Policy based routing on 1921 ip base license...not working?

[jasonhumes]

Hi

We've got three routers, one 1921 and two 1811.  We've configured policy based routing on these two devices, and it seems to be working fine for the one router 1811, but on the 1921, the policy routing doesn't seem to be doing anything/working.  The 1921 is an ip base license...does this need to be DATA for PBR to work?

What we are trying to do is have the 1921 control internal routing to one of the external/edge 1811 routers.  One of the 1811 routers is the normal default route and the other should only be used as directed by the policy route config...which is as follows;

interface facing the server 0/0.10

encap dot1q 10

desc servers

ip add 192.168.40.1 255.255.255.0

ip policy route-map owa_policy_route

!

ip access-list extended owa_policy_route

permit tcp host 192.168.40.21 eq 443 any

!

route-map owa_policy_route permit 10

match ip address owa_policy_route

set ip default next-hop 192.168.109.252   (internal IP of the 1811)

!

Any thoughts?

Thanks.

[cadet alain]

Hi,

Could it simply be that you typed the ACL wrong and it should be:

ip access-list extended owa_policy_route

permit tcp host 192.168.40.21 any eq 443

Regards.

Alain

Don't forget to rate helpful posts.

[jasonhumes]

No, it’s the response from the server, which is the owa, that we want going out the other feed.  So when users connect to him in from this second feed, he has to respond back out that second feed.

Your version would force traffic from this host, destined to TCP443 out that feed, but its the traffic from this host SOURCE tcp443 we need to control.

Make sense?

Thanks.

[cadet alain]

Hi,

ok makes sense.

What does sh access-list, sh route-map and debug ip policy is telling ?

Regards.

Alain

Don't forget to rate helpful posts.

[jasonhumes]

The ACL shows no hits, the route-map shows no matches and a debug shows nothing either...which is what leads me to believe it's a license/bug issue?

[cadet alain]

Hi,

which IOS image have you got ?

Regards.

Alain

Don't forget to rate helpful posts.

[jasonhumes]

c1900-universalk9-mz.SPA.152-2.T.bin

[cadet alain]

Hi,

Cisco feature navigator tells us this is implemented on your IOS/licence.

Regards.

Alain

Don't forget to rate helpful posts.

[jasonhumes]

I'm not sure I follow...are you saying according this Cisco this should work, and since it's not it's a bug...I also checked the feature tool before opening this post, but as I've seen in the past, that tool is not the final word/gospel and MANY times we've found features that should be that just are not.

Thanks...waiting on Cisco TAC to chime in now.

[cadet alain]

Hi,

Yes if we believe what they say there it is supported, I don't have acces to bug toolkit so if it is referenced there I can't tell you.

Regards.

Alain

Don't forget to rate helpful posts.

[Karsten Iwen]

At least you could upgrade to 15.2.2T2, That release has "two rounds" of bugfixes applied compared to your release. But if you don't need the 15.2 or 15.1-features, I would go for 15.0(1)M8.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Mohamed Sobair]

Jason,

I believe Your Policy Based Routing should be modified to the following:

interface facing the server 0/0.10

encap dot1q 10

desc servers

ip add 192.168.40.1 255.255.255.0

ip policy route-map owa_policy_route

!

ip access-list extended owa_policy_route

permit tcp host 192.168.40.21 eq 443 any

!

route-map owa_policy_route permit 10

match ip address owa_policy_route

set ip next-hop 192.168.109.252   (internal IP of the 1811) ------------  Remove the ((default)) keyword from this statement.

The reason is because the desfault keyword (set ip default next-hop) instructs the router to look for an exact match for the host route (192.168.40.21).  although this server is directly connected to the router, the router sees the WHOLE Network 192.168.40.0/24 as a CONNECTED, but it doesnt have an EXACT MATC For (192.168.40.21/32) in its routing table.

Try doing it without the Default keyword and you should be fine.

Thanks,

Mohamed

[inakigb10]

I reaplaced an 861 router with a 1921 with IP Base.

The same policy map with same interfaces location does not work on the 1921, did some debugs on the 1921 and seems is not paying attention to the policy map on the interface. Had to revert back an put 861 in place.

Has TAC confirmed you do not need "DATA" feature license to run policy routing on 1900?

[jasonhumes]

Unfortunately, after two weeks of working at this with TAC, having them demo and it and prove that they too couldn't get it working as it was on earlier hardware...wouldn't confirm or deny the bug and we ended up having a work around which involved moving some gateways around and doing our policy routing on another device, which actually paid attention to the full configuration.  We've not had this particular scenario come up since, so I can't confirm or deny if it is still an issue.

Thanks

Jason

[inakigb10]

I got it working in a setup with PAT from WAN to LAN on tcp port 80.

This is what i got from the "debug ip policy" after 3 attempts to connect to webserver on 192.168.0.243:

000037: *Dec 18 04:45:20.891 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, len 52, FIB policy match

000038: *Dec 18 04:45:20.891 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, len 52, PBR Counted

000039: *Dec 18 04:45:20.891 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, g=172.21.252.2, len 52, FIB policy routed

000040: *Dec 18 04:45:23.903 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, len 52, FIB policy match

000041: *Dec 18 04:45:23.903 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, len 52, PBR Counted

000042: *Dec 18 04:45:23.903 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, g=172.21.252.2, len 52, FIB policy routed

000043: *Dec 18 04:45:25.291 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, len 52, FIB policy match

000044: *Dec 18 04:45:25.291 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, len 52, PBR Counted

000045: *Dec 18 04:45:25.291 UTC: IP: s=192.168.0.243 (GigabitEthernet0/1), d=172.23.23.1, g=172.21.252.2, len 52, FIB policy routed

From the debug and the hits on the route map it seemed the packets were being policy routed properly:

Customer-Core#
Customer-Core#sh access-lists  AvoidPAT
Extended IP access list AvoidPAT
    10 permit tcp host 192.168.0.243 eq 443 172.23.23.0 0.0.0.255
    20 permit tcp host 192.168.0.243 eq smtp 172.23.23.0 0.0.0.255
    30 permit tcp host 192.168.0.243 eq www 172.23.23.0 0.0.0.255 (3 matches)

Customer-Core#
Customer-Core#sh route-map  AvoidPAT
route-map AvoidPAT, permit, sequence 10
  Match clauses:
    ip address (access-lists): AvoidPAT
  Set clauses:
    ip next-hop 172.21.252.2
Nexthop tracking current: 0.0.0.0
172.21.252.2, fib_nh:0,oce:0,status:0
  Policy routing matches: 3 packets, 396 bytes

Customer-Core#
Customer-Core#sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
Embedded-Service-Engine0/0 unassigned      YES NVRAM  administratively down down
GigabitEthernet0/0         X.X.X.X    YES NVRAM  up                    up
GigabitEthernet0/1         192.168.0.1     YES NVRAM  up                    up
Serial0/0/0                unassigned      YES NVRAM  administratively down down
Loopback1                  172.21.252.1    YES NVRAM  up                    up
NVI0                       X.X.X.X    YES unset  up                    up

However a dummy ACL just to log all packets in or out of Loopback1 had no hits.

After trying several things, I thought of not using hardware switching (no ip route-cache cef) on the inside interface, and I got it working:

000098: *Dec 18 05:31:43.079 UTC: %SEC-6-IPACCESSLOGP: list LogALL permitted tcp 192.168.0.243(0) -> 172.23.23.2(0), 133 packets