I think we already confirm that kea is sending the DHCP OFFER to the vBNG right ? its jsut not making it from the vBNG to the vBRGEMU
Brian From: [email protected] <[email protected]> Sent: Monday, August 26, 2019 1:12 PM To: 'Multanen, Eric W' <[email protected]>; FREEMAN, BRIAN D <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Cc: [email protected]; PLATANIA, MARCO <[email protected]>; 'Bartlomiej Grzybowski' <[email protected]> Subject: RE: [onap-discuss] vCPE usecase: DHCP issue Tap interfaces looks to be up, 10.3.0.1 on BNG looks correct … just 10.3.0.2 on BRG is missing please see attached info collected from BRG and BNG, Maybe you will see something I don’t see … Thanks a lot for your support, Michal From: Multanen, Eric W <[email protected]<mailto:[email protected]>> Sent: Monday, August 26, 2019 6:41 PM To: FREEMAN, BRIAN D <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; PLATANIA, MARCO <[email protected]<mailto:[email protected]>>; 'Bartlomiej Grzybowski' <[email protected]<mailto:[email protected]>> Subject: RE: [onap-discuss] vCPE usecase: DHCP issue you can check in the vBNG: vppctl show ip fib to verify that routing info is correct. From: FREEMAN, BRIAN D <[email protected]<mailto:[email protected]>> Sent: Monday, August 26, 2019 11:33 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; PLATANIA, MARCO <[email protected]<mailto:[email protected]>>; Multanen, Eric W <[email protected]<mailto:[email protected]>>; 'Bartlomiej Grzybowski' <[email protected]<mailto:[email protected]>> Subject: RE: [onap-discuss] vCPE usecase: DHCP issue Its the tunnel-tap between the BRG and the BNG. There is also a routing function in the BNG that needs to be up. So I would be looking inside vppctl vpp# show interface Name Idx State Counter Count GigabitEthernet0/4/0 1 up rx packets 14078 rx bytes 1864486 tx packets 2605 tx bytes 830306 drops 11477 ip4 2602 ip6 11471 GigabitEthernet0/6/0 2 up rx packets 13201 rx bytes 1741980 tx packets 2594 tx bytes 876510 drops 10608 ip4 2593 ip6 10606 GigabitEthernet0/7/0 3 up rx packets 11477 rx bytes 986884 tx packets 1 tx bytes 60 drops 11476 ip6 11472 local0 0 down tap-0 4 up rx packets 22 rx bytes 1908 tx packets 10 tx bytes 796 drops 20 ip4 12 ip6 8 vpp# show interface address GigabitEthernet0/4/0 (up): 10.3.0.1/24 GigabitEthernet0/6/0 (up): 10.4.0.3/24 GigabitEthernet0/7/0 (up): 10.1.0.10/24 local0 (dn): tap-0 (up): 192.168.40.41/24 brg emu vpp# show interface Name Idx State Counter Count GigabitEthernet0/4/0 1 up rx packets 14359 rx bytes 1841816 tx packets 2605 tx bytes 878406 drops 11764 ip4 2595 ip6 11752 local0 0 down tap-0 2 up rx packets 5 rx bytes 390 drops 8 tap-1 3 up rx packets 9 rx bytes 754 drops 8 ip4 7 ip6 2 vpp# show interface address GigabitEthernet0/4/0 (up): 10.3.0.2/24 local0 (dn): tap-0 (up): l2 bridge bd_id 10 shg 0 tap-1 (up): 20.0.0.40/24 From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of Michal Ptacek via Lists.Onap.Org Sent: Monday, August 26, 2019 10:43 AM To: FREEMAN, BRIAN D <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; PLATANIA, MARCO <[email protected]<mailto:[email protected]>>; 'Multanen, Eric W' <[email protected]<mailto:[email protected]>>; 'Bartlomiej Grzybowski' <[email protected]<mailto:[email protected]>> Subject: [onap-discuss] vCPE usecase: DHCP issue Hi, In VCPE usecase, did anyone encounter DHCP issue for BRG interface ?? Long story short: BRGEMU (DHCP client) send DHCP request, forwarded by BNG (relay server) towards DHCP server DHCP server returns DHCP offer (port 67 -> port 67) to BNG …. but then it’s somehow dropped and not forwarded back to BRGEMU !! More detailed story: It looks that main problem is that BRG doesn’t receive it’s IP (10.3.0.2) from DHCP !!! root@zdcpe1cpe01brgemu01-201908251807:~# vppctl show int address GigabitEthernet0/4/0 (up): local0 (dn): tap-0 (up): l2 bridge bd_id 10 shg 0 tap-1 (up): 20.0.0.40/24 root@zdcpe1cpe01brgemu01-201908251807:~# vppctl show hardware Name Idx Link Hardware GigabitEthernet0/4/0 1 up GigabitEthernet0/4/0 Ethernet address fa:16:3e:50:74:1c Red Hat Virtio carrier up full duplex speed 10000 mtu 9216 rx queues 1, rx desc 256, tx queues 1, tx desc 256 tx frames ok 101 tx bytes ok 32926 rx frames ok 4 rx bytes ok 224 If I understand it correctly, BRG should get IP address via DHCP – Option 82 (means BNG is relay host between BNG and DHCP server) I also see some traffic on DHCP server for that MAC address, however don’t know where replies got dropped root@zdcpe1cpe01dhcp01-201908251807:~# tcpdump -i any port 67 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 18:27:55.636784 IP 10.4.0.3.bootpc > 10.4.0.1.bootps: BOOTP/DHCP, Request from fa:16:3e:50:74:1c (oui Unknown), length 307 18:27:55.639311 IP 10.4.0.1.bootps > 10.4.0.3.bootps: BOOTP/DHCP, Reply, length 290 18:28:00.641081 IP 10.4.0.3.bootpc > 10.4.0.1.bootps: BOOTP/DHCP, Request from fa:16:3e:50:74:1c (oui Unknown), length 307 18:28:00.642956 IP 10.4.0.1.bootps > 10.4.0.3.bootps: BOOTP/DHCP, Reply, length 290 18:28:05.638780 IP 10.4.0.3.bootpc > 10.4.0.1.bootps: BOOTP/DHCP, Request from fa:16:3e:50:74:1c (oui Unknown), length 307 18:28:05.641179 IP 10.4.0.1.bootps > 10.4.0.3.bootps: BOOTP/DHCP, Reply, length 290 On BNG it looks that traffic is flowing … root@zdcpe1cpe01bng01-201908251807:~# vppctl show node count Count Node Reason 185 vbng-dhcp-to-server DHCP packets relayed to the server 183 vbng-dhcp-to-server DHCP packets relayed to clients 1 vbng-dhcp-to-server DHCP packets failed to pass the AAA check. 1 ip4-udp-lookup no error 8 ip6-input ip6 adjacency drop 5 ip4-glean ARP requests sent 2 ip4-icmp-input echo replies sent 2 arp-input ARP replies sent 2 arp-input ARP replies received root@zdcpe1cpe01bng01-201908251807:~# vppctl show trace ------------------- Start of thread 0 vpp_main ------------------- Packet 1 00:18:02:693363: dpdk-input GigabitEthernet0/4/0 rx queue 0 buffer 0x3618: current data 14, length 312, free-list 0, clone-count 0, totlen-nifb 0, trace 0x0 PKT MBUF: port 0, nb_segs 1, pkt_len 326 buf_len 2176, data_len 326, ol_flags 0x0, data_off 128, phys_addr 0x6a4d4500 packet_type 0x0 IP4: fa:16:3e:50:74:1c -> ff:ff:ff:ff:ff:ff UDP: 0.0.0.0 -> 255.255.255.255 tos 0x00, ttl 128, length 312, checksum 0x39b6 fragment id 0x0000 UDP: 68 -> 67 length 292, checksum 0x0000 00:18:02:693414: ip4-input UDP: 0.0.0.0 -> 255.255.255.255 tos 0x00, ttl 128, length 312, checksum 0x39b6 fragment id 0x0000 UDP: 68 -> 67 length 292, checksum 0x0000 00:18:02:693428: ip4-lookup fib 0 dpo-idx 8 flow hash: 0x00000000 UDP: 0.0.0.0 -> 255.255.255.255 tos 0x00, ttl 128, length 312, checksum 0x39b6 fragment id 0x0000 UDP: 68 -> 67 length 292, checksum 0x0000 00:18:02:693434: ip4-local UDP: 0.0.0.0 -> 255.255.255.255 tos 0x00, ttl 128, length 312, checksum 0x39b6 fragment id 0x0000 UDP: 68 -> 67 length 292, checksum 0x0000 00:18:02:693436: ip4-udp-lookup UDP: src-port 68 dst-port 67 00:18:02:693439: vbng-dhcp-to-server DHCP proxy: sent to server 10.4.0.1 original_sw_if_index: 1, sw_if_index: 1 00:18:02:693444: ip4-lookup fib 0 dpo-idx 7 flow hash: 0x00000000 UDP: 10.4.0.3 -> 10.4.0.1 tos 0x00, ttl 128, length 335, checksum 0x2593 fragment id 0x0000 UDP: 68 -> 67 length 315, checksum 0x0000 00:18:02:693451: ip4-rewrite tx_sw_if_index 2 dpo-idx 7 : ipv4 via 10.4.0.1 GigabitEthernet0/6/0: fa163ecd2d63fa163e957b450800 flow hash: 0x00000000 00000000: fa163ecd2d63fa163e957b4508004500014f000000007f1126930a0400030a04 00000020: 000100440043013b00000101060005c3f82c00008000000000000000 00:18:02:693453: GigabitEthernet0/6/0-output GigabitEthernet0/6/0 IP4: fa:16:3e:95:7b:45 -> fa:16:3e:cd:2d:63 UDP: 10.4.0.3 -> 10.4.0.1 tos 0x00, ttl 127, length 335, checksum 0x2693 fragment id 0x0000 UDP: 68 -> 67 length 315, checksum 0x0000 00:18:02:693455: GigabitEthernet0/6/0-tx GigabitEthernet0/6/0 tx queue 0 buffer 0x3618: current data 0, length 349, free-list 0, clone-count 0, totlen-nifb 0, trace 0x0 IP4: fa:16:3e:95:7b:45 -> fa:16:3e:cd:2d:63 UDP: 10.4.0.3 -> 10.4.0.1 tos 0x00, ttl 127, length 335, checksum 0x2693 fragment id 0x0000 UDP: 68 -> 67 length 315, checksum 0x0000 Packet 2 00:18:02:696453: dpdk-input GigabitEthernet0/6/0 rx queue 0 buffer 0xf3f: current data 14, length 318, free-list 0, clone-count 0, totlen-nifb 0, trace 0x1 PKT MBUF: port 1, nb_segs 1, pkt_len 332 buf_len 2176, data_len 332, ol_flags 0x0, data_off 128, phys_addr 0x6a438ec0 packet_type 0x0 IP4: fa:16:3e:cd:2d:63 -> fa:16:3e:95:7b:45 UDP: 10.4.0.1 -> 10.4.0.3 tos 0x10, ttl 128, length 318, checksum 0xe593 fragment id 0x0000, flags DONT_FRAGMENT UDP: 67 -> 67 length 298, checksum 0x3375 00:18:02:696473: ip4-input UDP: 10.4.0.1 -> 10.4.0.3 tos 0x10, ttl 128, length 318, checksum 0xe593 fragment id 0x0000, flags DONT_FRAGMENT UDP: 67 -> 67 length 298, checksum 0x3375 00:18:02:696486: ip4-lookup fib 0 dpo-idx 6 flow hash: 0x00000000 UDP: 10.4.0.1 -> 10.4.0.3 tos 0x10, ttl 128, length 318, checksum 0xe593 fragment id 0x0000, flags DONT_FRAGMENT UDP: 67 -> 67 length 298, checksum 0x3375 00:18:02:696487: ip4-local UDP: 10.4.0.1 -> 10.4.0.3 tos 0x10, ttl 128, length 318, checksum 0xe593 fragment id 0x0000, flags DONT_FRAGMENT UDP: 67 -> 67 length 298, checksum 0x3375 00:18:02:696488: ip4-udp-lookup UDP: src-port 67 dst-port 67 00:18:02:696489: vbng-dhcp-to-client DHCP proxy: broadcast to client from 10.3.0.1 original_sw_if_index: 1, sw_if_index: 1 BUT on BRG it’s somehow dead root@zdcpe1cpe01brgemu01-201908251807:~# vppctl show node count Count Node Reason 7 tapcli-rx no error 2 ip6-input ip6 adjacency drop 7 l2-learn L2 learn packets 1 l2-learn L2 learn misses 6 l2-learn L2 learn hits 7 l2-input L2 input packets 7 l2-flood L2 flood packets 7 l2-flood L2 replication complete 4 arp-input IP4 destination address not local to subnet root@zdcpe1cpe01brgemu01-201908251807:~# vppctl trace add dpdk-input 10 root@zdcpe1cpe01brgemu01-201908251807:~# vppctl show trace ------------------- Start of thread 0 vpp_main ------------------- No packets in trace buffer (restart of BRG will not allow interfaces to setup properly, so fastest way for restore it is to run ./vcpe.py infra) Any hint very appreciated … Thank you, Michal PS: I am now using same VCPE images on integration lab (just for case 😊) [http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=m.ptacek&do=bWFpbElEPTIwMTkwODI2MTQ0MjI1ZXVjYXMxcDE4ZjgzZjNiYWJjNDVkMzA1MjMwODRmZmVlNDM0YzU1ZiZyZWNpcGllbnRBZGRyZXNzPW9uYXAtZGlzY3Vzc0BsaXN0cy5vbmFwLm9yZw__] [cid:[email protected]] [http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=m.ptacek&do=bWFpbElEPTIwMTkwODI2MTcxMTE4ZXVjYXMxcDI2MDFkNmY4OTMxMTJlZTY0OGY1Y2JmYjA4MTgxNDQyNSZyZWNpcGllbnRBZGRyZXNzPWJmMTkzNkBhdHQuY29t] -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18693): https://lists.onap.org/g/onap-discuss/message/18693 Mute This Topic: https://lists.onap.org/mt/33034144/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
