Ipsec/VRF Mpls ?
Hi after a first post with 0 answer (very thanks ..) i test a second post for get a small help. I am search a simple sample of configuration for a cisco 2821 for connect a Ipsec routers ton a MPLS IP VPN Backbone My cisco 2821 have two interface, one connected at my MPLS network and the second at the Internet. I create two vrf, one for a site to site and the second for a Remote User Access anyone have this into a config ? because i never have used Ipsec actually on cisco. The site-to-site router are a C1721, and remote user use cisco IPSEC client and i want a radius authentification (and it's the radius that sent the vrf) thanks for your help Stephane
RE: Routing to multiple uplinks
Anycast? http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=nm=n anog29 Might need to know a little more about the layout here for a better answer. -Scott -Original Message- From: rodrick brown [mailto:rodrick.br...@gmail.com] Sent: Friday, December 18, 2009 7:47 PM To: nanog@nanog.org list Subject: Routing to multiple uplinks This may be slightly off topic however I have a very unique situation where I need to provide two diverse paths to a major stock exchange. Each host may either use route A or B for any given reason to access this particular exchange using two distinct routers and target address. The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. I believe my only option here is to setup multiple default routes with a preferred path of some sort. This seems to be possible using ip route2 on Linux. This just seems wrong on many levels and I thought I would post here because I know there is something obvious I'm missing. Please clue me in. Thanks. Sent from my iPhone 3GS.
Re: Chinese bgp metering story
On Sat, Dec 19, 2009, Dobbins, Roland wrote: Existing hardware does this today with NetFlow, et. al. .. not only that, we've been doing this for a bloody long time in internet years. About all that really matter is figuring out how to engineer your network to allow for netflow based billing without having subtle duplicate flows everywhere.. Adrian (Ah, thinking about this stuff brings back memories, and I'm only 30..)
Re: Edge-Core (Accton) switches
On 02.12.2009 19:12, Todd Mueller wrote: Anyone have any experience using Edge-Core switches (or Accton, Edge-Core is a subsidiary)? Good/bad? Pricing/features seem good, but you often get what you pay for . . . we have a couple of Foundry Networks EdgeIron 4802CF, which should be similar to accton's ES3550C [1]. we have a hand full of vlans (10-20) configured and use them as a top-of-the-rack (?) switch to connect our customer's servers. the gbit uplink(s) are connected to our core equipment. on our experience, the do no good job at handling too much load. depending on the firmware, the management cpu will become too loaded and you'll have troubles accessing the switch via ssh or you'll see snmp issues. however, i haven't seen any real issues with switching performance. cheers raoul [1] http://www.accton.com/products/product_range/01_l2fes/es3550c.htm -- DI (FH) Raoul Bhatia M.Sc. email. r.bha...@ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email.off...@ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax.+43 1 3670030 15
Re: Chinese bgp metering story
On Fri, Dec 18, 2009 at 10:09:32PM -0600, James Hess wrote: On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin jo...@pch.net wrote: .. modified if need be - to achieve this. ?Mixing billing with the reachability information signalled through BGP just doesn't seem like a good idea. Indeed not.. but it might offer one advantage, if it was mandatory for any such tarrif/cost to be advertised there to be valid, and in the form of an ancillary BGP route attribute, rather than buried in some 500,000 page treaty that forces all ISPs to decipher it and try to figure out what their liabilities are. Mainly because it makes any tarrif very visible, and easily understood. and offers an easy ability to automatically make decisions like discard reachability information that has any billing labels or strings attached to it, or has a cost greater than $X per million packets listed for 'source'... and easily allows an ISP to replace the next hop with null when a tarrif option has been listed, or use only a route not subject to tarrif. I concur. Such visibility is efficient and drives simplification and automation from a data mining perspective, when analyzing accounting information. In such context, some care is required. Reachability information is destination based. Mixing accounting (ie. NetFlow) and reachability (ie. BGP) information is of good value for traffic delivered out of a routing domain but not for traffic received, ie. reverse reachability lookups can be a way although they are not truly deterministic due to routing asymmetries; a mix of ingress measurements, lookup maps and an export protocol supporting L2 information (ie. for same interface, multiple peers scenarios) give way a better chance to resolve which neighboring party is pulling which traffic into the observed domain. Cheers, Paolo
Re: Chinese bgp metering story
i am truely in awe how deeply the implications and alternatives have been analysed. this is particularly impressive given the complete absense of any facts about the alleged proposal. randy
Re: Chinese bgp metering story
On Dec 19, 2009, at 6:42 PM, Randy Bush wrote: this is particularly impressive given the complete absense of any facts about the alleged proposal. I think the whole brouhaha is the merely result of someone saying 'BGP-speaking routers' vs. saying 'peering/transit edge routers', combined with the notion of somehow cartelizing this on a national basis vs. the current individual network-to-network private/public basis. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Chinese bgp metering story
On Sat, Dec 19, 2009 at 08:42:33PM +0900, Randy Bush wrote: i am truely in awe how deeply the implications and alternatives have been analysed. this is particularly impressive given the complete absense of any facts about the alleged proposal. Part of the thread just went more of general discussion about mixing accounting/reachability information despite the original subject label was retained. Cheers, Paolo
Re: Chinese bgp metering story
Paolo Lucente wrote: On Fri, Dec 18, 2009 at 10:09:32PM -0600, James Hess wrote: On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin jo...@pch.net wrote: .. modified if need be - to achieve this. ?Mixing billing with the reachability information signalled through BGP just doesn't seem like a good idea. Indeed not.. but it might offer one advantage, if it was mandatory for any such tarrif/cost to be advertised there to be valid, and in the form of an ancillary BGP route attribute, rather than buried in some 500,000 page treaty that forces all ISPs to decipher it and try to figure out what their liabilities are. Mainly because it makes any tarrif very visible, and easily understood. and offers an easy ability to automatically make decisions like discard reachability information that has any billing labels or strings attached to it, or has a cost greater than $X per million packets listed for 'source'... and easily allows an ISP to replace the next hop with null when a tarrif option has been listed, or use only a route not subject to tarrif. I concur. Such visibility is efficient and drives simplification and automation from a data mining perspective, when analyzing accounting information. In such context, some care is required. Reachability information is destination based. Mixing accounting (ie. NetFlow) and reachability (ie. BGP) information is of good value for traffic delivered out of a routing domain but not for traffic received, ie. reverse reachability lookups can be a way although they are not truly deterministic due to routing asymmetries; deliberate tunning for purposes of TE, use of default. will all contribute to ingress path not resembling egress... a mix of ingress measurements, lookup maps and an export protocol supporting L2 information (ie. for same interface, multiple peers scenarios) give way a better chance to resolve which neighboring party is pulling which traffic into the observed domain. Cheers, Paolo
Re: Routing to multiple uplinks
Maybe I am missing something, but how does VRRP/HSRP cause latency? On 12/19/09 3:45 AM, Scott Berkman wrote: Anycast? http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=nm=n anog29 Might need to know a little more about the layout here for a better answer. -Scott -Original Message- From: rodrick brown [mailto:rodrick.br...@gmail.com] Sent: Friday, December 18, 2009 7:47 PM To: nanog@nanog.org list Subject: Routing to multiple uplinks This may be slightly off topic however I have a very unique situation where I need to provide two diverse paths to a major stock exchange. Each host may either use route A or B for any given reason to access this particular exchange using two distinct routers and target address. The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. I believe my only option here is to setup multiple default routes with a preferred path of some sort. This seems to be possible using ip route2 on Linux. This just seems wrong on many levels and I thought I would post here because I know there is something obvious I'm missing. Please clue me in. Thanks. Sent from my iPhone 3GS. -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
Re: Routing to multiple uplinks
VRRP/HSRP does not cause latency the problem we faced prior was when links flapped or timed out this would be too much of a hindrance for our users to reconcile application state with various trading venues we are trading thousands upon thousands of trades a minute to various destinations. As stated before Path A and Path B are two distinct paths they do however provide identical services but application state is not preserved. A new session and state must be established if a user decides to switch between paths. Essentially we provide the ability for users either shutdown and start sending orders to Path A or Path B based on latency from our servers to these trading venues we're actively monitoring latency between both end points. The overall design is being driven by our rigorous application needs more than anything. The implementation is straight forward we receive a duplicate set of feeds from site A and site B and can also access various services coming from site A or site B however, at any given time a user will be sending/recieving data from one of those destinations. Never both simultaneously. So my question what is the best way to provide this type of redundancy at the host level? The application will only use one target address. On Sat, Dec 19, 2009 at 1:17 PM, Steven King sk...@kingrst.com wrote: Maybe I am missing something, but how does VRRP/HSRP cause latency? On 12/19/09 3:45 AM, Scott Berkman wrote: Anycast? http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=nm=n anog29 Might need to know a little more about the layout here for a better answer. -Scott -Original Message- From: rodrick brown [mailto:rodrick.br...@gmail.com] Sent: Friday, December 18, 2009 7:47 PM To: nanog@nanog.org list Subject: Routing to multiple uplinks This may be slightly off topic however I have a very unique situation where I need to provide two diverse paths to a major stock exchange. Each host may either use route A or B for any given reason to access this particular exchange using two distinct routers and target address. The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. I believe my only option here is to setup multiple default routes with a preferred path of some sort. This seems to be possible using ip route2 on Linux. This just seems wrong on many levels and I thought I would post here because I know there is something obvious I'm missing. Please clue me in. Thanks. Sent from my iPhone 3GS. -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown
Re: Routing to multiple uplinks
HSRP/VRRP can be tweaked to less than 1s fail over time. Can you provide a copy of your network map for analysis? GLBP might be a viable option as fail over is not actually an issue at that point. On 12/19/09 2:48 PM, Rodrick Brown wrote: VRRP/HSRP does not cause latency the problem we faced prior was when links flapped or timed out this would be too much of a hindrance for our users to reconcile application state with various trading venues we are trading thousands upon thousands of trades a minute to various destinations. As stated before Path A and Path B are two distinct paths they do however provide identical services but application state is not preserved. A new session and state must be established if a user decides to switch between paths. Essentially we provide the ability for users either shutdown and start sending orders to Path A or Path B based on latency from our servers to these trading venues we're actively monitoring latency between both end points. The overall design is being driven by our rigorous application needs more than anything. The implementation is straight forward we receive a duplicate set of feeds from site A and site B and can also access various services coming from site A or site B however, at any given time a user will be sending/recieving data from one of those destinations. Never both simultaneously. So my question what is the best way to provide this type of redundancy at the host level? The application will only use one target address. On Sat, Dec 19, 2009 at 1:17 PM, Steven King sk...@kingrst.com mailto:sk...@kingrst.com wrote: Maybe I am missing something, but how does VRRP/HSRP cause latency? On 12/19/09 3:45 AM, Scott Berkman wrote: Anycast? http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=nm=n http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=nm=n anog29 Might need to know a little more about the layout here for a better answer. -Scott -Original Message- From: rodrick brown [mailto:rodrick.br...@gmail.com mailto:rodrick.br...@gmail.com] Sent: Friday, December 18, 2009 7:47 PM To: nanog@nanog.org mailto:nanog@nanog.org list Subject: Routing to multiple uplinks This may be slightly off topic however I have a very unique situation where I need to provide two diverse paths to a major stock exchange. Each host may either use route A or B for any given reason to access this particular exchange using two distinct routers and target address. The applicatiOn running on these hosts must only see/use one target address this needs to be transparent as possible. NIC bonding/teaming on the host side isn't a viable solution because of the latency overhead same goes for vrrp/hsrp. I believe my only option here is to setup multiple default routes with a preferred path of some sort. This seems to be possible using ip route2 on Linux. This just seems wrong on many levels and I thought I would post here because I know there is something obvious I'm missing. Please clue me in. Thanks. Sent from my iPhone 3GS. -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
