SG300 internal DHCP server with different vlans with Access Control

[intport1231]

Hello,

I just want to setup a couple of vlans that are going to provide dynamic IP addresses to some PCs directly connected.

Therefore I have created two vlans, two dhcp pools, and it works. Now I want to restrict access, in L2 I do it by means of mac acl, but I have the switch in L3 so as to use the internal dhcp server. I don't have, nor do I want to use yet, an external radius server for mac/802.1x security. I want to grant/not-grant access to PCs based on their mac addresses and I should be able to do that with a cisco switch.

So far I can get it working either by setting dhcp pool over a vlan and no mac acl, or by setting a mac acl to a vlan and the PCs with static IP address.

In the logs I can see how the packets for dynamic ip obtaining (bootp) are being permitted by the switch but I receive no response to the DHCP Discovery.

Can someone please show me the right way to do this?

excerpt of config:

(mac XX:XX:0e:24:XX:XX  is the one is trying to get a dynamic IP address, just covering the digits there... )

v1.4.1.3 / R800_NIK_1_4_194_194

vlan database

vlan 2,3

!

ip dhcp server

ip dhcp pool network p2

address low 192.168.2.1 high 192.168.2.14 255.255.255.240

ip dhcp pool network p3

address low 192.168.3.1 high 192.168.3.14 255.255.255.240

!

mac access-list extended al1

permit XX:XX:0e:24:XX:XX 00:00:00:00:00:00 any ace-priority 2 log-input

!

interface vlan 1

ip address 192.168.1.100 255.255.255.0

no ip address dhcp

!

interface vlan 2

name vl2

ip address 192.168.2.1 255.255.255.240

service-acl input al1

!

interface vlan 3

name vl3

ip address 192.168.3.1 255.255.255.240

!

interface gigabitethernet7

switchport trunk native vlan 2

power inline never

!

interface gigabitethernet8

switchport trunk native vlan 3

power inline never

This is the messages i get (PC in dynamic obtaining mode, console accesing via serial):

