[dev] Recursive lookup through BGP-LU route
Donald Sharp
sharpd at cumulusnetworks.com
Tue Jun 26 08:11:38 EDT 2018
Can we get the output of `show ip route`, `show ip route
10.112.129.9`, `show mpls fec`, and `show mpls table`?
donald
On Mon, Jun 25, 2018 at 3:45 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:
> Hi,
>
> We're experimenting with BGP-LU and frr in our lab. We have two host
> machines running frr. Each is connected to two TOR switches through their
> eth0 and eth1 links (four TORs total). Those are connected through another
> pair of switches. We have configured BGP-LU to distribute MPLS labels over
> ebpg throughout. Connectivity between loopback addresses on the two hosts
> works well at this point.
>
> Then, I created some namespaces in the hosts and gave them addresses. We use
> BGP to announce those addresses as /32 routes with the loopback address as
> the next hop. The route between namespaces on the two machines is
> recursively resolved so that they push the same MPLS label as the path to
> the other loopback. This all works well to start off with and we did some
> iperf runs that showed pretty good results. ECMP was working because the
> bandwidth was higher than any single link.
>
> After some link state changes, we seemed to lose the connection. However,
> pings between the loopback addresses still worked. After some time, we
> noticed that the MPLS labels in the routes to the namespace addresses (/32s)
> were different than the label in the route to the loopback. Since the former
> routes are resolved recursively using the latter, the labels should always
> be the same. Could this be a bug in FRR? Shouldn't the routes to the
> namespaces be invalidated or updated as soon as the route it was based on
> changed? The traffic between namespaces is getting dropped because the
> switch doesn't know about the label being pushed by the host.
>
> Any insight would be very helpful.
>
> Thanks!
> Carl Baldwin
>
> Here are /32 routes received. 10.112.128.1 is the loopback on the other
> host. The four routes are to four namespaces on the other host.
>
> lab1r2u05# show ip bgp neighbor 10.112.97.1 received-routes
> BGP table version is 0, local router ID is 10.112.128.2
> Status codes: s suppressed, d damped, h history, * valid, > best, =
> multipath,
> i internal, r RIB-failure, S Stale, R Removed
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> Network Next Hop Metric LocPrf Weight Path
> *> 10.224.12.10/32 10.112.128.1 0 4206900001
> 4206909998 i
> *> 10.224.12.15/32 10.112.128.1 0 4206900001
> 4206909998 i
> *> 10.224.12.70/32 10.112.128.1 0 4206900001
> 4206909998 i
> *> 10.224.12.75/32 10.112.128.1 0 4206900001
> 4206909998 i
>
> Total number of prefixes 4
>
> Below is the routing table as it looked when we lost connectivity. Notice
> that the mpls label for the loopback route is 306592 via eth1 but the label
> for the four namespace addresses is 306576.
>
> root at lab1r2u05:~/ovs-droplets# ip route
> default via 10.112.2.132 dev eth2
> 10.112.2.128/25 dev eth2 proto kernel scope link src 10.112.2.145
> 10.112.128.1 encap mpls 306592 via 10.112.129.9 dev eth1 proto 186
> metric 20
> 10.112.129.8/30 dev eth1 proto kernel scope link src 10.112.129.10
> 10.112.129.12/30 dev eth0 proto kernel scope link src 10.112.129.14
> 10.224.12.10 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186
> metric 20
> 10.224.12.15 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186
> metric 20
> 10.224.12.70 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186
> metric 20
> 10.224.12.75 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186
> metric 20
> 10.224.12.20 dev br0 scope link
> 10.224.12.25 dev br0 scope link
> 10.224.12.80 dev br0 scope link
> 10.224.12.85 dev br0 scope link
>
>
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev
>
More information about the dev
mailing list