cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3032
Views
25
Helpful
8
Replies

Cisco 9800-CL - DHCP Relay Function

Greeting Experts,

We have installed two Virtual 9800 in our DC and set them up according to the documentation. The idea is to replace some old AireOS WLCs. 
Here is the interesting part:
The old solution uses DHCP Proxy to provide IP addresses for devices in two specific networks.

I am not able to replicate this behavior on the new WLC running 17.3.4, although we tried to use the DHCP Relay function on them.

I got some captures and I was able to see that the DHCPDiscover is going out from the WLC, but with the wrong VLAN.
Let's say a device connects to SSID using VLAN 200 and I have the IP Helper added to the SVI Of the VLAN on the WLC.
On the capture, I see that I have a DHCP Discover with source IPaddr of the SVI and Destination the DHCP Server - all good so far. However the packet comes from VLAN 100 - which is the MGMT-vlan...

How do I fix that? Are there any options to force the DHCP packet through the correct VLAN?

I've seen a bug related to this issue and they say that it is related to a configuration on the FW or the RPF Check, but we don't have the option to disable this at the moment, nor to configure ip-helper on the switches.

Any ideas? 

1 Accepted Solution

Accepted Solutions

So...

1.  This is the way the 9800 works, by design, as @Rasika Nayanajith has explained already.

2. So you either work with it that way or don't.  This is how it was designed to work.  It was never designed to work like AireOS used to.  This is just one of the many changes in 9800.

3.  The way AireOS worked was not strictly RFC compliant to start with as explained in the AireOS docs (it actually worked as a proxy not a relay) so no surprise that they've reverted to standard in IOS-XE using existing IOS-XE standard dhcp relay feature/functionality.

4. It's not recommended to use SVI with DHCP relay, but it does work - we're using it.  It's just that it works the same way as DHCP relay on any other Cisco router does now, which means that the relayed DHCP packet is routed according to IP destination on the 9800 just like any other packet would be.  So if you want to work that way you need to redesign accordingly.  You also need to consider (and mitigate) the security implications of hosting those SVIs on the 9800 where traffic can now be routed between the SVIs.

View solution in original post

8 Replies 8

marce1000
VIP
VIP

 

 - Whilst this is not a direct reply   review the current 9800-CL  configuration with the CLI command : show  tech wireless , have the output analyzed by  https://cway.cisco.com/tools/WirelessAnalyzer/  , please note do not use classical show tech-support (short version) , use the command denoted in green for Wireless Analyzer. If something is currently configured wrong , you may get hints for your current particular  problem too!

 M.



-- ' 'Good body every evening' ' this sentence was once spotted on a logo at the entrance of a Weight Watchers Club !

Hi, M.
Thanks for your reply.
The analyzer is a great tool, however there is nothing with the DHCP that the analyzer had found.
That would mean that my configuration is not entirely wrong!

Cheers!

This is the main reason why Cisco is not recommended to have any SVI on your 9800 other than management SVI. In that way when you migrate AireOS to 9800, you should not define those dynamic interfaces on 9800. Refer the 9800 config best practice document given below

https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9800-series-wireless-controllers/guide-c07-743627.html#DHCPbridgingandDHCPrelay 

In your case, you have to define DHCP relay function on your upstream device (L3 switch or firewall) & 9800 act as a L2 (just defined L2 vlan without SVI)

HTH
Rasika
*** Pls rate all useful responses ***

Hi Rasika,

Thanks for the reply.
I've seen this recommendation, but I was just wondering if there is a way to do it as a relay, exactly how it was designed to work. Because there is this feature, but this feature is not usable in my situation.
Maybe there is a way to force the WLC to use the proper VLAN for the packets.

Currently will be super hard to create helpers or relay on the upstream devices and I am searching for different solution if there is any.


Cheers!

So...

1.  This is the way the 9800 works, by design, as @Rasika Nayanajith has explained already.

2. So you either work with it that way or don't.  This is how it was designed to work.  It was never designed to work like AireOS used to.  This is just one of the many changes in 9800.

3.  The way AireOS worked was not strictly RFC compliant to start with as explained in the AireOS docs (it actually worked as a proxy not a relay) so no surprise that they've reverted to standard in IOS-XE using existing IOS-XE standard dhcp relay feature/functionality.

4. It's not recommended to use SVI with DHCP relay, but it does work - we're using it.  It's just that it works the same way as DHCP relay on any other Cisco router does now, which means that the relayed DHCP packet is routed according to IP destination on the 9800 just like any other packet would be.  So if you want to work that way you need to redesign accordingly.  You also need to consider (and mitigate) the security implications of hosting those SVIs on the 9800 where traffic can now be routed between the SVIs.

Hello,

I see, so it will forward the packet using the routing table on the WLC.

Well what's the point in having the option to have an IP helper specified on an interface when it will always use the mgmt vlan since the default route will be for the management? I can't understand the logic behind it. Maybe configure static routes for each SVI?!

My main point is that I was not expecting this behavior and I still am not sure that the source IP address and VLAN on the same packet can be different networks at the same time and that could be made to work without redesigning all upstream devices.

 

Either way, thank you for the explanation.

Cheers!

You can try "ip dhcp relay source-interface vlan x" under your user SVI where X is your 9800 management VLAN (described in that best practice document). That may fix your issue (test with PCAP)

Though it is not the recommended design by Cisco, It may be a workaround.

HTH
Rasika

Hello,

When I don't use this option, the packet will be forwarder from mgmt SVI with source the IP address and the VLAN of the Mgmt SVI. If I use it, only the source IP address is changed, but still uses VLAN of the management SVI. This is what is broken in my opinion, but i  another reply I think I understood what causes it.

 

Cheers!

Review Cisco Networking products for a $25 gift card