Obviously, the specifics of the network statements and router-id are unique per device. Each device has a LOOPBACK interface with an IP that matches the router-id and is a /32 in the rage of 172.29.254.0/24. Each device ALSO has a null bridge that is in the range 172.29.253.0/24 (added as a /32 as well), which is advertised into BGP and NOT in OSPF. This is following the description given here: http://www.stubarea51.net/2017/05/27/wisp-design-using-ebgp-and-ospf-transit-fabric-for-traffic-engineering/. BGP sessions are between the 172.29.254.x IPs on each neighboring router. So, for example, “Core” is peered with “Grub”, “Peggy” and “Reed”. BGP config is as follows:
This is a portion of the BGP config on the “Woodchuck” router. All others are the same with a unique PRIVATE AS per router, so this config creates an eBGP connected network. The network between “Core” and “Gateway” is OSPF only and the default route is being injected from the Gateway OSPF config. I am creating filters like this to influence routes. As an example, here is 172.29.253.5:
Here is the CORE config where I need to specify going through Peggy instead of Reed (default):
This works and traffic flows as expected. My problem is that It will not fail over. I am learning about this route via the Reed router, or I would add to the filter to test for the presence of a community that is added via the 172.29.254.12 (Peggy) router. What am I missing? Any ideas to even try?
In your setup - it seems like failover should come from ospf - and not BGP. If a link goes down - the bgp need to know its peer by your ospf routes. Try to experiment with your OSPF cost. A simple setup is to se the net as circle. Core is circle 1- All devices connected to this - circle2 - all devices connected to circle 2 devices - circle 3 eg…
Then add a ospf cost at all circles - C1-10/ c2 - 100/ c3 -1000 eg.
to make your setup even simpler - forget gateway and stuff behind this (core - gateway). I read this as a 0.0.0.0/0 route. Maybe you need the server/dude route to gateway - but this dont need to be advertised to core. Then just add a defualt. dont use bgp/ospf for default here. Focus on your core device(s).
make a ospf - with cost 10 to stevi,grub,peggy and reed from core
make a ospf - cost 100 to koot,carvallies, woodhuck,florence from reed and from grub to corvallies. here its possible if this is backup link - to set 200 in cost.
I think you might have a simpler setup if you enable MPLS in your setup. its 99% ready if you have l2MTU enough trough your links. then you can run MMPLS BGP and use vpls or vrf at CPE interfaces, and have a MPLS failover using ospf cost as logical failover.
Butche - nice to see you again (over the forums hehe)
I have run into this exact problem and am super happy you posted that link - its exactly what I need to do here because ospf just ain’t cutting it. I want to read up more on this solution and see if it will help me out.
Do you have more than one bgp peer on the same interface? A while back I ran into a bug (feature) that had something to do with more than one instance or peer on the same interface… not sure if thats related or not. It seems like the last one to come up won.
I have run into this exact problem and am super happy you posted that link - its exactly what I need to do here because ospf just ain’t cutting it. I want to read up more on this solution and see if it will help me out.
Do you have more than one bgp peer on the same interface? A while back I ran into a bug (feature) that had something to do with more than one instance or peer on the same interface… not sure if thats related or not. It seems like the last one to come up won.
The essence of what we are trying to solve is that there are links on the network that are full and others that COULD be used that are not used because OSPF is incapable of utilizing multiple paths unless they are ECMP. That being said, BGP “steering” of traffic flows over diverse paths will allow for the full utilization of all available bandwidth. In trying to get this to work, I have tried using one IP per peering and I have tried it with one loopback for peering for all peers. Both approaches end up with the same result. That being that when I set the “next hop” via BGP, I am still seeing the community string that says “use path X”, even when the network doesn’t know how to reach the next hop for that path. Another side effect is that OSPF is finding a path to the peering IPs around the network and I end up getting the path to work, but doubling the utilization on some links…sigh.
Still - I read your post as you trying to connect BGP’s trough ospf learned path. R1 connect to R2 - but it know about R2 couse of OSPF learned routes. Its not l2 since you have the loopback ip connecting.
if you run bgp with confederation, MPLS and vpnv4/l2tp-cisco you will get the routing table trough bgp in a MPLS setup, and can use Traffic engineering to have multiple path’s from Router to router, and eventually - combine traffic. I run this setup - compbined by a ospf learned core for failover and VPLS - and it worked werry well. Still i always used LACP to bound dual l2 links - like doble licenced radios, multiple sfp’s etc. But for the l3 routes from eBGP and NAS’es around in the core - i used BGP IPV4, with vrf at endpoint and with confederation inside " MPLS cloud", to have different AS at each bgp router.
