Hi Mike, The first problem you mentioned (packets matching a route are not sent when the next hop has not been resolved at the time the route is added) is likely fixed by this patch:
e2353a7f6 linux-cp: Add delegate to adjacencies It was merged after fd77f8c00, so you would either need to cherry-pick it or rebase onto that commit or some more recent one on master. I have heard another report of the second issue you mentioned (changing default netns does not work correctly) but I haven't gotten time to look at it yet. Thanks, -Matt On Thu, May 27, 2021 at 6:59 PM Mike Beattie <m...@ethernal.org> wrote: > On Thu, May 27, 2021 at 11:36:02AM +0200, Pim van Pelt wrote: > > Hoi Nate, > > > > further to what Andrew suggested, there are a few more hints I can offer: > > .... > > Then you should be able to consume the IPv4 and IPv6 DFZ in your router. > I > > tested extensively with FRR and Bird2, and so far had good success. > > Pim, thank you for those hints - I plan to be implementing a new core > routing infrastructure using VPP & FRR w/ linux-cp & linux-nl that will be > consuming full tables in the near future. Your hints will be invaluable I > susect. > > However, in my testing, I discovered an interesting behaviour with regards > to routing. I have previously tried to reply with my findings to the list, > but I wasn't subscribed at the time of Neale's posts, and I wanted to > continue on his thread ... I composed a detailed report on the web > interface > of the list, then managed to completely miss the "CC list" checkbox. So I > think Neale got it himself only. (Sorry Neale). > > I digress... what I discovered was that if a route entry is created before > a > neighbor entry with the next hop is established, no traffic flows: > > > root@vpp-test:~# ip netns exec dataplane bash > root@vpp-test:~# systemctl restart vpp.service > root@vpp-test:~# vppctl set interface mtu 1500 GigabitEthernet0/13/0 > root@vpp-test:~# vppctl lcp create GigabitEthernet0/13/0 host-if vpp1 > netns dataplane > root@vpp-test:~# ip l > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode > DEFAULT group default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > root@vpp-test:~# ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 15: vpp1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default > qlen 1000 > link/ether 32:dc:fa:93:9e:fe brd ff:ff:ff:ff:ff:ff > root@vpp-test:~# cat init50.sh > #!/bin/sh > > ip link set up dev vpp1 > > ip link add link vpp1 vpp1.50 type vlan id 50 > ip link set up dev vpp1.50 > ip addr add 10.xxx.yyy.202/24 dev vpp1.50 > > root@vpp-test:~# ./init50.sh > root@vpp-test:~# ping 1.1.1.1 > ping: connect: Network is unreachable > root@vpp-test:~# ip route add default via 10.xxx.yyy.254 > root@vpp-test:~# ping 1.1.1.1 > PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. > ^C > --- 1.1.1.1 ping statistics --- > 5 packets transmitted, 0 received, 100% packet loss, time 4077ms > > root@vpp-test:~# ping 10.xxx.yyy.254 > PING 10.xxx.yyy.254 (10.xxx.yyy.254) 56(84) bytes of data. > ^C > --- 10.xxx.yyy.254 ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 3070ms > > root@vpp-test:~# ip route delete default > root@vpp-test:~# ping 10.xxx.yyy.254 > PING 10.xxx.yyy.254 (10.xxx.yyy.254) 56(84) bytes of data. > ^C > --- 10.xxx.yyy.254 ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 3062ms > > > > No traffic passed... ping router before adding route: > > > > root@vpp-test:~# systemctl restart vpp.service > root@vpp-test:~# ./init50.sh > root@vpp-test:~# ping 10.xxx.yyy.254 > PING 10.xxx.yyy.254 (10.xxx.yyy.254) 56(84) bytes of data. > 64 bytes from 10.xxx.yyy.254: icmp_seq=1 ttl=64 time=0.780 ms > 64 bytes from 10.xxx.yyy.254: icmp_seq=2 ttl=64 time=0.306 ms > 64 bytes from 10.xxx.yyy.254: icmp_seq=3 ttl=64 time=0.310 ms > ^C > --- 10.xxx.yyy.254 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2038ms > rtt min/avg/max/mdev = 0.306/0.465/0.780/0.222 ms > root@vpp-test:~# ip route add default via 10.xxx.yyy.254 > root@vpp-test:~# ping 1.1.1.1 > PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. > 64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=23.5 ms > 64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=23.9 ms > ^C > --- 1.1.1.1 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1002ms > rtt min/avg/max/mdev = 23.541/23.710/23.879/0.169 ms > root@vpp-test:~# > > > Traffic passes fine. > > This is a basic VPP installation built with > https://gerrit.fd.io/r/c/vpp/+/31122 rebased onto master of a couple weeks > ago (fd77f8c00). Ping plugin disabled, linux-cp and linux-nl enabled, with > linux-cp config of: > > linux-cp { > default netns dataplane > interface-auto-create > } > > Normally, this behaviour wouldn't be an issue, as a neighbor relationship > with the nexthop will be created with the BGP converstion that would cause > routes to be created that use that nexthop - however, that's not the case > with Route Reflectors that I plan on implementing. OSPF will be used in the > implementation which might mitigate the problem - I hadn't gotten that far > in testing. However, I figured that if this is a real bug, then it's worth > fixing. > > > There were a couple of other feedback items for the linux-nl plugin that > I'd > written to Neale in the web form for the list, but I can only recall one of > them - the default netns has to be specified in the config file, you can't > use the command: > > # vppctl lcp default netns dataplane > > As the netlink listener doesn't appear to be re-created in that netns > dynamically. > > Of course, I'm new to VPP as well, so if I'm doing something stupid, please > let me know! > > Mike. > -- > Mike Beattie <m...@ethernal.org> > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19500): https://lists.fd.io/g/vpp-dev/message/19500 Mute This Topic: https://lists.fd.io/mt/83138237/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