(because it had previously obtained dynamic ip adddress with no mac acl it also sends a dhcp request (source 192.168.2.2), besides the dhcp discovery (source 0.0.0.0, source 169.254.17.198)

9-Mar-2015 17:28:23 %LINK-I-Up: gi7

29-Mar-2015 17:28:23 %LINK-I-Up: Vlan 2

29-Mar-2015 17:28:28 %STP-W-PORTSTATUS: gi7: STP status Forwarding

29-Mar-2015 17:28:28 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(63688) -> 239.255.255.250(1900),trapped

29-Mar-2015 17:28:28 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(1900) -> 239.255.255.250(1900),trapped

29-Mar-2015 17:28:28 %3SWCOS-I-LOGACLMAC: gi7: permit ACE XX:XX:0e:24:XX:XX -> ff:ff:ff:ff:ff:ff, Ethertype-2054, VLAN-2, COS-0, trapped

29-Mar-2015 17:28:28 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(137) -> 192.168.2.15(137),trapped

29-Mar-2015 17:28:28 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 0.0.0.0(68) -> 255.255.255.255(67),trapped

29-Mar-2015 17:28:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(50505) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(60462) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(51228) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(57550) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(56185) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(63271) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(59702) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:33 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(138) -> 192.168.2.15(138),trapped

29-Mar-2015 17:28:39 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(60447) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:52 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(58671) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:52 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(50546) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:52 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(65324) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:52 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(65312) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:28:52 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(59817) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:29:19 %3SWCOS-I-LOGACLINET: gi7: permit ACE IPv4(IGMP) 169.254.17.198 -> 224.0.0.22, DSCP-0, IGMP type--108 trapped

29-Mar-2015 17:29:19 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(520) -> 169.254.255.255(520),trapped

29-Mar-2015 17:29:19 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(520) -> 224.0.0.9(520),trapped

29-Mar-2015 17:29:19 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(137) -> 169.254.255.255(137),trapped

29-Mar-2015 17:29:19 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(1900) -> 239.255.255.250(1900),trapped

29-Mar-2015 17:29:19 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(56631) -> 239.255.255.250(1900),trapped

29-Mar-2015 17:29:23 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(49559) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:29:25 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(138) -> 169.254.255.255(138),trapped

29-Mar-2015 17:29:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(57374) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:29:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(55377) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:29:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(54745) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:29:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(59012) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:29:30 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(62870) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:29:34 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(57804) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:30:33 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(59794) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:30:33 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(52719) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:30:33 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(51969) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:30:33 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(58803) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:30:33 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(60307) -> 224.0.0.252(5355),trapped

29-Mar-2015 17:33:28 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(1900) -> 239.255.255.250(1900),trapped

29-Mar-2015 17:33:28 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(63688) -> 239.255.255.250(1900),trapped

29-Mar-2015 17:33:28 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 0.0.0.0(68) -> 255.255.255.255(67),trapped

29-Mar-2015 17:33:28 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(137) -> 192.168.2.15(137),trapped

29-Mar-2015 17:33:28 %3SWCOS-I-LOGACLMAC: gi7: permit ACE XX:XX:0e:24:XX:XX -> ff:ff:ff:ff:ff:ff, Ethertype-2054, VLAN-2, COS-0, trapped

29-Mar-2015 17:33:33 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 192.168.2.2(138) -> 192.168.2.15(138),trapped

29-Mar-2015 17:34:19 %3SWCOS-I-LOGACLINET: gi7: permit ACE IPv4(IGMP) 169.254.17.198 -> 224.0.0.22, DSCP-0, IGMP type--108 trapped

29-Mar-2015 17:34:19 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(137) -> 169.254.255.255(137),trapped

29-Mar-2015 17:34:19 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(1900) -> 239.255.255.250(1900),trapped

29-Mar-2015 17:34:19 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(56631) -> 239.255.255.250(1900),trapped

29-Mar-2015 17:34:25 %3SWCOS-I-LOGACLINETPORTS: gi7: permit ACE IPv4(UDP) 169.254.17.198(138) -> 169.254.255.255(138),trapped

29-Mar-2015 17:35:11 %LINK-W-Down: gi7

29-Mar-2015 17:35:11 %LINK-W-Down: Vlan 2

So the messages are not blocked they are permitted but then I get no response from the switch dhcp pool server if an acl is applied to the vlan or to the port.

I already have tried changing the port to access mode, to general mode (and with pvid 4095), I also tried this:

ip access-list extended DHCP
permit udp 0.0.0.0 0.0.0.0 bootpc 255.255.255.255 0.0.0.0 bootps ace-priority 99 log-input

and binding it to the port i want to connect to with no success.

This is very basic stuff, and it should be possible to do it with the switch alone but I'm really struggling, can you tell me how to go about that?

Thank you!

[Michal Bruncko]

hello

this is really interesting... yes, its basic functionality.

questions:

• if you set ACL on either port or VLAN and you already have static IP address assigned, is all rest communication working properly from that host?
• did you tried to use an external DHCP server if that will work (just for comparison and to see if packets are flowing both ways)?
• did you checked DHCP counters on switch via show commands to see if they are increasing while you have set ACL on port/VLAN?

[intport1231]

Thank you for your response.

With ACL, mac based ACE permiting source macs (hosts), binding ACL to VLAN, default to Deny all.

1. Static IP assignment on hosts. OK

- I can ping to the vlan IP address that is the ip pool address.

- I can ping to another host in the same vlan with host static IP assignment (windows pcs via netsh)

- I can ping to another host in another vlan since the L3 switch has the internal routes.

2. External DHCP.  dhcp mac address to ACE. OK

- I can reach the switch via external host (static/dynamic) via the external router/dhcp server connected to the switch.

- I can obtain the dynamic IP address on initial host from the external dhcp/router through the switch to which ACL mac based ACE has been configured. I can reach the switch ip address and dhcp/router.

3. DHCP Counters on internal DHCP pools when ACL to vlan binding present. not OK.

- show interfaces counters: show the increase in inbound Multicast packets (my dhcp discoveries)

- show ip dhcp server statistics: with ACL binding to vlan the counters remain at zero, that is no declined entries no dynamic entries either. with no service-acl input, I unbind that is I remove the ACL and then the counters do increase.

This is very strange. If someone could test and reproduce the behavior or even better make it work and tell me how to :) It'd be ideal, I already tried introducing another ip based ace for udp messages allowing range ports from 67-68 to 67-68 but i don't get it to work. Once again I'm in 1.4.13 sw version.

Thank you a lot ! let me know!

[intport1231]

Final workaround is to disable ACE logging after having downgraded to 1.3.5.58 and 1.4.0.88 and upgrade to 1.4.3.1

UPDATE: This issue seems to be related with the way the switch upgrades from 1.3.5.58 to 1.4.1.3. The System works properly without the need for a work around if the ACLs and ACEs are carried on from 1.4.0.88 and Then it works fine until you reset the configuration and goes back to not working properly.

The Initial solution was to downgrade to 1.3.5.58 from there upgrade to 1.4.0.88 and from there back to 1.4.1.3 using method 1 below, If you jump from 1.3.5.58 to 1.4.1.3 then something will be screwed up (in the file system?) and then you'll have the problem, but when you reset (button reset) everyhting is lost again.

@Michal, maybe you could try for this thing to reach the proper communication channels towards cisco, I don't know how to do it myself, or if inhere I can expect a cisco support personnel, I'm currently a guest in the forum. This upgrade process just screws up with something and is not an smooth transition from sw release to sw release.

this is the timeline of things so sw people can figure out what went wrong when they are reproducing the problem in lab.

Method 1 Working (upgrading from 1.4.0.88 with ACE logging disabled)

Timeline SG300-10P HW 03 boot 1.3.5.06 sw 1.3.5.58

- upgraded via http to image-2: 1.3.5.58, image-1: ACTIVE 1.4.1.3 DHCP not working in L3 with ACL mac based, ACE logging enabled

