Local PBR - Wrong source ip address picked ...

[sylvain.munaut]

Hi,

I'm using a policy (route-map) applied to locally generated packets. Unfortunately IOS doesn't pick to right source ip address ...

Here's my setup :

- Cisco 877 with Vlan1 connected to the lan (10.0.0.1) and ATM0.1 connected to the wan (123.123.123.123)

- Some other router on the lan (10.0.0.2)

The router config (relevant part) :

---CUT---

ip route 0.0.0.0 0.0.0.0 ATM0.1

access list 101 .... some rules ...

route-map special_stuff

match ip address 101

set ip next-hop 10.0.0.2

interface Vlan 1

ip route-cache policy

ip policy route-map mck-vpn

ip local policy route-map special_stuff

---/CUT---

What happens is that :

- Lan client sending packet that match the criteria are correctly sent back to 10.0.0.2 and it works fine

- Local packets generated by the router that match the criteria are sent to 10.0.0.2 as well but with the ATM0.1 IP as source instead of Vlan1 ... And that's the issue ...

The 'why' I have to sent some packets to 10.0.0.2 is that they have to be tunnelled and I don't have control over that, I can only change the cisco box. I only don't use the routing table simply because I have other interface than Vlan1 and those need not to use the 'special' route.

Thanks for any insight you might have ... IMHO it doesn's sound logic for the cisco to send packet on Vlan1 that have the ATM0.1 ip as source ...

Sylvain

[mahmoodmkl]

Hi

I think local policy route-map is over riding the interface route-map.

Thanks

Mahmood

[sylvain.munaut]

Huh ... I don't really see what you mean ?

The policy on the interface and the local one have a different goal :

- On the interface it's there so that all packet that comes from this interface are routed thru the routemap

- The local policy is there so that packet generated locally are router thru the routermap (for examples dns request generated by the router itself, stuff like that).

[Richard Burts]

Sylvain

I am not sure from your post whether you believe that there is a problem with Policy Based Routing, or whether you just think that there is a problem with how the router picks a source address. Perhaps you can clarify?

For some protocols (for example for syslog, for FTP and TFTP, for TACACS or Radius, for NTP, for ping or traceroute) there is the possibility that you can configure the router to identify what to use as the source address. You do not indicate whether you have configured any of this on your router. Perhaps you can provide the complete config so that we can see how things are set up?

You have not told us what kind of traffic is being generated by the router that is policy base routed and what traffic is having the wrong source address? Perhaps you can explain this to us? And perhaps you can explain what you think that the source address should have been?

HTH

Rick

[sylvain.munaut]

I think there is a problem with how the router picked the source IP. The packets in question are DNS requests. I haven't configured anything to force him to take any source address for DNS.

I can't force it because some requests will be sent on the LAN (and in this case I expect it to take the LAN ip as source) and some will be sent on the WAN (and there I expect it to take the WAN ip as source).

The config is attached.

[Richard Burts]

Sylvain

I have looked at the config that you posted and some of it is helpful. I note some differences between the config posted and what you have previously described. In particular in previous post you describe one Policy Based Routing on a VLAN interface and a different PBR for local policy. But the posted config has the same PBR for the interface and for local policy.

I also note that the configured default route is:

ip route 0.0.0.0 0.0.0.0 ATM0.4

but there is not any ATM0.4 interface but is ATM0.1.

So I am not sure if the config and the behavior are changing during the discussion.

I do see in the config that you have configured 2 name servers and that both of them are external (reached through the outside interface not the LAN interface). I also see that you have configured the router to act as a DNS server for clients on the VLAN interfaces. So I would expect DNS requests to be sent out the outside interface and DNS responses to be sent out the inside interface. If that is not what is happening perhaps you can provide some details of the packets that are not doing as expected?

HTH

Rick

[sylvain.munaut]

Well in order :

- About the different policies : The first post is erroneous ... I just forgot to replace mck-vpn to special_stuff ...

- About ATM0.4 vs ATM0.1 I just forgot to rename it while posting ... The .4 is due to the fact I reconfigures 4 times using SDM at the very beginning ... but there is only 1 interface and it's always the same that's used in the running config.

- The DNS server actually splits the requests. If it's for a domain matching *.somecompany.com, the DNS requests will be sent to a IP that is _not_ internal but that will match the routemap and have it's next hop set to an internal IP (10.0.1.32 iirc). Because even if the dns server that must answer this request has an 'internet' ip, it is not directly reachable and must be tunnelled via 10.0.1.32

[Richard Burts]

Sylvain

With the additional explanation I believe that I understand the behavior now. First let us be clear that PBR takes place as the packet is about to be forwarded - after the packet is built. So if the router is building a packet that is a DNS request it believes that it will be sending the packet out the ATM subinterface (if it is building a request to 100.100 there is not any entry in the routing table for 100.100 so it will use the default route out the ATM subinterface) and chooses the ATM subinterface as the source address. But then in the forwarding process PBR changes the next hop from the ATM subinterface to 10.0.1.32. At this point the source address is already chosen (appropriately as far as I can see) and PBR does not change the source address.

It seems to me that the way to solve this is to put routes into the routing table for 100.100 (or at least for 100.100.1.1 and 100.100.2.1) with 10.0.1.32 as the next hop. This way when the router builds its DNS request it will understand correctly which interface to use as the source address.

HTH

Rick

[sylvain.munaut]

Ok, I see.

Indeed puting the route make things work.

But the side effect is that requests to 100.100.{1,2}.1 coming from Vlan2,3&4 are now also sent to 10.0.1.32 instead ... In my original config I didn't apply the policy to Vlan2,3&4, only to Vlan1. But that's ok, it's just two IP ...

Thanks.

[Richard Burts · Accepted solution]

Sylvain

Based on this statement in one of the previous posts:

Because even if the dns server that must answer this request has an 'internet' ip, it is not directly reachable and must be tunnelled via 10.0.1.32

I would have thought it was an issue for VLANs 2, 3, and 4 as well as VLAN 1. Is there something that makes VLAN 2, 3, and 4 work that does not make VLAN 1 work?

HTH

Rick

[sylvain.munaut]

Well, the DNS service is not directly rachable ... other might.

And the VLAN 2,3,4 are not trusted at all, so I prefered to avoid tunneling packet on their behalf.

But it's not a big deal, I can just block all forwarding request from vlan 2,3,4 to theses two IPs. The guests have no business trying to contact them anyway ...

Sylvain