Re: [c-nsp] Limiting DHCP on a Bridge Group
Match protocol is nbar, I can never remember which require ip nbar protocol-discovery on the interface. Why not use an access-list denying dhcp deny udp any eq bootpc any eq bootps David -- http://dcp.dcptech.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Garry Sent: Wednesday, February 10, 2010 12:50 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Limiting DHCP on a Bridge Group Hi, I've got a setup that could use some tweaking ... CPE is a 876W, with the 4 wired switch ports (read: VLAN1) and the WLAN being in a bridge group, LAN ip on the BVI1 interface. LAN ports are only for designated boxes, while there are select users that may use the WLAN link to connect. For those, the router is running as a DHCP server, too. Anyway, I would like to limit the DHCP answers to just the WLAN link. I know I could go ahead and just split up the bridge group, with routing between the networks, but due to some other requirements, WLAN and wired lan needs to be in the same broadcast domain (at least unless the customer goes through some major reconfiguration). I've received some suggestion as to using a policy map with class maps matching on proto dhcp and the incoming interfaces, dropping the traffic when it matched, while still forwarding the class default ... anyway, I tried setting that up, but still got DHCP on the FE ports ... Any other suggestions? Or some hint on what I missed? Here's an excerpt from the config ... --- class-map match-all NODHCP match protocol dhcp match input-interface FastEthernet0 class-map match-all NODHCP1 match protocol dhcp match input-interface FastEthernet1 class-map match-all NODHCP2 match protocol dhcp match input-interface FastEthernet2 class-map match-all NODHCP3 match protocol dhcp match input-interface FastEthernet3 policy-map NODHCP class NODHCP drop class NODHCP1 drop class NODHCP2 drop class NODHCP3 drop class class-default ! interface BVI1 ip address 10.1.1.1 255.255.255.0 service-policy input NODHCP Help appreciated, -garry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Limiting DHCP on a Bridge Group
On 10.02.2010 19:04, David Prall wrote: Match protocol is nbar, I can never remember which require ip nbar protocol-discovery on the interface. Tried it (put it in the bvi1 interface), still getting DHCP replies though .. recognition is working fine, though ... dhcp 21 1180 352 The policy map/class seem to be attached to the BVI correctly, too: T#show policy-map int BVI1 Service-policy input: NODHCP Class-map: NODHCP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol dhcp Match: input-interface FastEthernet0 drop [..] Class-map: class-default (match-any) 931 packets, 57159 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: any Even added another class with input interface of VLAN1, still no success ... on the show policy-map command, none of the class-maps show any IP traffic, except for the default class ... After setting up two seperate classes to check for either an interface, or the protocol, it looks like the protocol part is working, while the interface match seems to fail ... adding both vlan1 and bvi1, I guess the class/policy map isn't able to differentiate the incoming interface anymore at that stage, as all the traffic is listed under BVI1, though the computer used to connect to the router at that point is connected to Fa0 ...: Class-map: test1 (match-any) 81 packets, 4860 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: input-interface FastEthernet0 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface FastEthernet1 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface FastEthernet2 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface FastEthernet3 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface Vlan1 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface BVI1 81 packets, 4860 bytes 5 minute rate 0 bps Any suggestion as to how to get around this? Maybe adding seperate vlans to each port and binding them to the bridge group? Why not use an access-list denying dhcp deny udp any eq bootpc any eq bootps Because I still need the DHCP to go through on the WLAN link? Tnx, garry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Limiting DHCP on a Bridge Group
I think the match interface is looking at where the policy is assigned. I know the policy isn't supported on the physical interfaces. I have to do all my QoS on fa4 inbound. Why not place an acl on the vlan interface for the wired ports. Not sure if it would be hit first, or if the bvi would capture it. Moved to an 881 at home, so I don't have my 871W anymore. David -- http://dcp.dcptech.com -Original Message- From: Garry [mailto:g...@gmx.de] Sent: Wednesday, February 10, 2010 2:06 PM To: c-nsp Cc: David Prall Subject: Re: [c-nsp] Limiting DHCP on a Bridge Group On 10.02.2010 19:04, David Prall wrote: Match protocol is nbar, I can never remember which require ip nbar protocol-discovery on the interface. Tried it (put it in the bvi1 interface), still getting DHCP replies though .. recognition is working fine, though ... dhcp 21 1180 352 The policy map/class seem to be attached to the BVI correctly, too: T#show policy-map int BVI1 Service-policy input: NODHCP Class-map: NODHCP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol dhcp Match: input-interface FastEthernet0 drop [..] Class-map: class-default (match-any) 931 packets, 57159 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: any Even added another class with input interface of VLAN1, still no success ... on the show policy-map command, none of the class-maps show any IP traffic, except for the default class ... After setting up two seperate classes to check for either an interface, or the protocol, it looks like the protocol part is working, while the interface match seems to fail ... adding both vlan1 and bvi1, I guess the class/policy map isn't able to differentiate the incoming interface anymore at that stage, as all the traffic is listed under BVI1, though the computer used to connect to the router at that point is connected to Fa0 ...: Class-map: test1 (match-any) 81 packets, 4860 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: input-interface FastEthernet0 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface FastEthernet1 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface FastEthernet2 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface FastEthernet3 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface Vlan1 0 packets, 0 bytes 5 minute rate 0 bps Match: input-interface BVI1 81 packets, 4860 bytes 5 minute rate 0 bps Any suggestion as to how to get around this? Maybe adding seperate vlans to each port and binding them to the bridge group? Why not use an access-list denying dhcp deny udp any eq bootpc any eq bootps Because I still need the DHCP to go through on the WLAN link? Tnx, garry ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Limiting DHCP on a Bridge Group
On 10.02.2010 20:30, David Prall wrote: I think the match interface is looking at where the policy is assigned. I know the policy isn't supported on the physical interfaces. I have to do all my QoS on fa4 inbound. Why not place an acl on the vlan interface for the wired ports. Not sure if it would be hit first, or if the bvi would capture it. I recon it ends up in the BVI, as adding the access-list to vlan1 ends up with no hits, while adding the same to the BVI increases the hit counter correctly, and dhcp requests are blocked ... but BVI won't help as it would also block the requests on wlan ... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Limiting DHCP on a Bridge Group
Garry, Wondering if you could do the wireless and vlan1 as unnumbered to a loopback. Then they are two distinct interfaces, on the same subnet. Or could always split the subnet into two distinct /25's instead of a single /24. David -- http://dcp.dcptech.com -Original Message- From: Garry [mailto:g...@gmx.de] Sent: Wednesday, February 10, 2010 2:39 PM To: David Prall Cc: 'c-nsp' Subject: Re: [c-nsp] Limiting DHCP on a Bridge Group On 10.02.2010 20:30, David Prall wrote: I think the match interface is looking at where the policy is assigned. I know the policy isn't supported on the physical interfaces. I have to do all my QoS on fa4 inbound. Why not place an acl on the vlan interface for the wired ports. Not sure if it would be hit first, or if the bvi would capture it. I recon it ends up in the BVI, as adding the access-list to vlan1 ends up with no hits, while adding the same to the BVI increases the hit counter correctly, and dhcp requests are blocked ... but BVI won't help as it would also block the requests on wlan ... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
