Policy Based Routing and IP Helper

[RyanJohnstone]

Can anyone help with an issue i am having with PBR and an IP Helper.  I cannot get devices in the VLAN with the associated SVI to get DHCP addresses, there is no DHCP server in the VLAN so an IP Helper is used but whenever i enable PBR on the SVI, DHCP stops working.  The switch is a 6506 Catalyst running Version 12.2(17d)SXB11 of IOS

The SVI config for the VLAN is as below

ip address 10.2.60.254 255.255.255.0

ip helper-address 10.10.80.200

ip helper-address 10.10.80.201

ip policy route-map ACPBR

no ip igmp snooping explicit-tracking

no ipv6 mld snooping explicit-tracking

no ipv6 mld snooping

a route map configured as follows

route-map ACPBR permit 10

match ip address ACPBR_ACL

set ip default next-hop 10.99.1.252

!

route-map ACPBR permit 20

set default interface Null0

!

and an access list as follows

ip access-list extended ACPBR_ACL

deny udp any any eq bootps log

permit ip 10.2.60.0 0.0.0.255 any

So any DHCP traffic should hit the deny command and drop back to the normal routing process, at least thats my understanding.  The logs on the 6506 even show the DENY being hit, see below

list ACPBR_ACL denied udp 0.0.0.0(68) -> 255.255.255.255(67), 1 packet

Can anyone advise why this may be happening, if i add the PBR to the SVI DHCP stops working, if i remove it then it starts working so it is definately PBR doing something.

Thanks

Ryan

[Peter Paluch · Accepted solution]

Ryan,

The deny line in your ACL merely causes the DHCP traffic to be not processed in the ACPBR block 10. However, for this traffic, the processing of the route-map continues to block 20 with the set default interface Null0 command. This could be the cause of the drops you are seeing. Remember, the permit/deny in ACL here only select packets to be dealt with in the particular route-map block. However, it is the permit/deny in the route-map block header that determines whether the packet is going to be PBR-ed or normally routed.

Assuming you want to keep the DHCP traffic to be normally routed, one of ways of doing that would be:

ip access-list extended ACPBR_ACL
 deny udp any any eq bootps log
 permit ip 10.2.60.0 0.0.0.255 any
!
ip access-list extended ACPBR_DHCP
 permit udp any any eq bootps
!
route-map ACPBR permit 10
 match ip address ACPBR_ACL
 set ip default next-hop 10.99.1.252
!
route-map ACPBR deny 15
 match ip address ACPBR_DHCP
!
route-map ACPBR permit 20
 set default interface Null0

This configuration causes the DHCP traffic to be processed in block 15, and because of the deny action in the block header, the traffic should fall back to normal routing.

While I am somewhat surprised that the PBR would affect broadcasts (it should not, and perhaps it affects only a part of the DHCP communication that does happen to be unicasted), I believe this modification of your config is worth trying.

Best regards,

Peter

[Jon Marshall]

Peter

You beat me to it. I must be getting slower in my typing 

Jon

[RyanJohnstone]

Thanks Peter, made changes based on your guidance and all working well.

[veevekraj]

Thanks

[Jon Marshall · Accepted solution]

Ryan

What is happening is that your DHCP request is being matched by ACPBR_ACL. When a packet matches a deny entry in acl it simply jumps to the next route map statement if there is one and there is in your case ie.

route-map ACPBR permit 20

set default interface Null0

If you want to stop processing the route-map altogether then you need to use a deny in the actual route map statement rather than the acl. So you need to rewrite your route map with a deny statement for DHCP traffic eg.

route-map ACBPR deny 10

match ip address ACPBR_DHCP

route-map ACPBR permit 20

match ip address ACPBR_ACL

set ip default next-hop 10.99.1.252

route-map ACPBR permit 30

set default interface Null0

ip access-list extended ACPBR_DHCP

permit udp any any eq bootps log

ip access-list extended ACPBR_ACL

permit ip 10.2.60.0 0.0.0.255 any

Of course without knowing exactly how your topology is setup you may need to modify but based on what you have told us the above should work.

Jon

[RyanJohnstone]

Thanks Jon, all working now.  appreciate your assistance.