And here is `ip route` after bringing the link from eth0 up again. It still lines up with the `show ip route` output I sent earlier.

Carl

    root@lab1r1u05:~/ovs-droplets# ip route
    default via 10.112.2.4 dev eth2
    10.112.2.0/25 dev eth2  proto kernel  scope link  src 10.112.2.15
    10.112.97.1  proto 186  metric 20
            nexthop encap mpls  696097  via 10.112.129.1  dev eth1 weight 1
            nexthop encap mpls  46  via 10.112.129.5  dev eth0 weight 1
    10.112.128.2  proto 186  metric 20
            nexthop encap mpls  702241  via 10.112.129.1  dev eth1 weight 1
            nexthop encap mpls  564  via 10.112.129.5  dev eth0 weight 1
    10.112.129.0/30 dev eth1  proto kernel  scope link  src 10.112.129.2
    10.112.129.4/30 dev eth0  proto kernel  scope link  src 10.112.129.6
    10.112.129.8/30 via 10.112.129.1 dev eth1
    10.224.12.10 dev br0  scope link
    10.224.12.15 dev br0  scope link
    10.224.12.20  proto 186  metric 20
            nexthop encap mpls  702161  via 10.112.129.1  dev eth1 weight 1
            nexthop encap mpls  560  via 10.112.129.5  dev eth0 weight 1
    10.224.12.25  proto 186  metric 20
            nexthop encap mpls  702161  via 10.112.129.1  dev eth1 weight 1
            nexthop encap mpls  560  via 10.112.129.5  dev eth0 weight 1
    10.224.12.70 dev br0  scope link
    10.224.12.75 dev br0  scope link
    10.224.12.80  proto 186  metric 20
            nexthop encap mpls  702161  via 10.112.129.1  dev eth1 weight 1
            nexthop encap mpls  560  via 10.112.129.5  dev eth0 weight 1
    10.224.12.85  proto 186  metric 20
            nexthop encap mpls  702161  via 10.112.129.1  dev eth1 weight 1
            nexthop encap mpls  560  via 10.112.129.5  dev eth0 weight 1
    100.64.0.0/24 dev br0  proto kernel  scope link  src 100.64.0.1

On Tue, Jun 26, 2018 at 6:11 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
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
>