[FROG] Recursive lookup through BGP-LU route

[Carl Baldwin]

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

PS Below are a few screen captures that I copied before restarting FRR to
get things back.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20180621/b792ddbc/attachment.html>