cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4852
Views
0
Helpful
23
Replies

DHCP relay issue on Nexus 3k when used with vrf

Hello,

I have a strange behavior on a Nexus 3k (3064) running "NXOS: version 7.0(3)I7(6)".

I have 2960-X(for the clients) connected via port-channel (and trunk) to two N3K (vpc on the Nexus side) - just L2.

The svi of the "access-vlan 3080" is configured with hsrp on the N3K, and also the dhcp-relay agent. I had to put the svi in a vrf called "Printer". 

I can ping the DHCP-Server from the svi, and svi from the DHCP server. The thing is, if the svi is in a vrf(no matter which one) the client didn't get an IP-Address. If I put the svi in the default vrf, everything works fine.

The debug on the N3K shows the DHCPOFFER from the DHCP server, but the OFFER doesn't make it to the client.

 

Here is the config from the svi:

interface Vlan3080
  description Printer_Access
  vrf member Printer  
  no shutdown
  ip address 172.16.231.2/24
  ip router ospf 3080 area 0.0.0.20
  hsrp version 2
  hsrp 3080
    preempt
    priority 105
    ip 172.16.231.1
  ip dhcp relay address 10.67.244.30
  ip dhcp relay address 10.67.248.30

  Attached is the debug-output from the N3K.

Kind regards,

Andreas

 

23 Replies 23

Hi,

I was able to do a packet capture on the remote site. I used a monitor session on the 2960-X.

So, I prepared the switch and power cycled the printer(Canon). The wireshark trace shows exactly the same as the ethanalyzer-trace from the Nexus.

There are DHCP REQUESTS and DHCP OFFERS but no ACK's. The trace shows that the OFFER's are delivered to the client, but the client doesn't accept it? 

So, I connected a notebook with standard Win10 to the same switch-port where the printer is not getting an IP, and how should I put it - the Notebook get's an IP-Address without any problems... . So I took another Printer(different Vendor -> Lexmark). Same, the Printer does not get an IP... now I'm totally confused...

Kind regards,

Andreas

 

 

 

 

Hi,

 

    Can you post the packet capture so i can see the printer packets? Is the "DHCP Broadcast Flag" set in the DHCP Discovery? Have you tried upgrading the firmware/NIC drivers on the printer?

 

Regards,

Cristian Matei.

Hi,

I can not post the full packet capture in raw, for some privacy restrictions. But I exported some packets and had to mask some ip addresses.

Here are the first four packets from wireshark(all other discovers and offers are the same):

The "DHCP Broadcast Flag" ist set to "unicast" ...

Pls. find the exported packets attached.

 

Kind regards,

Andreas

 

Hi,

 

    Things look legit, and the printer receives the DHCP Offer. What i would do is the following, see which one fixes the problem.

         1. Reset the printer to factory defaults and reload it, reconfigure it.

         2. Upgrade the firmware/drivers to the latest one provided by Canon.

 

Regards,

Cristian Matei.

  

Hi,

sorry, I've forgotten some. I testet with a Canon and a Lexmark Printer. Both behave same. The printers are rented, so I couldn't update/upgrade anything. The thing is, they work without any problem if "running in default vrf".

I created another vrf with similar config (different ospf process , different vlan, different subnet, etc....) and put the printer on that vlan - same behavior. :(

I can make a try and reset one printer to factory defaults, an see if it works.

Kind regards,

Andreas

 

 

Hi,

I was not able to reset the printer to factory-defaults, got an access denied...

But I was able to do some more traces. I attached the DHCP_offer. One which works(default-vrf) and the other which does not work(vrf "Printer").

To me they look fairly the same.

Can you pls. have a look?

Kind regards,

Andreas

 

 

Hi,

 

    There is something different, which could make all the difference, exactly between working and non-working. It seems that the  Nexus behaves differently when running the DHCP Relay functionality in default VRF vs. user-defined VRF. In the global VRF, it uses source port number of 67 (how the plain old DHCP RFC was stating), while in the user VRF it uses a random source port number of 24528 in this case (how DHCP enhancements via RFC's allow DHCP to function, like RFC 8537). I suspect that your printers reject the DHCP Offer just because of seeing a different source port number than 67. If this is the case, nobody is to blame, there is just an incompatibility, but mostly because that may be an old printer, which clearly behaves like an old printer, with old habits?

   You said you were able to get an address for another non-printer device, both in the global GRT and the VRF, right? If yes, you'll just have to use different printers, or ask the owner to perform some upgrades, maybe it will fix it, to be less strict.

 

Regards,

Cristian Matei. 

Hi Cristian,

thank you very much for the excellent explanation! I think you're right. I bet the printers are all on an outdated firmware. This would also explain why an Win10-Client works without any problem. 

 

Thank you!

Regards,

Andreas

 

I like the chase, but mostly finding the answer in the end.

Cheers,

Cristian Matei.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: