Re: Route Reflector Client Design Question

[Spyros Kakaroukas]

Hey Erik,

1) This messes up the design and introduces unnecessary complexity. As your 
issue is not directly caused by having a RR topology, I’d avoid doing that.
2) That, IMHO, would be the optimal solution, assuming you don’t have enough 
internal routes to overflow the TCAM of your PEs in the near future. This would 
also solve some potential loops if you ever want to pass unlabelled traffic.
3) That’s a very generic question with broad potential answers.
4) You could, but you’d have to evaluate that trade-off yourself ;)

Kind regards,

My thoughts and words are my own.

Spyros

On 04/05/2018, 09:02, "NANOG on behalf of Erik Sundberg" 
 wrote:

I have a RR Client design question..


CORE1---2x10G---CORE2
|   
|
|   
|
|10G Ring   
|
|   
|
|   
|
PE1--PE2--PE3--PE4--PE5


-Core1 & Core2 are RR Reflectors with full IPV4 Tables (ASR9K)
-MPLS LDP Enabled
-IGP is ISIS
-Each PE peers only with Core1 and Core2 as RR Clients with iBGP
-PE's are only receiving a default route from the Core Routers due to TCAM 
size of 20K (ASR920's\ME3800's)
-The ring does not have that much traffic on it <500m, so I do not want to 
use additional 10G ports on the Core's and is why I have it in a 10G U ring.
-Primary link to the cores is via the PE1 --- CORE1 Like. For this 
discussion the link between PE5 to CORE2 is set up as a backup link.

The scenario is I have traffic between PE2 and PE3. Since the PE's are only 
receiving a default route from the Cores. Traffic is label switch from PE2 - 
PE1 - Core1 does a IP lookup at Ingress then label switches back to 
PE1-PE2-PE3. This ends up being 5 hops and doubling the traffic on the link to 
the Cores.

My questions is how do I get traffic to go directly between the PE's 
without going to the Core Routers?

1. Can I enable iBGP between the PE's in a full mesh to allow traffic 
between the PE's without going to the core's. Or does this break the Route 
Reflector model?
2. Create a route policy on the Core's advertising routes learned from the 
PE's back to all the PE's on the ring.
3. Is this one of the down sides to U Rings?
4. Leave it alone and move on to bigger and better things


Thanks

Erik



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files 
or previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. Thank 
you.

RE: route converge time

[Spyros Kakaroukas]

Hey,

This is a complex problems and there are quite a few parts to consider.

Let's assume you want to optimize how fast you choose the right best exit 
after a failure. The opposite ( how fast the internet chooses the best entry 
point into your network after a failure ) is usually not that easy to 
influence.

The first component of our total convergence time is how fast you can actually 
detect the failure. If your bgp speaker is directly connected to the transit's 
bgp speaker with no boxes inbetween, then you can detect the failure about as 
fast as it takes your end to detect that the link is down, which is usually 
pretty fast ( you could tune the carrier-delay if you want to ). If there are 
any other boxes in-between , you can't rely on that. The best solution in that 
case, imho, would be to use bfd. If you can't do that, you may want try and 
tune bgp keepalive/holddown timers. Keep in mind that running aggressive 
timers will consume cpu resources on both your and the provider's end.

The second component would be how much time it takes bgp to find the alternate 
routes. As you're using l3vpn , there's an easy trick to apply here. You can 
just set up a different rd on each router and both routers will end up with 
routes from both providers in their bgp table. That will obviously consume 
hardware resources ( usually ram, as not every route will make it to the fib 
just yet ) so make sure your routers can handle it.

The third component would be how much time it takes you to update the fib 
itself. This is usually fast for a single route, but not as fast as you might 
think for ~550k routes. What you can do to speed this up depends somewhat on 
your hardware. Most big vendors do support some flavor of a hierarchical fib 
( cisco calls theirs pic core ). Keep in mind that this will also eat up 
hardware resources depending on the implementation itself. Make sure you read 
up before you try anything as it could end up doubling your fib requirements, 
which aren't light to begin with for full tables.

Last but not least, keep scalabity in mind when reading the last 2 paragraphs. 
On newer boxes, tuning for fast convergence may be more than fine for 2 
providers but practically impossible for, say, 6 or 8 of them.

As for the scenarios of local failure, first of all, really try to make sure 
that the ibgp session between them ( or towards their RRs/etc ) is as robust 
as it gets. Assuming that's taken care of, convergence should be about as much 
time as it takes your igp to figure it out. Bfd and usual igp timer/feature 
adjustments do apply. Next-hop tracking and fast peering detection ( assuming 
cisco ) are also nice, though if you have defaults in your network, you might 
want to exclude them from being used for either.

My thoughts and words are my own.

Kind Regards,

Spyros


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Baldur Norddahl
Sent: Saturday, November 21, 2015 3:45 PM
To: nanog@nanog.org
Subject: route converge time

Hi

I got a network with two routers and two IP transit providers, each with the 
full BGP table. Router A is connected to provider A and router B to provider 
B. We use MPLS with a L3VPN with a VRF called "internet".
Everything happens inside that VRF.

Now if I interrupt one of the IP transit circuits, the routers will take 
several minutes to remove the now bad routes and move everything to the 
remaining transit provider. This is very noticeable to the customers. I am 
looking into ways to improve that.

I added a default static route 0.0.0.0 to provider A on router A and did the 
same to provider B on router B. This is supposed to be a trick that allows the 
network to move packets before everything is fully converged.
Traffic might not leave the most optimal link, but it will be delivered.

Say I take down the provider A link on router A. As I understand it, the 
hardware will notice this right away and stop using the routes to provider A. 
Router A might know about the default route on router B and send the traffic 
to router B. However this is not much help, because on router B there is no 
link that is down, so the hardware is unaware until the BGP process is done 
updating the hardware tables. Which apparently can take several minutes.

My routers also have multipath support, but I am unsure if that is going to be 
of any help.

Anyone got any tricks or pointers to what can be done to optimize the downtime 
in case of a IP transit link failure? Or the related case of one my routers 
going down or the link between them going down (the traffic would go a 
non-direct way instead if the direct link is down).

Thanks,

Baldur


smime.p7s
Description: S/MIME cryptographic signature

RE: mpls over microwave

[Spyros Kakaroukas]

Hey,

We run few mpls links ( 7600s/3600s on the mpls side mostly ) over Ceragon 
wireless gear. Nothing too fancy, I just treat them as switches ( or even just 
cables for some boxes,  not doing mac learning at all ). No issues whatsoever 
on the networking side.


My thoughts and words are my own.

Kind Regards,

Spyros

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks
Sent: Thursday, February 05, 2015 11:55 PM
To: nanog@nanog.org
Subject: mpls over microwave



Anyone doing MPLS over microwave radios?  Please share your experiences on list 
or off.

scott


This e-mail and any attachment(s) contained within are confidential and are 
intended only for the use of the individual to whom they are addressed. The 
information contained in this communication may be privileged, or exempt from 
disclosure. If the reader of this message is not the intended recipient, you 
are hereby notified that any dissemination, distribution, or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify the sender and delete the communication without 
retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, 
any opinion, recommendation, conclusion, solicitation, offer or agreement or 
any information contained in this communication.