Re: MPLS VPN design - RR in forwarding path?
. Yn - Reply message - From: "Randy Bush" To: "Marcin Kurek" Cc: "North American Network Operators' Group" Subject: MPLS VPN design - RR in forwarding path? Date: Wed, Dec 31, 2014 9:36 PM > - Move RRs out of the forwarding path this remains contentious. there are those who think having the control plane not congruent to the data plane is a recipe for really fun debugging and has other issues. randy
Re: MPLS VPN design - RR in forwarding path?
> - Move RRs out of the forwarding path this remains contentious. there are those who think having the control plane not congruent to the data plane is a recipe for really fun debugging and has other issues. randy
Re: MPLS VPN design - RR in forwarding path?
Hi, Right, one is when besides forwarding packets a router also functioning as a RR, another - when RR sets NH to itself and hence forces all the traffic to pass thru the router in fast path. Keep in mind - some architectures, such as seamless MPLS would require a RR to be in the fast path. There are some other cases where it could be a requirement. I'd advice to look into vRR space - price/performance looks quite good. Wrt open source implementations - if you are looking into relatively basic feature set (v4/v6 unicast/vpn) reliability is not of main concern and of course- there are hands and brains to support it - could be a viable approach. Might you be looking into more complex feature set - EVPN, BGP-LS, FS, enhanced route refresh, etc, highly optimized code wrt update rate/ number of peers supported - most probably you'd end up with a commercial implementation. Hope this helps Regards, Jeff > On Dec 31, 2014, at 9:08 AM, Chuck Anderson wrote: > >> On Wed, Dec 31, 2014 at 01:08:15PM +0100, Marcin Kurek wrote: >> Hi everyone, >> >> I'm reading Randy's Zhang BGP Design and Implementation and I found >> following guidelines about designing RR-based MPLS VPN architecture: >> - Partition RRs >> - Move RRs out of the forwarding path >> - Use a high-end processor with maximum memory >> - Use peer groups >> - Tune RR routers for improved performance. >> >> Since the book is a bit outdated (2004) I'm curious if these rules >> still apply to modern SP networks. >> What would be the reasoning behind keeping RRs out of the forwarding >> path? Is it only a matter of performance and stability? > > When they say "move RRs out of the forwarding path", they could mean > "don't force all traffic through the RRs". These are two different > things. Naive configurations could end up causing all VPN traffic to > go through the RRs (e.g. setting next-hop-self on all reflected > routes) whereas more correct configurations don't do that--but there > may be some traffic that natrually flows through the same routers that > are the RRs, via an MPLS LSP for example. That latter is fine in many > cases, the former is not. E.g. I would argue that a P-router can be > an RR if desired.
Re: MPLS VPN design - RR in forwarding path?
On (2014-12-31 12:05 -0500), Chuck Anderson wrote: Hey, > are the RRs, via an MPLS LSP for example. That latter is fine in many > cases, the former is not. E.g. I would argue that a P-router can be > an RR if desired. There is no compelling advantage. No budget is too thin for 3 gray NPE-G1, if they are, maybe network engineers without borders can help you. There are some compelling disadvantages, my current and previous employer both have experienced VPN AFI BGP UPDATE crashing whole box (infact whole cluster of 3 VPN reflectors, at once). Trying to achieve 0 outages is silly and impossible, reducing outage impact is often simple and cheap, sometimes not done, when only failure modes considered are physical (HW, fibre, electricity...) failures, rather than the more common modes (pilot and software). -- ++ytti
Re: MPLS VPN design - RR in forwarding path?
On Wed, Dec 31, 2014 at 01:08:15PM +0100, Marcin Kurek wrote: > Hi everyone, > > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path > - Use a high-end processor with maximum memory > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules > still apply to modern SP networks. > What would be the reasoning behind keeping RRs out of the forwarding > path? Is it only a matter of performance and stability? When they say "move RRs out of the forwarding path", they could mean "don't force all traffic through the RRs". These are two different things. Naive configurations could end up causing all VPN traffic to go through the RRs (e.g. setting next-hop-self on all reflected routes) whereas more correct configurations don't do that--but there may be some traffic that natrually flows through the same routers that are the RRs, via an MPLS LSP for example. That latter is fine in many cases, the former is not. E.g. I would argue that a P-router can be an RR if desired.
Re: MPLS VPN design - RR in forwarding path?
On 12/31/14 4:08 AM, Marcin Kurek wrote: > Hi everyone, > > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path I'd find it odd if the RR were the nexthop for any signficant traffic, in recent deployments I've done there's no fib to speak of excepting igp routes installed on the RR itself. > - Use a high-end processor with maximum memory bgp addpath kicked up the memory requirements of the RR considerably when we deployed it. > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules > still apply to modern SP networks. > What would be the reasoning behind keeping RRs out of the forwarding > path? Is it only a matter of performance and stability? > > Thanks, > Marcin > signature.asc Description: OpenPGP digital signature
Re: The state of TACACS+
Far too much discussion on this IMO. If you're that paranoid about it, just use the nuclear launch keys approach. Create the local account password, split it, give half of it to one party, half to the other. Then two separate parties must be engaged to use the account. Done. Sincerely, Clay Curtis Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows. On Mon, Dec 29, 2014 at 9:38 AM, Michael Douglas wrote: > In the Cisco world the AAA config is typically set up to try tacacs > first, > and local accounts second. The local account is only usable if > tacacs is > unavailable. Knowledge of the local username/password does not > equate to > full time access with that credential. Also, you would usually > filter the > incoming SSH sessions to only permit a particular management IP > range; the > local credential, or tacacs credential, shouldn't be usable from any > arbitrary network. > > On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor > > wrote: > > > Scott, > > > > Thanks for the response. How do you make sure the failsafe and/or > root > > password that is stored in the device incase remote auth fails > can't be > > accessed without having several employees engaged? Are there any > mechanisms > > for doing so? > > > > My fear would be we would hire an outsourced tech. After a certain > amount > > of time we would have to let this part timer go, and would disabled > his > or > > her username and password in TACAS. However, if that tech still > knows the > > root password they could still remotely login to our network and > cause > > havoc. The thought of having to change the root password on > hundreds of > > devices doesn't sound appealing either every time an employee is > let go. > To > > make matters worse we are using an outsourced firm for some network > > management, so the case of hiring and firing is fairly consistent. > > > > On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms > wrote: > > > > > Colton, > > > > > > Yes, that's the 'normal' way of setting it up. Basically you > still > have > > > to configure a root user, but that user name and password is kept > locked > > up > > > and only accessed in case of catastrophic failure of the remote > > > authentication system. An important note is to make sure that > the fail > > > safe password can't be accessed without having several people > engaged > so > > it > > > can't be used without many people knowing. > > > > > > > > > Scott Helms > > > Vice President of Technology > > > ZCorum > > > (678) 507-5000 > > > > > > http://twitter.com/kscotthelms > > > > > > > > > On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor > > > > > wrote: > > > > > >> We are able to implement TACAS+. It is my understanding this a > fairly > > old > > >> protocol, so are you saying there are numerous bugs that still > need to > > be > > >> fixed? > > >> > > >> A question I have is TACAS+ is usually hosted on a server, and > > networking > > >> devices are configured to reach out to the server for > authentication. > My > > >> question is what happens if the device can't reach the server if > the > > >> devices network connection is offline? Our goal with TACAS+ is > to not > > have > > >> any default/saved passwords. Every employee will have their own > username > > >> and password. That way if an employee gets hired/fired, we can > enable > or > > >> disable their account. We are trying to avoid having any > organization > > wide > > >> or network wide default username or password. Is this possible? > Do the > > >> devices keep of log of the last successful username/password > > combinations > > >> that worked incase the device goes offline? > > >> > > >> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake > > > >> wrote: > > >> > > >> > Picking back up where this left off last year, because I > apparently > > only > > >> > work on TACACS during the holidays :) > > >> > > > >> > > > >> > On 12/30/2013 7:28 PM, Jimmy Hess wrote: > > >> > > > >> >> Even 5 seconds extra for each command may hinder operators, > to the > > >> extent > > >> >> it would be intolerable; shell commands should run almost > > >> >> instantaneously this is not a GUI, with an hourglass. > > Real-time > > >> >> responsiveness in a shell is crucial --- which remote auth > should > not > > >> >> change. Sometimes operators paste a buffer with a fair > number of > > >> >> commands, not expecti...
Contact domain messagelabs.com
Hello Guys, So, is there anyone responsible by domain messagelabs.com here at list? I'm trying contact them , but no successful. Tks and Happy Holidays Welisson Tomé
Re: MPLS VPN design - RR in forwarding path?
On 31/12/2014 12:08, Marcin Kurek wrote: > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path > - Use a high-end processor with maximum memory > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules still > apply to modern SP networks. arguably more so now than ever, but you can always run RRs inline in the forwarding path if you want to. Taking RRs out of the forwarding plane means that you can keep your overall routing architecture simpler and more consistent, and adding/removing different forwarding hardware means that you don't really need to do much with the RR configuration. The larger router vendors all have virtualised RR implementations these days (XRv/CSR1k, vRR, AlcaLu, etc), which means that you can get to run your RRs on standard x86 hardware platforms using normal hypervisors. This wasn't the case in 2004. The pricing and licensing for virtual RR images from the normal vendors hasn't settled down into workable models yet but that's only a matter of time, particularly given that open source routing stacks are going to start seriously impinging on this market segment in the next couple of years. Nick
Re: MPLS VPN design - RR in forwarding path?
On Wednesday, December 31, 2014, Marcin Kurek wrote: > Hi everyone, > > I'm reading Randy's Zhang BGP Design and Implementation and I found > following guidelines about designing RR-based MPLS VPN architecture: > - Partition RRs > - Move RRs out of the forwarding path > - Use a high-end processor with maximum memory > - Use peer groups > - Tune RR routers for improved performance. > > Since the book is a bit outdated (2004) I'm curious if these rules still > apply to modern SP networks. > What would be the reasoning behind keeping RRs out of the forwarding path? > Is it only a matter of performance and stability? > > Thanks, > Marcin > Correct, these ideas are MOSTLY rooted in old school router limitations. Ymmv. Look for facts in the replies you get, not unsubstantiated opinions. There is no technical reason to have a bgp rr out of path on a hardware based forwarding router that has sufficient control plane capacity to run bgp. CB
MPLS VPN design - RR in forwarding path?
Hi everyone, I'm reading Randy's Zhang BGP Design and Implementation and I found following guidelines about designing RR-based MPLS VPN architecture: - Partition RRs - Move RRs out of the forwarding path - Use a high-end processor with maximum memory - Use peer groups - Tune RR routers for improved performance. Since the book is a bit outdated (2004) I'm curious if these rules still apply to modern SP networks. What would be the reasoning behind keeping RRs out of the forwarding path? Is it only a matter of performance and stability? Thanks, Marcin
