bridge/Cloud interface is not passing DHCP Responses

Before posting something, READ the changelog, WATCH the videos, howto and provide following:
Your install is: Bare metal, ESXi, what CPU model, RAM, HD, what EVE version you have, output of the uname -a and any other info that might help us faster.

Moderator: mike

Post Reply
colin
Posts: 2
Joined: Fri Apr 21, 2017 2:57 pm

bridge/Cloud interface is not passing DHCP Responses

Post by colin » Tue Aug 07, 2018 10:24 am

EVE-NG version: 2.0.3-92
Platform: ESXi 6.5
Security config on hypervisor:
  • Promiscuous mode Accept
  • MAC address changes Accept
  • Forged transmits Accept
Hi,

I'm doing some ZTP testing at the moment with Arista vEOS images (was working before) but it seems that the pnet2 interface is consuming/dropping the DHCP responses.

Looking at the setup:

Code: Select all

brctl show
bridge name     bridge id               STP enabled     interfaces
pnet2           8000.000c2976c6ca       no              eth2
                                                        vunl0_1_0
                                                        vunl0_2_1
                                                        vunl0_3_0
                                                        vunl0_4_0

Code: Select all

tcpdump -i vunl0_2_1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vunl0_2_1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:05:32.267298 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:cb:38:c2 (oui Unknown), length 300
11:05:32.267602 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:cb:38:c2 (oui Unknown), length 300
11:05:34.265517 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:01:00:00 (oui Unknown), length 300
11:05:34.265784 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:01:00:00 (oui Unknown), length 300

Code: Select all

tcpdump -i pnet2 port bootps -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pnet2, link-type EN10MB (Ethernet), capture size 262144 bytes
11:07:32.903789 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:00:00:cb:38:c2, length 300
11:07:32.904151 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:00:00:cb:38:c2, length 300
11:07:32.944639 IP 172.168.1.3.67 > 172.168.1.243.68: BOOTP/DHCP, Reply, length 308
11:07:32.944679 IP 172.168.1.3.67 > 172.168.1.243.68: BOOTP/DHCP, Reply, length 308
11:07:32.944695 IP 172.168.1.3.67 > 172.168.1.243.68: BOOTP/DHCP, Reply, length 308
11:07:32.944817 IP 172.168.1.3.67 > 172.168.1.243.68: BOOTP/DHCP, Reply, length 308
11:07:34.499852 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:00:00:01:00:00, length 300
11:07:34.500099 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:00:00:01:00:00, length 300
11:07:34.500326 IP 172.168.1.3.67 > 172.168.1.240.68: BOOTP/DHCP, Reply, length 308
11:07:34.500409 IP 172.168.1.3.67 > 172.168.1.240.68: BOOTP/DHCP, Reply, length 308
11:07:34.500434 IP 172.168.1.3.67 > 172.168.1.240.68: BOOTP/DHCP, Reply, length 308
11:07:34.500508 IP 172.168.1.3.67 > 172.168.1.240.68: BOOTP/DHCP, Reply, length 308

I never see the DHCP responses on the vunl interfaces, just the request, and response looks to be correct.

Code: Select all

11:08:03.136964 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:cb:38:c2, length 300, xid 0x9812090b, Flags [none] (0x0000)
          Client-Ethernet-Address 50:00:00:cb:38:c2
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Parameter-Request Option 55, length 11:
              MTU, Subnet-Mask, BR, Default-Gateway
              Domain-Name, Domain-Name-Server, LOG, Hostname
              TFTP, BF, Classless-Static-Route
            Vendor-Class Option 60, length 11: "Arista;vEOS"
            Client-ID Option 61, length 6: hardware-type 80, 00:00:cb:38:c2
            END Option 255, length 0
            PAD Option 0, length 0, occurs 22
11:08:03.137312 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 336)
    172.168.1.3.67 > 172.168.1.243.68: [udp sum ok] BOOTP/DHCP, Reply, length 308, xid 0x9812090b, Flags [none] (0x0000)
          Your-IP 172.168.1.243
          Client-Ethernet-Address 50:00:00:cb:38:c2
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: 172.168.1.3
            Lease-Time Option 51, length 4: 43200
            Subnet-Mask Option 1, length 4: 255.255.255.0
            BR Option 28, length 4: 172.168.1.255
            Default-Gateway Option 3, length 4: 172.168.1.1
            BF Option 67, length 32: "http://172.168.1.3/ztp/bootstrap"
            END Option 255, length 0

Any thoughts?

Thanks!

Uldis (UD)
Posts: 5067
Joined: Wed Mar 15, 2017 4:44 pm
Location: London
Contact:

Re: bridge/Cloud interface is not passing DHCP Responses

Post by Uldis (UD) » Tue Aug 07, 2018 6:52 pm

I guess it is know inssue of VM ware...
if you have dual NIC multihomed and paired to your LAN.
Check this post...

https://github.com/InfraSIM/infrasim-co ... -situation

Uldis

colin
Posts: 2
Joined: Fri Apr 21, 2017 2:57 pm

Re: bridge/Cloud interface is not passing DHCP Responses

Post by colin » Wed Aug 08, 2018 8:44 am

That was exactly it - shut down one of the uplinks and it's working fine. Very strange. Will have to dig into this later.

Good catch - thanks!

slyone
Posts: 3
Joined: Wed Apr 21, 2021 11:44 am

Re: bridge/Cloud interface is not passing DHCP Responses

Post by slyone » Tue Jul 13, 2021 6:12 pm

I am suffering from a similar issue. I don't understand how shutting down an ESX up link resolves the issue, when the response packets are arriving on the eve-ng hosts, they just appear to not be crossing the bridge
on the return direction only. What could be filtering it?

Code: Select all

root@eve1:/var/log# brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242f8266e06       no              rdp_1049600
nat0            8000.000000000000       no
pnet0           8000.005056910b1d       no              eth0
pnet1           8000.0050569104d2       no              eth1
                                                        vun001000000100
Both discover and offer seen on eth1 and pnet1

Code: Select all

root@loodinfraeve1:/var/log# tshark -i pnet1 -f "port 68 or port 67" 
Running as user "root" and group "root". This could be dangerous.
Capturing on 'pnet1'
    1 0.000000000      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x97e39937
    2 0.000246574      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x97e39937
    3 0.000313786      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x97e39937
    4 0.000324201      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x97e39937
    5 0.000568100 10.210.78.164 ? 10.210.78.170 DHCP 366 DHCP Offer    - Transaction ID 0x97e39937
    6 0.000595142 10.210.78.164 ? 10.210.78.170 DHCP 366 DHCP Offer    - Transaction ID 0x97e39937
    7 0.000643217 10.210.78.164 ? 10.210.78.170 DHCP 366 DHCP Offer    - Transaction ID 0x97e39937
    8 0.000714836 10.210.78.164 ? 10.210.78.170 DHCP 366 DHCP Offer    - Transaction ID 0x97e39937
but not seen on the lab cloud1 side

Code: Select all

root@eve1:/var/log# tshark -i vun001000000100 -f "port 68 or port 67" 
Running as user "root" and group "root". This could be dangerous.
Capturing on 'vun001000000100'
    1 0.000000000      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4b72a045
    2 0.000323094      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4b72a045
    3 0.000587226      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4b72a045
    4 0.000606702      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4b72a045
    5 10.329648237      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4b72a045
    6 10.329913761      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4b72a045
    7 10.330157960      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4b72a045
    8 10.330186110      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x4b72a045
    9 30.136074511      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x56b3492f
   10 30.136457864      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x56b3492f
   11 30.136520404      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x56b3492f
   12 30.136530195      0.0.0.0 ? 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x56b3492f
I can't shutdown the uplinks from the servers as this is a 3 node cluster running other things.

Uldis (UD)
Posts: 5067
Joined: Wed Mar 15, 2017 4:44 pm
Location: London
Contact:

Re: bridge/Cloud interface is not passing DHCP Responses

Post by Uldis (UD) » Wed Jul 14, 2021 8:33 am

You must be sure that no NIC Teaming is used on your esxi!
It must be remioved, use single NON nic team uplink connect your esxi server to LAN

Post Reply