Policy Based Routing breaks DHCP ???

[sylvain.munaut]

Hi.

I have a setup working on a Cisco 1812 running 15.1(4)M7.

I'm starting from a working setup (but a rather large config, so not practical to post and sanitize here) and I'm trying to add new WAN link and use this new links for the users of one of the Vlan.

Since I'm already using the FastEthernet0 and FastEthernet1 for other things, I put this new WAN link as Vlan100.

Here's what I added to the config :

interface Vlan100
 ip address 1.1.1.2 255.255.255.252
 ip nat outside
 ip virtual-reassembly in
 zone-member security zone_wan

ip access-list extended acl_src_newwan
 permit ip host 1.1.1.2 any

route-map pbr-local permit 30
 match ip address acl_src_newwan
 set ip default next-hop 1.1.1.1

route-map nat_newwan permit 10
 match ip address acl_nat
 match interface Vlan100

ip nat inside source route-map nat_newwan interface Vlan100 overload

route-map pbr-newwan
 set ip default next-hop 1.1.1.1

interface Vlan20
 ip policy route-map pbr-newwan

A few comments :

• The zone_wan security zone is the same zone as the previous/other wan links.
• The pbr-local routemap is used for ip local policy route-map pbr-local and has entries 10/20 already for two other WAN links. This makes sure that local packet are sent down the right link and this works fine.
• The NAT setup is also a cut and paste from the NAT of the other two WAN links

Now when I do this, clients on Vlan20 actually have internet access through the new WAN link and this works exactly as designed.

BUT DHCP on Vlan20 stops working ... new clients can't get IPs anymore. If you fix the IP or if they got an IP previously it works fine but can't get a new one or renew or lease or anything ...

Here's the config for Vlan20 and the DHCP pool for it :

ip dhcp pool dhcp-pool-guest
 network 10.0.20.0 255.255.255.0
 default-router 10.0.20.1
 dns-server 10.0.20.1
 lease 3

interface Vlan20
 ip address 10.0.20.1 255.255.255.0
 no ip redirects
 ip dns view-group dns-query-other
 ip nat inside
 ip virtual-reassembly in
 zone-member security zone_guest
 

Any one has any idea of what could be going on here ???

Cheers,

    Sylvain

[Vasilii Mikhailovskii · Accepted solution]

Hello.

I guess you need to fix "route-map pbr-newwan", so it won't match your DHCP and local IP-addresses (with match address).

But, if you are trying to build a couple of independant routers (pairs of LAN/WAN and dedicated NAT rules), I would configure them via VRFs.

[sylvain.munaut]

My understanding was that by using :

set ip default next-hop 1.1.1.1

instead of :

set ip next-hop 1.1.1.1

then only the default route (i.e. anything that doesn't match something more specific than 0.0.0.0) would be affected by the route-map.

Also something I forgot to say is that the server is also the DNS server/cache for the VLAN and this also works fine ... so the router processes seems to have no problem communicating with the client of the vlan. Not sure why DHCP is different. Maybe something to do with broadcast addresses ?

VRFs here are not an option because only the WAN has to be different, but there are a bunch of routes to VPNs or other VLANs that are common.

[Julio Carvajal]

Hello,

Actually how it works is as follows:

With IP default next-hop:

• PBR will be applied as long as we do not have a route entry in the routing table for the destination. If we have it will not be Policed Based Routed.

Quick questions.

You are not using Self-Zones for ZBFW, are you?

If you remove the PBR config on vlan 20 , do u get an IP?

Regards

[sylvain.munaut]

I'm assuming that a 0.0.0.0/0.0.0.0 default route doesn't count as a "route entry for the destination" then ? Because from what I observe, it doesn't seem to count. With that PBR config, it seems that if I have a specific route to a destination it will take it, and if not, it will take what the PBR says (essentially "replacing" the default route with the PBR one, which is exactly what I want, so that they get access to all internal ranges/destination but for the wide internet, it takes the PBR).

* Yes, I am using self zones woth zbfw

* And yes, if I remove the PBR from Vlan20, then the client on that Vlan get an IP (and they get internet as well through the "old" WAN link).

[Vasilii Mikhailovskii · Accepted solution]

ip access-l ext VL20_ACL
 deny ip any 10.0.0.0 0.255.255.255
 permit ip 10.0.20.0 0.0.0.255 any

route-map pbr-newwan permit 10?
 set ip next-hop 1.1.1.1
 match ip address VL20_ACL

[sylvain.munaut]

The :

deny ip any 10.0.0.0 0.255.255.255

isn't even strictly necessary, but yeah, that made it work.

[sylvain.munaut]

Ok, so turns out adding a match address did fix the issue.

The important part was to make sure that the route-map wouldn't match the src=0.0.0.0 dst=255.255.255.255 that's used in the discovery message. So just using the same acl as I use for the NAT worked fine (which only limits the source address to the local range).