cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1748
Views
205
Helpful
11
Replies

DHCP in DNA L2VN

smithvivi08096
Level 1
Level 1

I have a customer requirement to deploy pairs of devices which are L2 isolated so that just the pair can see or talk to one another. This was achieved in DNA with L2VNs and everything worked when tested. However, the customer has thrown me a curve ball and asked that one of the devices in the pair lease an address to the other. Now this does not work within the fabric because of dhcp snooping being turned on for edge nodes. I’ve tried disabling ip dhcp snooping and adding ip dhcp snooping trust to the interface for the device which is hosting the device that’s acting as a dhcp server for the other. This didn’t help. 

Therefore, my question is; does anyone have any experience with this use case within their DNA environments? specifically dhcp inside an SDA fabric or L2VN?

 

thank you in advance. 

UPDATE: to wrap this thread up, it seems that L2VNs are the solution but you must enable multicast on the underlay for it to work. This can be achieved either via LAN automation by ticking the enable multicast box or manually after the fact by enabling multicast routing globally then ip pim spare-mode on all L3 interfaces.

1 Accepted Solution

Accepted Solutions

willwetherman
Spotlight
Spotlight

Hi @smithvivi08096 

 

We have configured Layer-2 Only/Pure L2VN in our SD-Access fabric for similar use cases without any issues. A common use case that we have is to provide L2 connectivity for third parties that have equipment installed in different locations within our campus. For example, a third party may have a router connected to one fabric edge that is providing internet access and acting as a DHCP server, and a switch connected to another fabric edge that provides connectivity to the third party endpoints. Our SD-Access fabric acts as simple "pipe" between these fabric edge switches; the third parties traffic, IP addressing etc is completely transparent to us. L2 flooding is enabled and DHCP snooping is disabled for each L2VN so DHCP works without any issues between third party devices within the fabric.

 

Note that L2 Flooding requires multicast to be enabled in the underlay. This can be configured manually or using LAN Automation. Has multicast been setup and tested in your network?

 

Will

 

View solution in original post

11 Replies 11

Preston Chilcote
Cisco Employee
Cisco Employee

You didn't mention the DHCP relay config that DNA is going to use to direct the request.  I don't know that it's been tested to use a DHCP server outside of a shared services block reachable via border (the usual design), but the first step that I considered reading your question was to make sure that in your design settings, the floor where this special device is listed has the right DHCP server applied.  That should at least make sure the new server is being directed the requests.  Then maybe you'll still need to toggle dhcp snooping so that the request actually reaches the server.

 

 

That’s a fair point Preston, with L2VNs I am not sure how it interacts with its L3VN parent and ip helper config. As far as I understand it from the docs, the L2VN is just another VLAN with no SVI. 

Oh ya, this is a L2VN.  So you will want to make sure the DHCP packet are broadcast on the L2VN.  This is disabled by default.  Have you enabled flooding?  https://community.cisco.com/t5/networking-documents/cisco-sd-access-layer2-flooding/ta-p/3943916

 

 

I have enabled flooding on the L2VN yes. I have tried disabling ip dhcp snooping as well. No luck this far. 

Hi. Right now Layer 2 Virtual Network is a limited availability feature and it may change to general availability later this year. The current SD-Access UI for L2VN should have a warning along the lines of "This is an early-release feature. Layer 2 Virtual Networks should be enabled only with explicit guidance from Cisco technical expert". In L2VN, DHCP snooping is always off and L2 flooding is always on. L2 flooding cannot be switched off in an L2VN. DHCP server connected to a Fabric Edge Node L2VN should work.

 

In an SD-Access routed segment (a segment that has an SVI with an IP address on the Fabric Edge Nodes), DHCP server connected to Edge Nodes is not supported.

 

Best regards, Jerome

Hey Jedolphi,

Interesting, this was my understanding as well, I do now have a TAC open and I am working with a Cisco SME to work through the use case. However, just to confirm if the devices are dropped into the same L2VN they should see the dhcp traffic by default and no other configuration is required?

HI! Yes that's correct. In my lab I have wired DHCP server connected to L2VN-A on FE1 and wired DHCP client connected to L2VN-A on FE2. DHCP just works, no config required in addition to that was pushed by DNA Center. FYI, DHCP will only work for wired clients at this stage. Wireless clients connected to a fabric SSID will not receive DHCP response from DHCP server at this time, that's one of the reasons why the feature is limited availability and has a warning message. We're working on bringing in wireless support too, ETA TBD. Best regards, Jerome

Hey Jerome,

It's interesting you should mention wireless because the devices I am struggling with are wireless ones. I was under the impression that it wouldn't impact the question since the devices are dropping into the correct VLAN. What is it about the fabric/wireless configuration which means that DHCP responses are not reaching the wireless device?

Hi, in short, broadcasts are not replicated from the Fabric Edge Node to the Fabric APs, so a DHCP reply that is broadcast in an L2VN will be dropped at the FE towards the Fabric AP - again I must stress L2VN is a Limited Availability feature today as per the warning on the SD-Access UI. The code to solve FE-to-AP broadcast replication is under development now. Unicast DHCP reply in L2VN to fabric wireless endpoint will work today, but, you typically cannot manually control DHCP unicast/broadcast decision as it's part of the endpoint O/S. If you need DHCP broadcast in L2VN to fabric wireless endpoint to work then please contact your Cisco SE or AM to start a discussion. If the SE/AM needs technical detail then please point them to me. Cheers, Jerome

willwetherman
Spotlight
Spotlight

Hi @smithvivi08096 

 

We have configured Layer-2 Only/Pure L2VN in our SD-Access fabric for similar use cases without any issues. A common use case that we have is to provide L2 connectivity for third parties that have equipment installed in different locations within our campus. For example, a third party may have a router connected to one fabric edge that is providing internet access and acting as a DHCP server, and a switch connected to another fabric edge that provides connectivity to the third party endpoints. Our SD-Access fabric acts as simple "pipe" between these fabric edge switches; the third parties traffic, IP addressing etc is completely transparent to us. L2 flooding is enabled and DHCP snooping is disabled for each L2VN so DHCP works without any issues between third party devices within the fabric.

 

Note that L2 Flooding requires multicast to be enabled in the underlay. This can be configured manually or using LAN Automation. Has multicast been setup and tested in your network?

 

Will

 

Hey Willwetherman,

Thank you for informative response, we do not have multicast enable on the underlay and the fabric is deployed. Are there steps or a guide available to help with enabling multi-cast on the underlay after LAN automation has occurred? or will it be easier to erase the switch and redo LAN automation with the enable multi-cast button ticked?