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@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@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@lists.frrouting.org https://lists.frrouting.org/listinfo/dev