Help with Confederation-RR-MPBGP
To all, I am studying for a certain vendors test, and need some guidance on best practices. Lets say you have a MPLS VPN with 4 PE routers. Is it more efficient to use RR or Confederation? Thank you, Philip
On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said:
need some guidance on best practices
What the vendor says is best practices, or what people in the trenches say?
Is it more efficient to use RR or Confederation?
If option A is 2% more "efficient" than option B, but takes 10% longer to deploy and causes 3% more SLA payouts to your customers when the added complexity causes a whoopsie, how much more work could you have gotten done in the time you spent in an uncomfortable meeting explaining to upper management why the whoopsie happened? (Sorry, it's been that sort of week :)
Le 12/06/2014 18:39, Valdis.Kletnieks@vt.edu a écrit :
On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said:
need some guidance on best practices
What the vendor says is best practices, or what people in the trenches say?
Is it more efficient to use RR or Confederation?
If option A is 2% more "efficient" than option B, but takes 10% longer to deploy and causes 3% more SLA payouts to your customers when the added complexity causes a whoopsie, how much more work could you have gotten done in the time you spent in an uncomfortable meeting explaining to upper management why the whoopsie happened?
(Sorry, it's been that sort of week :)
:-) Now, Philip, I think along the same path as Vladis: it depends... What does your physical or layer 2 network look like? How do you expect packets to move around inside, and in and out, of that topology? You need policing? How much and of what, etc, etc...? I'm quite often a fan of confed's, if the network is young thus ``easy'' migration, but there are scenarios... Please provide more detail to this mail thread or one-to-one if you prefer. Cheers, mh
I guess my question is (sorry MPLS speak ahead) with 4 PE's on the edge running MP-BGP and ISIS & 4 P's in the core running ISIS, is it best practice to confederate or use a route reflector and make the PE's clients. Basically I want to know what an ISP would do, not a test in a LAB. On Thursday, June 12, 2014 2:45 PM, Michael Hallgren <m.hallgren@free.fr> wrote: Le 12/06/2014 18:39, Valdis.Kletnieks@vt.edu a écrit :
On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said:
need some guidance on best practices
What the vendor says is best practices, or what people in the trenches say?
Is it more efficient to use RR or Confederation?
If option A is 2% more "efficient" than option B, but takes 10% longer to deploy and causes 3% more SLA payouts to your customers when the added complexity causes a whoopsie, how much more work could you have gotten done in the time you spent in an uncomfortable meeting explaining to upper management why the whoopsie happened?
(Sorry, it's been that sort of week :)
:-) Now, Philip, I think along the same path as Vladis: it depends... What does your physical or layer 2 network look like? How do you expect packets to move around inside, and in and out, of that topology? You need policing? How much and of what, etc, etc...? I'm quite often a fan of confed's, if the network is young thus ``easy'' migration, but there are scenarios... Please provide more detail to this mail thread or one-to-one if you prefer. Cheers, mh
On 6/18/14, 12:31 PM, "Philip Lavine" <source_route@yahoo.com> wrote:
I guess my question is, is it best practice to confederate or use a route reflector
Basically I want to know what an ISP would do, not a test in a LAB.
One data point that you may find useful: If you find out later that you’ve chosen incorrectly the first time around, it is FAR easier to change *from* RRs *to* Confeds than it is to do the opposite. The AS migration tools that you’d normally use to handle moving routers from one ASN to another don’t work to migrate routers from a confed ASN to a normal iBGP ASN setup, probably because the BGP machinery doesn’t know what to do with the union of the changes those things make to BGP’s default behavior, so you’re stuck with trying to find the least bad flag day way to handle renumbering ASNs out of a confed. Doing it without major traffic impact is pretty difficult since most of the options involve nuking BGP and rebuilding it to punt routers from one ASN to another, and doing this on multiple routers simultaneously in order to minimize the time when BGP is offline on multiple devices due to ASN mismatches. Size of network of course matters when considering whether this is really a potential issue for you, but since you’re asking in terms of what an ISP would do vs what works in a lab, considering large scale rather than today’s scale when determining the exit strategy is pretty important. Wes George Anything below this line has been added by my company’s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Le 18/06/2014 18:31, Philip Lavine a écrit :
I guess my question is (sorry MPLS speak ahead) No harm, me I've always rather consifered MPLS as a service provider (like VPN, etc).
with 4 PE's on the edge running MP-BGP and ISIS & 4 P's in the core running ISIS, is it best practice to confederate or use a route reflector and make the PE's clients.
MP-BGP for VPN, I guess? Or am I missing something in your case? If so, you use MPLS for services, right? Where do you hook up to 'the Internet'? This aside, I'd go the confederation way (only?) in case I see a potential future need to do amounts of by destination routing also within my network. I'd find it nicer than rushing down the RSVP lane (pending SR :-)) Makes some sense to you?
Basically I want to know what an ISP would do, not a test in a LAB.
Me, rarely had a lab for these kind of things, but quite often networks :-) Cheers, mh
On Thursday, June 12, 2014 2:45 PM, Michael Hallgren <m.hallgren@free.fr> wrote:
Le 12/06/2014 18:39, Valdis.Kletnieks@vt.edu <mailto:Valdis.Kletnieks@vt.edu> a écrit :
On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said:
need some guidance on best practices
What the vendor says is best practices, or what people in the trenches say?
Is it more efficient to use RR or Confederation?
If option A is 2% more "efficient" than option B, but takes 10% longer to deploy and causes 3% more SLA payouts to your customers when the added complexity causes a whoopsie, how much more work could you have gotten done in the time you spent in an uncomfortable meeting explaining to upper management why the whoopsie happened?
(Sorry, it's been that sort of week :)
:-)
Now, Philip, I think along the same path as Vladis: it depends... What does your physical or layer 2 network look like? How do you expect packets to move around inside, and in and out, of that topology? You need policing? How much and of what, etc, etc...?
I'm quite often a fan of confed's, if the network is young thus ``easy'' migration, but there are scenarios... Please provide more detail to this mail thread or one-to-one if you prefer.
Cheers,
mh
On Wednesday, June 18, 2014 06:31:38 PM Philip Lavine wrote:
I guess my question is (sorry MPLS speak ahead) with 4 PE's on the edge running MP-BGP and ISIS & 4 P's in the core running ISIS, is it best practice to confederate or use a route reflector and make the PE's clients.
Basically I want to know what an ISP would do, not a test in a LAB.
Route reflector. Mark.
participants (5)
-
George, Wes -
Mark Tinka -
Michael Hallgren -
Philip Lavine -
Valdis.Kletnieks＠vt.edu