Hi Petr, My earlier statement that multicast should work with no additional configuration required was wrong. That's only true if you have the netlink listener patch (https://gerrit.fd.io/r/c/vpp/+/31122) applied. I have that applied to my local builds and I incorrectly thought it was part of the linux-cp code that had already been merged to master. Sorry for the confusion.
To punt multicast packets arriving on GigabitEthernet3/0/0 to the host, I think you can run these commands: vppctl ip mroute add 224.0.0.0/24 via local Forward vppctl ip mroute add 224.0.0.0/24 via GigabitEthernet3/0/0 Accept The explanation of the purpose of those commands that I received a while back was "In mfib you need to specify both where the traffic can come from (via an Accept path) so it passes the RPF check and where it's going to (via a Forward path)". -Matt On Wed, May 26, 2021 at 1:40 PM Petr Boltík <[email protected]> wrote: > Hi, > thank you ..... answers are inline below. > > Predispositions > The host is apu4d4 + Debian 10.9 + bird 1.66 (old, but in repo), clear > install + VPP 21.06-rc1~0-ge82d59f38~b1 (10.10.50.1/24). The opposite > side is MikroTik rb4011 (10.10.50.2/24). There is no disabled plugins, > only enabled linux-cp. > > st 26. 5. 2021 v 19:08 odesílatel Matthew Smith <[email protected]> > napsal: > >> Hi Petr, >> >> Responses are inline... >> >> On Wed, May 26, 2021 at 10:23 AM <[email protected]> wrote: >> >>> Hello, >>> >>> I'm sorry for the beginner question, but I was unable to find the >>> answer. I tested the linux-cp feature in VPP 21.10-rc0. Nice job, but I >>> cannot get to work ospf multicast, probably I'm doing something wrong, or >>> should it work? >>> >> >> >> Multicast should work without any special configuration. >> >> What is the output of 'vppctl show ip mfib 224.0.0.0/24' after you apply >> your linux-cp and interface configurations? >> > > There is first interesting point. There is no mbib route for 224.0.0.0/24 > > vpp# show ip mfib 224.0.0.0/24 > ipv4-VRF:0, fib_index:0 flags:none > (*, 0.0.0.0/0): flags:Drop, > fib:0 index:0 locks:1 > src:Default Route flags:none locks:1: flags:Drop, > Extensions: > Interface-Forwarding: > Interfaces: > multicast-ip4-chain > [@0]: dpo-drop ip4 > > > >> >> >>> >>> BGP communication works fine (tcp), OSPF NBMA works fine. >>> Communication from host to physical interface already passes (224.0.0.5). >>> Communication from the physical interface to the host did not pass >>> (224.0.0.5). >>> >>> >> >> What did you observe while determining that inbound multicast was not >> being passed to the host? Did you run a packet trace and confirm that the >> packets are arriving on the VPP hardware interface? If so, can you please >> send trace output for 1 or 2 of the inbound multicast packets? If not, you >> can run a trace via a sequence of commands like: >> >> vppctl clear trace >> vppctl trace filter include ip4-mfib-forward-lookup 100 >> vppctl trace add dpdk-input 100 >> sleep 10 >> vppctl show trace >> > > Packets successfully arrived from physical interface .... ip4-input report > several problems: > Step 1: > > Packet 3 > 00:11:11:019194: dpdk-input > GigabitEthernet3/0/0 rx queue 0 > buffer 0x9c0c2: current data 0, length 82, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x2 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 1, nb_segs 1, pkt_len 82 > buf_len 2176, data_len 82, ol_flags 0x180, data_off 128, phys_addr > 0x72103100 > packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid > Packet Types > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > IP4: b8:69:f4:99:85:40 -> 01:00:5e:00:00:05 > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 1, length 68, checksum 0x1214 dscp CS6 ecn NON_ECN > fragment id 0x8a7c > 00:11:11:019235: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP4: b8:69:f4:99:85:40 -> 01:00:5e:00:00:05 > 00:11:11:019250: ip4-input-no-checksum > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 1, length 68, checksum 0x1214 dscp CS6 ecn NON_ECN > fragment id 0x8a7c > 00:11:11:019258: ip4-mfib-forward-lookup > fib 0 entry 0 > 00:11:11:019268: ip4-mfib-forward-rpf > entry 0 itf -1 flags > 00:11:11:019273: ip4-drop > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 1, length 68, checksum 0x1214 dscp CS6 ecn NON_ECN > fragment id 0x8a7c > 00:11:11:019276: error-drop > rx:GigabitEthernet3/0/0 > 00:11:11:019281: drop > ip4-input: *Multicast RPF check failed* > > > *==> vppctl ip mroute add 0.0.0.0/0 <http://0.0.0.0/0> AA* > Step 2: > > Packet 2 > > 00:15:51:052464: dpdk-input > GigabitEthernet3/0/0 rx queue 0 > buffer 0x9ccf2: current data 0, length 82, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x1 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 1, nb_segs 1, pkt_len 82 > buf_len 2176, data_len 82, ol_flags 0x180, data_off 128, phys_addr > 0x72133d00 > packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid > Packet Types > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > IP4: b8:69:f4:99:85:40 -> 01:00:5e:00:00:05 > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 1, length 68, checksum 0x11f8 dscp CS6 ecn NON_ECN > fragment id 0x8a98 > 00:15:51:052515: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP4: b8:69:f4:99:85:40 -> 01:00:5e:00:00:05 > 00:15:51:052533: ip4-input-no-checksum > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 1, length 68, checksum 0x11f8 dscp CS6 ecn NON_ECN > fragment id 0x8a98 > 00:15:51:052541: ip4-mfib-forward-lookup > fib 0 entry 0 > 00:15:51:052550: ip4-mfib-forward-rpf > entry 0 itf -1 flags > 00:15:51:052554: ip4-drop > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 1, length 68, checksum 0x11f8 dscp CS6 ecn NON_ECN > fragment id 0x8a98 > 00:15:51:052558: error-drop > rx:GigabitEthernet3/0/0 > 00:15:51:052563: drop > null-node: *blackholed packets* > > > ==> * ip mroute 0.0.0.0/0 <http://0.0.0.0/0> via tap2 Forward* > > show errors > Count Node Reason > Severity > 1 ip4-input ip4 ttl <= 1 > error > 1 ip4-icmp-error hop limit exceeded response > sent error > > > Packet 22 > 00:19:11:072911: dpdk-input > GigabitEthernet3/0/0 rx queue 0 > buffer 0x9d1d2: current data 0, length 82, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x15 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 1, nb_segs 1, pkt_len 82 > buf_len 2176, data_len 82, ol_flags 0x180, data_off 128, phys_addr > 0x72147500 > packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid > Packet Types > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > IP4: b8:69:f4:99:85:40 -> 01:00:5e:00:00:05 > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 1, length 68, checksum 0x11e4 dscp CS6 ecn NON_ECN > fragment id 0x8aac > 00:19:11:072951: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP4: b8:69:f4:99:85:40 -> 01:00:5e:00:00:05 > 00:19:11:072969: ip4-input-no-checksum > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 1, length 68, checksum 0x11e4 dscp CS6 ecn NON_ECN > fragment id 0x8aac > 00:19:11:072980: ip4-mfib-forward-lookup > fib 0 entry 0 > 00:19:11:072992: ip4-mfib-forward-rpf > entry 0 itf -1 flags > 00:19:11:072997: ip4-replicate > replicate: 6 via [@2]: ipv4-mcast: tap2: mtu:9000 next:6 flags:[] > 01005e00000002fe16852e1e0800 > 00:19:11:073004: ip4-rewrite-mcast > tx_sw_if_index 0 dpo-idx 6 : ipv4-mcast: tap2: mtu:9000 next:6 flags:[] > 01005e00000002fe16852e1e0800 flow hash: 0x0000000b > 00000000: > 45c000448aac0000005912e40a0a3202e0000005020100300808080800000000 > 00000020: 864800016865736c6f000000ffffff00000a0201000000280a0a3202 > 00:19:11:073010: ip4-icmp-error > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 0, length 68, checksum 0x12e4 dscp CS6 ecn NON_ECN > fragment id 0x8aac > 00:19:11:073039: ip4-drop > OSPF: 10.10.50.2 -> 224.0.0.5 > tos 0xc0, ttl 0, length 68, checksum 0x12e4 dscp CS6 ecn NON_ECN > fragment id 0x8aac > > > > *00:19:11:073060: error-drop rx:GigabitEthernet3/0/000:19:11:073071: > drop ip4-input: ip4 ttl <= 1* > > > *==> ip mroute 0.0.0.0/0 <http://0.0.0.0/0> via GigabitEthernet3/0/0 > Forward* > > > *vpp# show errors * Count Node > Reason Severity > 1 lldp-input lldp packets received on > disabled i error > 2 dpdk-input no error > error > 12 ip4-input ip4 ttl <= 1 > error > 12 ip4-input ip4 egress interface same as > ingres error > 24 ip4-icmp-error hop limit exceeded response > sent error > 1 snap-input unknown oui/snap > protocol error > > > >> >> Several possible outcomes based on the trace output: >> >> 1. No multicast packets arrive on the hardware interface. That would >> obviously be a problem with the external network rather than VPP or >> linux-cp. >> 2. Multicast packets arrive on the hardware interface and the trace shows >> them being dropped during some phase of processing. Hopefully there would >> be some indication of why they are being dropped in the trace output or in >> the output of 'vppctl show errors'. >> 3. Multicast packets arrive on the hardware interface and the trace shows >> them being transmitted on the host tap interface. If that is the case, does >> 'tcpdump -i ge300' on the host show any packets arriving? Are you running >> any kernel-based packet filter like iptables or nftables on the host? >> >> > ad 1. Packets arrived on the GigabitEthernet3/0/0 > ad 2. Some outputs you can see upper > ad 3. tcpdump -i ge300 show arrived icmp, tcp but no packet is > received from the opposite ospf process. > > > Thanks > Petr > > Thanks, >> -Matt >> >> >> Is there any way how to configure multicast redirect? A have tried a lot >>> of configurations (ip mroute, ....) with no success. >>> Many thanks for your answers. Regards Petr >>> >>> example configuration (enable linux-cp plugin) >>> # vpp >>> set int ip address GigabitEthernet3/0/0 10.10.50.1/24 >>> set int state GigabitEthernet3/0/0 up >>> lcp create GigabitEthernet3/0/0 host-if ge300 >>> # linux host >>> ip addr add 10.10.50.1/24 dev ge300 >>> ip link set dev ge300 mtu 1500 >>> ip link set dev ge300 up >>> >>> >>> >>> >>> >>> >>>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19477): https://lists.fd.io/g/vpp-dev/message/19477 Mute This Topic: https://lists.fd.io/mt/83103366/21656 Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp Mute #plugin:https://lists.fd.io/g/vpp-dev/mutehashtag/plugin Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
