[vpp-dev] FD.io CI Outage has been resolved
Folks, Sorry for the late notice, but I've been meeting bound while troubleshooting today's FD.io CI outage. There was a network configuration change in the Vexxhost datacenter that cause the public IP address of jenkins to become inaccessible from the Nomad cluster causing all jobs to fail. This has been resolved. Another issue still remains, that is why the external address was being used. It was determined that Jenkins was configured this way in the a portion of the cloud configuration even though Jenkins was configured to use the internal IP address in the global configuration variables. Unfortunately updating the cloud configuration failed to work after the network issues were resolved and restoring the cloud configuration to use jenkins.fd.io resolved the issue. Given today's outage, I have recommended that Andrew push back the VPP 21.10 branch pull to Thursday 9/23/2021. Kudo's to Peter Mikus for identifying the root cause of the outage, Vanessa Valderrama for assisting during a PTO day to manage Jenkins configuration changes & restarts, and Anton Baranov & Mohammed Naser for fixing the data center network configuration. Thanks, -daw- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20174): https://lists.fd.io/g/vpp-dev/message/20174 Mute This Topic: https://lists.fd.io/mt/85775812/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] DPDK initialization issues
[Edited Message Follows] " That looks suspicious for sure... Can you try with VPP native virtio driver instead of DPDK? " Hi Ben, Thank you. How do I enable that? I dint compile the VPP code. I just installed the VPP packages on VM and trying to test the IPSEC config. Regards, Satish Amara -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20173): https://lists.fd.io/g/vpp-dev/message/20173 Mute This Topic: https://lists.fd.io/mt/84979398/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] DPDK initialization issues
Hi Ben, Thank you. How do I enable that? I dint compile the VPP code. I just installed the VPP packages on VM and trying to test the IPSEC config. Regards, Satish Amara -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20173): https://lists.fd.io/g/vpp-dev/message/20173 Mute This Topic: https://lists.fd.io/mt/84979398/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] config 1G hugepage
Hoi Mohsen, I'm probably not the right person to answer :) but in a previous post ( https://lists.fd.io/g/vpp-dev/message/19643) the semantics of hugepages came up, from there (relaying what people smarter than I have answered) - VPP will claim the hugepage on startup, so it'll reserve them for itself from the beginning. - You could take a look at that directory you mentioned before, to see how many pages are available in the system, how many are used by VPP (by comparing a before-and-after): pim@hippo:/sys/devices/system/node/node0/hugepages$ find . . ./hugepages-2048kB ./hugepages-2048kB/free_hugepages ./hugepages-2048kB/surplus_hugepages ./hugepages-2048kB/nr_hugepages ./hugepages-1048576kB ./hugepages-1048576kB/free_hugepages ./hugepages-1048576kB/surplus_hugepages ./hugepages-1048576kB/nr_hugepages For example like so: pim@hippo:/sys/devices/system/node/node0/hugepages$ cat ./hugepages-2048kB/free_hugepages 3072 pim@hippo:/sys/devices/system/node/node0/hugepages$ sudo systemctl start vpp pim@hippo:/sys/devices/system/node/node0/hugepages$ cat ./hugepages-2048kB/free_hugepages 1623 So on this machine, 1449 2MB hugepages were claimed upon startup by this instance of VPP. Hope that helps - I'll leave other folks to give better answers :) groet, Pim On Tue, Sep 21, 2021 at 8:12 PM Mohsen Meamarian wrote: > Hi, > Thanks, Is there a way to make sure how many Hugespages are ready to Vpp > using? Immediately after Start Vpp, I open the "/ run / vpp / hugepages " > file but it is empty. Is the VPP mechanism to occupy the Hugepage if needed > or does Vpp reserve it for itself from the beginning? > > > -- Pim van Pelt PBVP1-RIPE - http://www.ipng.nl/ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20172): https://lists.fd.io/g/vpp-dev/message/20172 Mute This Topic: https://lists.fd.io/mt/85744775/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] config 1G hugepage
Hi, Thanks, Is there a way to make sure how many Hugespages are ready to Vpp using? Immediately after Start Vpp, I open the "/ run / vpp / hugepages " file but it is empty. Is the VPP mechanism to occupy the Hugepage if needed or does Vpp reserve it for itself from the beginning? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20171): https://lists.fd.io/g/vpp-dev/message/20171 Mute This Topic: https://lists.fd.io/mt/85744775/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] VPP vnet event for route/FIB table update?
Hi We have an application that requires to be notified when a FIB table is updated. Is there any VPP event API (an equivalent of NETLINK_ROUTE ) to monitor FIB table updates? Thank you very much - Pranab Das -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20170): https://lists.fd.io/g/vpp-dev/message/20170 Mute This Topic: https://lists.fd.io/mt/85763142/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IPv6 unnumbered interface
Artem, That seems to be a bug in the source address selection routine used by ND. An NS should not be sent out an interface with an address from another interface. In this case it should have sent the ND with the link-local address as source. In IPv6, there is really no such thing as unnumbered. The unnumbered statement should just be a hint to the SAS algorithm to pick an address from that interface. Best regards, Ole > On 17 Sep 2021, at 12:21, Artem Glazychev wrote: > > Hi Neale, > > Thanks a lot, it really helped! > > But I used: > > enable ip6 interface memif0/0 > > in addition to: > > set int unnumbered memif0/0 use loop0 > > Otherwise, ping from vpp2 to vpp1 doesn't work. > > So, I moved on. > > Next problem > > If I use unnumbered IPv6 interface with a custom vrf table - ping doesn't > work. > > Configuration: > > vpp1: > > create interface memif id 0 master > set int ip address memif0/0 fc00::1/120 > set int state memif0/0 up > > vpp2: > create loopback interface > create interface memif id 0 slave > ip6 table add 1 > set int ip6 table loop0 1 > set int ip6 table memif0/0 1 > set int unnumbered memif0/0 use loop0 > enable ip6 interface memif0/0 > ip route add fc00::1/128 via memif0/0 > set int state memif0/0 up > set int ip address loop0 fc00::2/120 > set int state loop0 up > > trace add memif-input 10 > vpp1: ping fc00::2 > > Traces: > > Packet 1 > > 00:00:28:149948: memif-input > memif: hw_if_index 2 next-index 4 > slot: ring 0 > 00:00:28:149959: ethernet-input > IP6: 02:fe:92:6a:0b:42 -> 33:33:00:00:00:01 > 00:00:28:149965: ip6-input > ICMP6: fe80::fe:92ff:fe6a:b42 -> ff02::1 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP router_advertisement checksum 0xd248 > 00:00:28:149969: ip6-mfib-forward-lookup > fib 0 entry 11 > 00:00:28:149973: ip6-mfib-forward-rpf > entry 11 itf 2 flags Accept, > 00:00:28:149975: ip6-replicate > replicate: 8 via [@1]: dpo-receive > 00:00:28:149979: ip6-local > fib:1 adj:8 flow:0 > ICMP6: fe80::fe:92ff:fe6a:b42 -> ff02::1 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP router_advertisement checksum 0xd248 > 00:00:28:149985: ip6-icmp-input > ICMP6: fe80::fe:92ff:fe6a:b42 -> ff02::1 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP router_advertisement checksum 0xd248 > 00:00:28:149987: icmp6-router-advertisement > ICMP6: fe80::fe:92ff:fe6a:b42 -> ff02::1 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP router_advertisement checksum 0xd248 > 00:00:28:149993: ip6-drop > fib:1 adj:8 flow:0 > ICMP6: fe80::fe:92ff:fe6a:b42 -> ff02::1 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP router_advertisement checksum 0xd248 > 00:00:28:149995: error-drop > rx:memif0/0 > 00:00:28:14: drop > ip6-icmp-input: valid packets > > Packet 2 > > 00:00:28:875034: memif-input > memif: hw_if_index 2 next-index 4 > slot: ring 0 > 00:00:28:875040: ethernet-input > IP6: 02:fe:92:6a:0b:42 -> 33:33:ff:00:00:02 > 00:00:28:875047: ip6-input > ICMP6: fc00::1 -> ff02::1:ff00:2 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP neighbor_solicitation checksum 0xe0ed > target address fc00::2 > 00:00:28:875049: ip6-mfib-forward-lookup > fib 0 entry 9 > 00:00:28:875053: ip6-mfib-forward-rpf > entry 9 itf 2 flags Accept, > 00:00:28:875059: ip6-replicate > replicate: 6 via [@1]: dpo-receive > 00:00:28:875063: ip6-local > fib:1 adj:6 flow:0 > ICMP6: fc00::1 -> ff02::1:ff00:2 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP neighbor_solicitation checksum 0xe0ed > target address fc00::2 > 00:00:28:875068: ip6-icmp-input > ICMP6: fc00::1 -> ff02::1:ff00:2 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP neighbor_solicitation checksum 0xe0ed > target address fc00::2 > 00:00:28:875071: icmp6-neighbor-solicitation > ICMP6: fc00::1 -> ff02::1:ff00:2 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP neighbor_solicitation checksum 0xe0ed > target address fc00::2 > 00:00:28:875076: ip6-drop > fib:1 adj:6 flow:0 > ICMP6: fc00::1 -> ff02::1:ff00:2 > tos 0x00, flow label 0x0, hop limit 255, payload length 32 > ICMP neighbor_solicitation checksum 0xe0ed > target address fc00::2 > 00:00:28:875078: error-drop > rx:memif0/0 > 00:00:28:875079: drop > ip6-icmp-input: neighbor solicitations from source not on link > We can see an error: neighbor solicitations from source not on link > > Additionally, if it helps: > > DBGvpp# show mfib entry > FIB Entries: > 0@(*, 0.0.0.0/0): flags:Drop, > Interfaces: > multicast-ip4-chain > [@0]: dpo-drop ip4 > 1@(*, 224.0.0.1/32): > Interfaces: > multicast-ip4-chain > [@1]: dpo-replicate: [index:0 buckets:1 flags:[has-local ] to:[0:0]] > [0] [@1]: dpo-receive > 2@(*, 224.0.0.2/32): > Interfaces: > multicast-ip4-chai
Re: [vpp-dev] Advertising prefixes in VPP fib via BGP
Hoi, (straying off topic, but) - If I set an IP address, or MTU, or admin-state on an interface, using the VPP API or CLI, I would expect that to show up in Linux as well. If VPP does not propagate this state, I have two choices: 1) do not (ever) use VPP to manipulate these things, but purely rely on netlink; 2) set the state twice, once in VPP and once again in Linux Doing that will expose a few subtle issues; Some examples: a) creating a Bond (create bond), exposing it in LCP (lcp create), and then adding an interface to the bond (bond add); VPP will change the MAC address of the Bond to that of the first joined interface. Linux will not know of it. b) creating a sub-int, and changing its MTU to 9216, then changing its phy to MTU 9000 is valid in VPP; Linux will not be able to cope with this (sub-ints must be capped at their parent's MTU) c) VRRP may be running and transition state, removing or adding the VIP. Linux will not be aware of this. d) Wireguard adds/removes a peer, which exposes a new prefix from their allowed-ip list; this effectively becomes a route into the wireguard interface. These routes will be invisible to Linux. There will be several cases in which a plugin or possibly vnet itself will make a change to an interface or the FIB on our behalf. One might argue it's indeed desirable to reflect those changes, otherwise users will continuously be confused by functionality that works in VPP-proper, but doesn't work or has unexpected side effects in VPP-LinuxCP. groet, Pim On Tue, Sep 21, 2021 at 4:47 AM Jim Thompson wrote: > > > > On Sep 20, 2021, at 5:07 PM, Pim van Pelt wrote: > > > > Matt: this is one of those places where having, in general, a sync from > VPP -> Linux would be useful. > > I think this is somewhat inadvisable. To quote someone else on-list, “VPP > is not your control plane”. > > Jim > > -- Pim van Pelt PBVP1-RIPE - http://www.ipng.nl/ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20168): https://lists.fd.io/g/vpp-dev/message/20168 Mute This Topic: https://lists.fd.io/mt/85736384/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
