How does one block (allow / deny) DHCP traffic on specifc interfaces?

[mbwallace]

Hi All,

I'm sorry I'm a newbie to managed switches. So the answer may be straight forward and I've just overlooked it.

We have a set of Netvanta 1544 switches, and I have a need to block DHCP traffic on particular interfaces. Given that this is a Layer 3 switch, this shouldn't be a problem. However, is there something simple built in, such as CISCO's 'ip dhcp snooping' command, or do I have to disable/enable the DHCP UDP ports on specific interfaces. In either case, could a sumary of the commands and what they do be provided?

I've done searching both on google and in the forums here, and I have yet to find something covering this topic on Adtran switches.

Thanks,

Mack

[Anonymous]

:

Thank you for asking this question in the support community.  When you get a chance can you provide some additional information about the application?  Do you want certain switchports to block DHCP or prevent DHCP from traversing VLANs?

Levi

[mbwallace]

I'm trying to block DHCP on a specific switch port. The Adtran switch will be sitting in between two different sub-subnets. 192.168.0-2.x will be on one port/interface, the remainder of the ports/interfaces will be 192.168.3.x addresses. All those IP addresses will be part of one sub-net (mask being 255.255.252.0) but all the 192.168.3.x addresses will be on a separate physical branch of the network. We'd also like to have a separate DHCP server for that branch, so only 192.168.3.x addresses will be issued on that physical branch.

So we don't want to the DHCP server on the 192.168.0-2.x segment to see/answer request from the 192.168.3.x segment, and the same is true for the DHCP server on the 192.168.3.x segment. We don't want it to see/answer DHCP request from the 192.168.0-2.x segment.

If at both ends of the connection between the two physical segments were  Cisco switches, I could turn on DHCP snooping and then enable a trust from the port for which we want DHCP responses on each switch. This wouldn't block request from traversing across the segments, but it would prevent responses from crossing the border. The result being, the only response a DHCP requester would see would be from the DHCP server in its own physical segment.

So, in short, what I want is a bridged port that filters out DHCP traffic.

Looking through the Adtran Documentation for this switch, as this is a Layer 3 switch, I believe I could actually do this all on one switch. However, the question is how. Looking through the documentation, I found the ip access-list command. The documentation then says that in order to use an ACL, you must turn on the firewall first. But I don't want a firewall. I just want to filter the traffic.

After looking through the firewall documentation, it mentions using an access-group to statically filter the network traffic with ACLs without having to enable the firewall. Sounds great. Exactly what I want to do.

So I created an access list as follow.

(config)#ip access-list extended DenyDHCP

(config-ext-nacl)#deny udp any any eq 67

(config-ext-nacl)#deny udp any any eq 68

(config-ext-nacl)#allow any any

But now when I try to apply the ACL to the interface, the command errors with an "Unrecognized Command"

(config-ext-nacl)#interface giga-switchport 0/12

(config giga-swx 0/12)#ip access-policy DenyDHCP in

% Unrecognized command

The documentation shows examples of applying the access group to an ethernet port or a VLan. I tried applying it to a Vlan as well, but I get the same error.

So now I'm at a loss. Do I have to set up a firewall?

[mbwallace]

I noticed that I copied the last two commands in the previous post wrong.

They should be:

(config)#interface gigabit-switchport 0/12

(config-giga-swx 0/12)ip access-group DenyDHCP in

for which I get back a "% Unrecognized command"

I double checked that this was indeed what I was entering into the CLI. Tried it on both the gigabit switchport as well as Vlan 1. 

Thanks,

Mack

[Anonymous]

:

Thank you for replying with additional information.  There are several ways you can achieve this; however, on this platform, access-groups is not one of them.  So, you can use a similar configuration to the one you posted above and enable the firewall to deny this traffic and allow everything else, but for your application it may be easiest to use hardware ACLs.  Here is the guide on Configuring Hardware ACLs in AOS.

Here is a small example configuration:

ip hw-access-list extended DENY-DHCP

  deny   udp any  any eq bootps

  deny   udp any  any eq bootpc

  permit ip any  any

!

hw-access-map MAP1

  vlans 2

  forward ip DENY-DHCP

I hope that makes sense, but please let me know if you have any questions.  I will be happy to help.

Levi

[mbwallace]

Thanks Levi,

that should help quite a bit.

However, some questions. Those commands apply the hw-access-map to an entire vlan. How do I only apply that access-map to single port or subset of ports, with other ports that are part of the same network without that same restriction? Do I assign that port to its own vlan and then bridge that vlan with a vlan consisting of the rest of the ports?

Thanks,

