Calling all BGP experst help
Hi guys,
okay I am talking with this guy on BGP convergence. This is our situation.
we have a mpls router and vpls router. We use vpls and primary and mpls as secondary.
when we do a failover test it takes like 5 minutes to converge. I looked on our MPLS router
and it has a huge BGP table and huge EIGRP table due to the fact we are doing route redistribution.
long story short:
I feel convergence time could be improved if we would do 2 things.
1. on the edge router, summarize some EIGRP routes
2. use prefix lists of networks not necessary in the edge router like routes to the entire WAN
We have tons of routes to our entire cloud. I know we only need a few routes for our LAN devices here to get to. we do not need routes in our BGP table that get injected into our RIB table. what for if you never access that subnet?
3. tweak the bgp timers keep alive and hold timers
this engineer i am talking to says no need to tweak the RIB. I said what? it is huge and our LAN doesnt need to look thru the entire RIB table, it only needs a few routes to access the WAN. It takes time to search a RIB table. Isn't this what we have been taught as network engineers to reduce the RIB table to decrease the look up time to improve converegnce. I have no reference for this engineer and he is higher than me. Am I wrong?
okay I am talking with this guy on BGP convergence. This is our situation.
we have a mpls router and vpls router. We use vpls and primary and mpls as secondary.
when we do a failover test it takes like 5 minutes to converge. I looked on our MPLS router
and it has a huge BGP table and huge EIGRP table due to the fact we are doing route redistribution.
long story short:
I feel convergence time could be improved if we would do 2 things.
1. on the edge router, summarize some EIGRP routes
2. use prefix lists of networks not necessary in the edge router like routes to the entire WAN
We have tons of routes to our entire cloud. I know we only need a few routes for our LAN devices here to get to. we do not need routes in our BGP table that get injected into our RIB table. what for if you never access that subnet?
3. tweak the bgp timers keep alive and hold timers
this engineer i am talking to says no need to tweak the RIB. I said what? it is huge and our LAN doesnt need to look thru the entire RIB table, it only needs a few routes to access the WAN. It takes time to search a RIB table. Isn't this what we have been taught as network engineers to reduce the RIB table to decrease the look up time to improve converegnce. I have no reference for this engineer and he is higher than me. Am I wrong?
Comments
-
DPG Member Posts: 780 ■■■■■□□□□□Why is the BGP table huge? Are you taking full routes? Do you have multiple WAN connections?
Hopefully you aren't dumping the entire BGP table into EIGRP which sounds like a possibility. -
daveyb Member Posts: 28 ■□□□□□□□□□Hi guys,
okay I am talking with this guy on BGP convergence. This is our situation.
we have a mpls router and vpls router. We use vpls and primary and mpls as secondary.
when we do a failover test it takes like 5 minutes to converge. I looked on our MPLS router
and it has a huge BGP table and huge EIGRP table due to the fact we are doing route redistribution.
long story short:
I feel convergence time could be improved if we would do 2 things.
1. on the edge router, summarize some EIGRP routes
2. use prefix lists of networks not necessary in the edge router like routes to the entire WAN
We have tons of routes to our entire cloud. I know we only need a few routes for our LAN devices here to get to. we do not need routes in our BGP table that get injected into our RIB table. what for if you never access that subnet?
3. tweak the bgp timers keep alive and hold timers
this engineer i am talking to says no need to tweak the RIB. I said what? it is huge and our LAN doesnt need to look thru the entire RIB table, it only needs a few routes to access the WAN. It takes time to search a RIB table. Isn't this what we have been taught as network engineers to reduce the RIB table to decrease the look up time to improve converegnce. I have no reference for this engineer and he is higher than me. Am I wrong?
As the person above me mentioned, how many prefixes are you receiving from your upstream?
Redistributing your entire BGP feed into an IGP is usually exactly what you don't want to be doing. Depending on how many routes you are carrying this will definitely slow down your convergence. Usually, you would keep your routes learnt via BGP in BGP, and only keep your P2P and loopbacks in your IGP. This will give you your best possible convergence time. If you do want to redistribute into your IGP for some reason, then you likely want to filter the routes down to the bare minimum first. Probably just a default. You may also want to look at switching from EIGRP to OSPF. You can then enable things like OSPF LFA to get your convergence lightning fast.
Cisco default BGP keepalive/holdtime are 30/180 seconds. This means you need to wait 3 minutes before your BGP session will drop. (Depending on the kit your provider is working, it may have actually negotiated lower. From what I remember it is the lowest requested hold time that is used). To speed failing over, you definitely want to drop this down. 10/30 is probably closer to what you are after. You can speed this up even further by running something like BFD (if your carrier supports it), or using IPSLA to track a route that you expect to see over that interface. -
itdaddy Member Posts: 2,089 ■■■■□□□□□□
Redistributing your entire BGP feed into an IGP is usually exactly what you don't want to be doing
Yup. Okay we are advertising most all WAN sub-nets into our edge router. Which when I was at Fiserv, we never did that only that which was necessary for reachability.
And this router does redistribution EIGRP (IGP LAN Side) and BGP redistirbution (EGP WAN side).
What I want to do is;
1. adjust default timers to smaller values
2. add filter prefix list to filter out not needed reachability routes
3. use EIGRP route summarization command on inside LAN interface.
to decrease the convergance time when we failover from VPLS to MPLS. It takes like 5 minutes.
I understand I have the entire wan involved but both MPLS and VPLS are always up and fully converged all the time just when I failover, unplug vpls router LAN/WAN cables the core L3 EIGRP send traffic to the new successor which is the MPLS router it should be faster.
The BGP table like I said has entire WAN subnet but the local LAN doesnt even need to access all of those routes ever. why keep them in the BGP table and thus in the route table right?
And why not summarize the route back for our LAN subnet 172.16.192.0 /18 right?
it only has 2 interfaces LAN and WAN why not summarize it else you see it agregated into like 30 subnets according to our LAN break out. -
fredrikjj Member Posts: 879where's the diagram we need?
PS.
sorry if that sounded rude, but it's not really possible to discuss questions like this without knowing more about what's going on in terms of topology, protocols and IP prefixes. -
itdaddy Member Posts: 2,089 ■■■■□□□□□□I do not have a drawing because it is a simple setup. let me explain:
2 edge routers
1. vpls that is multimesh with tons of other peers (entire wan)
2. mpls router cer and per only neighbors
both have entire wan in bgp tables thus in the route table
and these routers redistribute back to LAN EIGRP which is large as well.
each router only has LAN and WAN so. I am going to summarize routes back to LAN because they only have 1 interface to traverse and i can prefix some routes out of BGP table since our LAN never travels to the other subnets. dont you think? isnt that what prefix list are for so you dont have a need to travel to the other subnets why have them in your bgp table? and summarize routes on your edge routers back to the LAN since only 1 interface back anyway. -
fredrikjj Member Posts: 879I do not have a drawing because it is a simple setup.
Ok be stubborn then, but it would have taken you way less time to draw than write all these posts, and we still don't know how it looks.let me explain:
2 edge routers
1. vpls that is multimesh with tons of other peers (entire wan)
2. mpls router cer and per only neighbors
both have entire wan in bgp tables thus in the route tableand these routers redistribute back to LAN EIGRP which is large as well.
Ok, what does large mean?each router only has LAN and WAN so. I am going to summarize routes back to LAN because they only have 1 interface to traverse
Sound reasonable.and i can prefix some routes out of BGP table since our LAN never travels to the other subnets. dont you think? isnt that what prefix list are for so you dont have a need to travel to the other subnets why have them in your bgp table?
Sounds like a horrible idea to be honest to micromanage what prefixes you advertise to other sites. What if reachability is required at some later date? -
itdaddy Member Posts: 2,089 ■■■■□□□□□□imagine this:
a core vss layer 3 switch that points to a vpls edge router and a mpls edge router. they are separate business clouds. one is vpls and one is mpls NOT The internet our own private L2 and L3 wans.
we use EIGRP successor route to take the vpls due to the metric speed is faster.
one the VPLS and MPLS routers we redistirbute our LAN EIGRP into the BGP.
the routes back are a lot say 30 to 40 subnets towards the LAN direction and towards the MPLS and vpls direction 55 prefixes.
i know we do not traverse to every subnet no way. the tables are not optimized they should be for faster convergence isnt that what network engineering study teaches us? -
Iristheangel Mod Posts: 4,133 ModAgreed with the folks. While it sounds "simple" enough, I think a diagram illustrating how both are connected, how the routing is working, how the WAN is designed, etc would add color to what you're asking
-
daveyb Member Posts: 28 ■□□□□□□□□□55 routes is not very many. Convergence times will not be affected by this, even on old crappy hardware. You need 1000's of routes for this to start being an issue. I would just suppress all routes being advertised onto your LAN, and just advertise a default route. Sounds like that is all that is required.
Your problem with failover times is likely down to actually detecting the session is dead. Lower your timers, and investigate things like BFD or IP SLA to sort that out.