[c-nsp] Limiting DHCP on a Bridge Group

David Prall dcp at dcptech.com
Wed Feb 10 14:30:51 EST 2010


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:gkg at 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                     2                        1
>                             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



More information about the cisco-nsp mailing list