Mack

[Anonymous]

Mack:

One way to do this would be to put all the devices/ports that you want to block DHCP access into a separate VLAN, then block DHCP for those VLANs (as the example I provided).  Another way would be to list the individual MAC addresses of each device you want to block DHCP in the hardware ACL.

Levi

[mbwallace]

Thanks Levi,

But will I then need to bridge or route between the two VLans? Or will this be unnecessary so long as the subnet of the router is the same as that for the two VLans?

Mack

[Anonymous]

Mack:

If you decide to place the devices in a separate VLAN, then typically they will need to be in a different subnet.  Either the ADTRAN will need an IP address (VLAN interface) in that subnet, and will route between the subnets automatically, or you will need a router to route between them.

Let me know what other questions you have.

Levi

[mbwallace]

Ok, so here's what I have...

I have some devices with addresses of 192.168.0.x and 192.168.1.x on one physical branch of the network.

I have some devices (including servers) with addresses of 192.168.3.x on the other physical branch headed by the Adtran Switch.

I want the devices on the 0.x and  1.x network to be able to access resources on the 3.x network, and vice versa.

So the subnet mask will be / should be 255.255.252.0 for members of both networks.

So, to do this, is it as simple as say

Setting up Vlan 1 with a 192.168.0.x or 192.168.1.x address with a mask of 255.255.254.x

Set up say Vlan 3 with a 192.168.3.x address with a mask of 255.255.255.x

And the switch will automatically route between the subnets?

Of course, what happens if the 0.x + 1.x network starts adding 2.x addresses? Then the subnet mask on the router would be opened up on that side to 255.255.252.x, which would now include the 3.x - I assume that this would kill the hardware access group filtering.

The problem is this. I'm trying to set up a network for a railroad's dispatching and event recording system. Users of a heretofore unmanaged network (managed by one department with an IP range of 192.168.0.x/255.255.254.x) will need to have access to resources in this new managed network (managed by my department). I was thinking of leaving the 2.x addresses free for the other department. But I'm guessing that would cause a problem with the DHCP filtering. Or at the very least, computers in the 3.x segments would not be able to communicate with the 2.x addresses.

I'm just trying to figure out how to set up the various Vlans and how this will work.

Thanks,

Mack

[mbwallace]

