[dev] Recursive lookup through BGP-LU route
Carl Baldwin
carl at ecbaldwin.net
Tue Jun 26 18:01:08 EDT 2018
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 at 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 at 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 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20180626/5878c6a3/attachment.html>
More information about the dev
mailing list