Thought this would be pretty simple but am failing here with the basics. Trying to policy route internet traffic from a particular host (10.3.201.1) via a dedicated internet link rather than via the corporate wan. The access-list I am using for the route map just doesn't get any matches. Other access-lists I have placed on the 2811 do not accumulate matches either so I am guessing this is the cause. A show ip int g0/1.3 tells me pbr is enabled on the interface using my route-map. Any clues most welcome.
Extended IP access list 151
10 deny ip host 10.3.201.1 172.16.1.0 0.0.0.255
20 deny ip host 10.3.201.1 10.0.0.0 0.255.255.255
30 permit ip host 10.3.201.1 any
Some snippets from the config bewlow:
description **** Services vLAN ****
encapsulation dot1Q 4
ip address 10.3.201.254 255.255.255.0
no ip unreachables
no ip proxy-arp
ip flow ingress
ip virtual-reassembly in
ip tcp adjust-mss 1452
ip policy route-map reroute-dc-internet-traffic
access-list 151 deny ip host 10.3.201.1 172.16.1.0 0.0.0.255
access-list 151 deny ip host 10.3.201.1 10.0.0.0 0.255.255.255
access-list 151 permit ip host 10.3.201.1 any
route-map reroute-dc-internet-traffic permit 10
match ip address 151
set ip next-hop 10.6.201.253route-map reroute-dc-internet-traffic permit 10
What is the output from show route-map reroute-dc-internet-traffic?
If you traceroute to an internet host, what path does it show? Can you get out? You are testing from the 10.3.201.1 device, correct? You can check which way you are going out by using a website like ipchicken.com.
Here is a good video on the subject:
show routemap output:
route-map reroute-dc-internet-traffic, permit, sequence 10
ip address (access-lists): 151
ip next-hop 10.6.201.253
Policy routing matches: 0 packets, 0 bytes
Trace from the 10.3.201.1 host, shows the PBR not being applied:
Tracing route to 184.108.40.206 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.3.201.254
2 <1 ms 1 ms <1 ms 172.25.88.98
3 136 ms 7 ms <1 ms 172.25.88.113
4 1 ms 1 ms 1 ms 172.25.88.114
5 2 ms 2 ms 2 ms 172.16.1.253
6 3 ms 22 ms 3 ms 220.127.116.11
7 3 ms 4 ms 2 ms 18.104.22.168
8 19 ms 24 ms 23 ms 22.214.171.124
9 17 ms 21 ms 25 ms 126.96.36.199
10 14 ms 14 ms 14 ms 188.8.131.52
11 17 ms 17 ms 16 ms 184.108.40.206
12 17 ms 17 ms 16 ms 220.127.116.11
13 17 ms 17 ms 17 ms 18.104.22.168
14 14 ms 14 ms 14 ms 22.214.171.124
so gets back to my ACLs not being applied??
I will go take a look at the video.
My next suggestion would be to make the access-list 151 permit ip host 10.3.201.1 any and get rid of the deny lines, just to see if that helps.
If it doesn't help, my guess would be because it's a sub interface. Maybe try applying it to the base interface and not the sub interface? So just gig0/1? Maybe it's not catching it because of that...
I'm curious to know the answer, if it wasn't so late I'd fire up a router here at home to try it myself!
Yeah this should be so simple it's really winding me up! I think I might be up late as well..... Have just started tinkering more with the ACls. This one for example isn't applied to anything but I shoulod still see matches right? I have a persistent ping happening to 126.96.36.199 from the 10.3.201.1 host. Still no matches. It seems that no acl on this router gets a match!
cisco1921_FV#sh access-l 152
Extended IP access list 152
10 permit icmp host 10.3.201.1 host 188.8.131.52
I'm going to go out on a limb here, but is the host that you're pinging from addressed as 10.3.201.1 on the WAN side? If not, you'll need to source your ping in order for your PBR to work. For example:
If you're pinging from the above with just standard pings, the wan address will be used as the source and will never match your policy. If that's the case, try "ping 184.108.40.206 source 10.3.201.1"
John..... the ping is coming from the 10.3.201.1 host. It is on the LAN side. The g0/1 interface has 6 sub interfaces servicing the 6 vlans on this site. The next hop for the route map is on one of the vlans. Other traffic exits via g0/0 into the corp wan.
I have created a few other test Acls and none of them get matches regardless of the host, vlan or traffic type. Confused!
I labbed this up and it works fine. Have you checked the IOS version to see if there are any bugs related?
Couldn't find any bug info but just upgraded from c1900-universalk9-mz.SPA.152-2.T to c1900-universalk9-mz.SPA.152-3.T (it was a 1921 BTW!) and everything dropped into place. The image i replaced is still available for download!