Ok, I think I have figured out how things are supposed to be in an "ideal" world. (Not what I'm working in, but...) Let's start here to see if I understand things correctly. Correct me if I'm wrong...

In an ideal world, each of the segments, 192.168.0.x, 192.168.1.x and 192.168.3.x would each have their own VLAN. The subnet mask for the clients of each of these vlans would be 255.255.255.0. And the layer 3 switch would be the default gateway for these three subnets. The layer three switch would then figure out if it could route traffic between the three subnets, or if not, forward the traffic to a gateway of last resort, which would usually be the public internet. At the layer three switch is also where we could apply a hw-access-list to prevent DHCP request, offers between the three subnets. If this was done all on one switch, no DHCP requesters or servers could be directly plugged into that switch, at least for the VLAN for which the hw-access-list denying DHCP is defined. The important part of all this being that the layer three switch needs to be in the default gateway path.

But would a hw-access-list be necessary at all if everything was separated into different Vlans? I would think that the broadcast request for a DHCP server would traverse the separate Vlans?

Unfortunately, how things are currently, the layer three switch on the 3.x network would/will just be an adjunct switch to the other network. Which is why I was just looking for a means to filter DHCP traffic. Cisco switches have a feature that will bock DHCP responses on untrusted ports/interfaces (DHCP snooping). This is there to prevent rogue DHCP servers from hijacking clients. If the switches on each side of the link between the 0.x-1.x and 3.x network had this capability, and the connecting ports were untrusted - while DHCP request would traverse across both physical segments, responses would only be heard from the local DHCP server. Of course, what I was hoping was I could do this with the Adtran switch we have all on one side. It looks like unfortunately the Adtran 1544 switch is not capable of doing this by interface.

Another little kink is that the 3.x network is to have a separate default gateway to the internet than the 0.x-1.x network. So if I'm to use Adtran 1544 switches, I'd think I need to have the layer three switch in each network, each being the default gateway for its respective network. Then a link between the two with a third Vlan (and third subnet). Traffic between the two subnets being routed through that third Vlan. And it would be that Vlan that would have the hw-access-list applied to it (if necessary).

Of course all of this seems fairly complicated for just wanting to filter a few DHCP packets on a specific interface.

Thanks,

Mack

[Anonymous · Accepted solution]

mbwallace:

I think we are making this harder than it needs to be.  I'm still not sure if you have administrative control to design/re-configure this network, or if you are working with a network design that is already implemented and you are trying to manipulate this setup to function the way you desire.  Furthermore, I'm unlcear as to where the DHCP server resides and where you would like to permit/deny DHCP broadcasts and what the overall goal of the network and application is.  If you could provide a network diagram, it would be helpful, or if you would like to send me a personal message, I will be happy to discuss this further with you and assist you with your questions.  However, from the information you just provided, it appears the goal of this application is just to prevent untrusted DHCP servers from responding to DHCP requests, not necessarily blocking DHCP on certain ports.  If that is correct, then you can simply use the Hardware ACL (HACL) as follows:

ip hw-access-list extended DENY-DHCP

  permit udp <DHCP Server's IP address> any eq bootps

  permit udp <DHCP Server's IP address> any eq bootpc

  deny udp any any eq bootps

  deny udp any any eq bootpc

  permit ip any  any

!

hw-access-map MAP1

  vlans X

  forward ip DENY-DHCP

If I have mistaken the goal of this application, then if you have the ability to design this network, then most likely, it will be much easier.  You will simply design the network as you mentioned above, where each subnet is divided into a separate VLAN, each with a /24 subnet.  If the networks are separated by VLAN, then the DHCP broadcasts, by default in a layer 3 switch or router, will not traverse VLANs/subnets, and thus the HACL may not be needed at all.

However, it appears there is already a 192.168.0.0 /22 network in place (which means 192.168.0.0 - 192.168.3.255 are all in the same subnet/VLAN with over 1,000 potential hosts (which I highly advise against)).  If you cannot change this subnet and segregate it down to smaller /24 subnets (192.168.0.0 /24; 192.168.1.0 /24; 192.168.2.0 /24 etc.), and if you want to block DHCP requests on specific interfaces on the ADTRAN, then you may have to create a HACL that matches the MAC address of the devices on each port that you would like to restrict DHCP, because everything will be in the same subnet/VLAN and will not be able to be manipulated by VLAN (as in the example I provided in a previous post).

I apologize for the difficulty I am having understanding the application, but please let me know any additional information you can, or let me know what questions you have on the ADTRAN unit.

Levi

[Anonymous]

:

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Levi

[mbwallace]

Dear Levi,

Sorry for the delay in replay. We've been talking with the other department and we're going to supply the other department with a layer 3 switch, set up separate virtual lans and try to do things correctly. I do have some questions, but I will put them in a new post, as they are separate from this topic.

I do still have some questions about what you've written above. So for anyones else who may be following or will follow in the future:

The hardware access list you've proposed:

  permit udp <DHCP Server's IP address> any eq bootps

  permit udp <DHCP Server's IP address> any eq bootpc

  deny udp any any eq bootps

  deny udp any any eq bootpc

  permit ip any  any

That access list looks like all the DHCP traffic is originating from the DHCP (both bootps and bootpc)

Shouldn't the access list be instead:

  permit udp any <DHCP Server's IP address> eq bootps

  permit udp <DHCP Server's IP address> any eq bootpc

  deny udp any any eq bootps

  deny udp any any eq bootpc

  permit ip any  any

That is any client is permitted to send a DHCP Request (from port 68 to port 67 bootps) to the DHCP Server at that IP address.

And the DHCP Server at that IP address can send a DHCP response (from 67 to 68 bootpc) to any client.

Any other DHCP server responding to a request through the switch would be denied.

While at first glance the first line makes sense, at second look it troubles me, because the DHCP request is usually made to 255.255.255.255:67. So would the switch properly route these request to the DHCP server's IP address?

The second and fourth lines are what effectively gives the switch the same functionality as "DHCP Snooping" on a Cisco Switch. So while this would only allow my DHCP server (192.168.3.2) to respond to DHCP request that come through the switch, it would not kill the DHCP request coming from the other network segment (192.168.0.0/23). And would still allow my server to respond to DHCP request that come from the the other network segment.

Now if I have another switch configured similarly for the other network segment - while DHCP request would propagate across both physical networks, only the server for the segment the requester is on could reply.

I think that the answer to my original question is now contained in this thread with a few details to work out. However, it seems there is no way to just prohibit all DHCP traffic on a physical interface on this switch (Netvanta 1544). Or at least not without that physical interface being on a separate VLan, in which case the two lans would be on different sub-nets and the switch would automatically filter out the broadcast traffic anyway, and I wouldn't need an access list.

And this puts us back into the right way to set this up with separate VLans and subnets and routing between them with the Layer 3 Switch.

Thanks,

Mack