Awesome, It works. Great job..... many thanks to you.
Regards Petr st 26. 5. 2021 v 22:02 odesílatel Matthew Smith <[email protected]> napsal: > > 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 (#19478): https://lists.fd.io/g/vpp-dev/message/19478 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]] -=-=-=-=-=-=-=-=-=-=-=-
