Calling all BGP experst help

itdaddyitdaddy Posts: 2,086Member
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?

Comments

  • DPGDPG Posts: 780Member
    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.

  • daveybdaveyb Posts: 28Member ■□□□□□□□□□
    itdaddy wrote: »
    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?
    You probably need to include a bit more information about your setup, like a network diagram.


    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.
  • itdaddyitdaddy Posts: 2,086Member

    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.
  • fredrikjjfredrikjj Posts: 879Member
    where'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.
  • itdaddyitdaddy Posts: 2,086Member
    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.
  • DPGDPG Posts: 780Member
    How many WAN routes are you seeing?

  • fredrikjjfredrikjj Posts: 879Member
    itdaddy wrote: »
    I 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 table
    And how are they connected to the other routers in this network? What does "entire WAN" mean? Is this some kind of private WAN or is WAN the Internet? If it's just a (large) private WAN why do you focus so much on the number of prefixes?
    and 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?
  • itdaddyitdaddy Posts: 2,086Member
    55 bgp prefixes i see in bgp
  • itdaddyitdaddy Posts: 2,086Member
    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?
  • EngRobEngRob Posts: 247Member ■■■□□□□□□□
    Diagram? I have no imagination
  • IristheangelIristheangel ABL - Always Be Labbin' Pasadena, CAPosts: 4,098Mod Mod
    Agreed 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
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
    Bonus TE Fun: Nerd Photos
  • daveybdaveyb Posts: 28Member ■□□□□□□□□□
    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.
Sign In or Register to comment.