- downgraded via switch banks (boot set image-x) to image-2: ACTIVE 1.3.5.58, image-1 1.4.1.3 OK (no ACE logging option in 1.3.5.58)

- downgraded via http to image-2: 1.3.5.58, image-1:ACTIVE 1.4.0.88 NOT OK (ACE logging enabled) OK (ACE logging disabled)

- downgraded via switch banks (boot set image-x) to image-2: ACTIVE 1.3.5.58, image-1:1.4.0.88

- upgraded via http to image-2: 1.3.5.58, image-1: ACTIVE 1.4.1.3 OK (with ACE logging on or off)

Method 2 Not working (upgrading from 1.4.0.88 with ACE logging enabled)

Timeline SF300-24P HW 02 boot old sw 1.2 something

-upgraded via tftp in several steps to latest boot 1.3.5.06 and image-2: 1.3.5.58, image-1: ACTIVE 1.4.1.3 DHCP not working in L3 with ACL mac based, ACE logging enabled

- downgraded via switch banks (boot set image-x) to image-2: ACTIVE 1.3.5.58, image-1 1.4.1.3

- upgraded via switch banks (boot set image-x) to image-2: 1.3.5.58, image-1 1.4.1.3 DHCP not working in L3 with ACL mac based, ACE logging enabled or disabled

- downgraded via http to image-2: 1.3.5.58, image-1:ACTIVE 1.4.0.88

- downgraded via switch banks (boot set image-x) image-2: ACTIVE 1.3.5.58, image-1:1.4.0.88

- upgraded via http image-2: 1.3.5.58, image-1: ACTIVE 1.4.1.3 DHCP not working with ACL

STEP 3, after you get it working in method 1, RESET from RESET button to screw everything up again and not have DHCP internal with ACLs

Final workaround is to disable ACE logging after having downgraded and upgraded.

Original response post:

- I can confirm that this is a problem present in v1.4.1.3.

- It is also present in 1.4.0.88 Only when logging input (log input in ACE) is enabled.

- I have tested the same scenario in 1.3.5.58 with no issues.
(1.3.5.58 has no option to log the ACE inputs (mac permit, denied messages)

tested on SG300-10P HW: 03

1. DHCP server on, pool on vlan, ACL mac based, ACE:

permit XX:XX:0e:24:XX:XX 00:00:00:00:00:00 any ace-priority 2 log-input

1.4.1.3 no OK	1.4.0.88 no OK
- Multicast-DHCP messages visualized as permitted (console) - DHCP messages not received by dhcp pool server (dhcp counters do not increase) - DHCP Discover not answered (no offer from ip pool switch server) - no Dynamic IP address received by host

2.DHCP server on, pool on vlan, ACL mac based, ACE:

permit XX:XX:0e:24:XX:XX 00:00:00:00:00:00 any ace-priority 2

(not logging the input of the ACE)

1.4.1.3 not OK	1.4.0.88 OK
- Multicast-DHCP messages visualized as permitted (console) - DHCP messages not received by dhcp pool server (dhcp counters do not increase) - DHCP Discover not answered (no offer from ip pool switch server) - no Dynamic IP address received by host	- DHCP messages Are received by dhcp pool server (dhcp counters do increase) - DHCP Discover properly answered offer from ip pool switch server, Inform from host, ack from server) - Dynamic IP address received ok by host

3.DHCP server on, pool on vlan, ACL mac based, ACE:

permit XX:XX:0e:24:XX:XX 00:00:00:00:00:00 any

(the structure of the ACE in 1.3.5.58 is a little different since there is not option for logging)

1.3.5.58 OK No Problems

- DHCP messages Are received by dhcp pool server (dhcp counters do increase) - DHCP Discover properly answered offer from ip pool switch server, Inform from host, ack from server) - Dynamic IP address received ok by host

 I have downgraded my system from 1.4.1.3 to 1.4.0.88 and turned off logging for every ACE and thus it works fine although the logging functionality is obviously lost.

This is very basic functionality and I want cisco personnel to take note and open a case as I don't know how to do it myself. This proved to be time consuming but when I was reading other problems users were experimenting with this software release 1.4.1.3 I began to wonder whether that was not the case also with my issue.

[Michal Bruncko]

I would say great investigation :-) You make it working with one drawback related to ACE logging.

Unfortunately I have no any connections to Cisco (I am not employee, just community member), so I strongly recommending you to report this to Small Business Support Center (SBSC). For me it is definitely bug and Cisco should be able to investigate this. Only problem could be with FLS (first line support) as this is complex issue (several reproducing steps, ACL, DHCP,... all together) and they will wanted to replicate this so you have to be prepared for couple of questions and maybe troubleshooting sessions with desktop sharing. But anyway it is really great investigation and this bug can be related to some other (not-reported) issues and generally can improve system at all.

[intport1231]

Just to let know people that might come across this post.

It has been reported via chat support to Cisco, they say they will look into it and escalate it via internal mail to Senior Engineers but it'd take time for the scenario to be reproduced by Senior Engineers and acknowledged as a bug and worked on for a future SW release.