West Lafayette, IN
If a single router (A) forms eigrp peers with 2 other routers (B) and (c) so its like this:
...........=== Router B
...........=== Router C
And Router A receives a route (10.10.10.0/24 example) from both B and C with equal metrics (say B and C are CE routers who learn this network via BGP from PE router), does EIGRP automatically do its own load sharing and will alternate between the two routers? Or would it always prefer one path? Does that make sense? I want the office to utilize both routers. Is that possible?
So, if routers B and C are speaking BGP, they would have to redistribute that route into EIGRP as an external. The tricky part is that Admin distance comes into play here that can cause a route blackhole. Is this route an eBGP or iBGP route when it is learned on routers B and C?
If it is external, you should be fine as the admin distance of 20 will beat the external EIGRP distance of 170. If it is internal (distance 200), you will clobber the BGP route in B and C's tables when it learns the alternate redistributed route via EIGRP. What you will see is a continuous route flap condition. The key is to manually tune the admin distance when you redistribute the route into EIGRP to force it to have a higher admin distance than the BGP route.
As long as you resolve the "chicken and the egg" routing issue, you should be able to obtain equal cost load balancing from Router A's perspective, assuming the links from Router A to Router's B and C are identical and you set the identical metric on either redistribution statement.
Scott, CCIE #14618 Routing & Switching
Too bad those that know it all can't do it all.
West Lafayette, IN
Yes, it eBGP and redistributes into EIGRP and everything is identical. So in doing this there equal load balancing? Hmm, so if say a packet leaves Router A and goes across Router B to go wherever will there be any possibility of asynchronous routing? How would the return traffic know to cross Router B back to A vs going through C?
Why dont you extend BGP to router A as well?
Keeping everything within one routing protocol is usually superior to attempting multiprotocol redistribution and trickery. I spend most of my time converting sites from BGP at the edge redistributed into an IGP, to pure BGP. If there are too many routed devices to full-mesh within a large site, i usually turn the wan routers into route reflectors. There is alot to be said for proper site/wan routing design. Those IGPs have caused alot of trouble with inter-site looping and path selection during incidents where equipment has failed and routing is sub-optimal.
I would agree with nosx said since it has been my own experience to prefer dealing with simple BGP-based network design instead of BGP-EIGRP multiprotocol design. By having BGP-based network design as nosx mentioned, you could keep the EIGRP as IGP only within the BGP AS domain while the BGP will control routing between sites (between BGP AS domains) and so will decide the best route path to reach specific destination (in your case, to reach 10.10.10.0/24 network).
However for theory sake, the route selection between multiple equal-metric routes (equal in administrative distance and equal in cost) by default will be load balanced. Should the load balanced be equally the same across the paths? The answer is depend on a lot of factors such as LAN design and (in your case) the MPLS cloud design. Mostly what I've seen in such scenario is that one circuit is more utilized than other.
|reply to lildevil |
I highly disagree with nsox as BGP is not needed in the entire infrastructure if the only router dealing with it is router A... It's just a hideous design as BGP really needs an IGP anyway like aryoba has stated.
Now staying on the topic, here's a Cisco's Doc essplainin' loadbalancing. This doc also has links to other loadbalancing manipulations
If your full routing table is in bgp, you should extend BGP. IGPs are used for loopback routing for iBGP relationships. The alternative to extending BGP is to redistribute routing information (bad practice in most cases) and just default / static routing from downstream devices (not scalable, doesnt meet all possible needs).
If you have a site or campus with 40 core/distribution routers, you should extend iBGP to the devices that participate in routing. Redistribution in that case has resulted in massive messes at customer after customer that i always clean up with extending bgp and moving reachability information into it.
just because someone does not comprehend the redistribution, is not the cause to extend another protocol what so ever...
how do you extend global routing policy when you are redistributing across large regional networks with backdoors?
Do you take all the bgp community values and convert them to ospf tags? and then try to convert back again? keeping everything in one protocol simplifies management and global routing policy. I havent worked for a large organization that relied on redistribution to get their packets flowing correctly.
it's simple really.... you don't you only redistribute one way out as he states... You only do things like you said in an ISP not an enterprise or a campus...
|reply to Da Geek Kid |
Most of the time, I'm not a fan of having IGP as a backdoor and as backup link to BGP-based network since it complicates the network unnecessarily. However there are times that you could use IGP as either primary or secondary link to BGP-based network without causing headache. The key is to separate IGP routing domain between the IGP as the alternate link to BGP-based network and the IGP as the IGP to support the iBGP session. Some people call this to maintain the alternate IGP routing table small and to separate the IGP routing domain off "the main IGP".