Policy based routing within vrf not catching traffic.

[daniel.miller1]

I am trying to direct traffic coming from another router and forward it to an IP address that is not directly connected to the outgoing interface.

I have tried applying the access list outbound to the interface and hit counters increment so I know the router can recognize the traffic.  As soon as I apply it as a policy based route to the interface, it seems like it cant find the traffic and forward it like I want.  ive tried 'recursive', 'set ip vrf' within the route map, 'set default interface', etc... but traffic still wants to go to the default of .66.  it seems like it is ignoring the PBR and using the default vrf table.  what am I missing?  thanks.  please let me know if more info is needed.

7204vxr Version 12.4(24)T4

ip vrf 
rd 5771:60023
route-target export 5771:60023
route-target import 5771:60023
!

interface GigabitEthernet0/2.108
encapsulation dot1Q 108
ip vrf forwarding vrf
ip address 10.242.60.65 255.255.255.248
no ip redirects
no ip proxy-arp
ip mtu 1500
ip policy route-map pbr
!

ip access-list extended acl_108
permit ip host 10.10.12.76 10.226.59.0 0.0.0.255 log
permit ip host 10.10.12.77 10.226.59.0 0.0.0.255 log
permit ip host 10.10.12.80 10.226.59.0 0.0.0.255 log
!

route-map pbr permit 10
match ip address acl_108
set ip vrf vrf next-hop 10.242.60.68
set default interface GigabitEthernet0/2.108
!
route-map pbr permit 20
!

pe01#show route-map
route-map pbr, permit, sequence 10
Match clauses:
ip address (access-lists): acl_108
Set clauses:
ip vrf vrf next-hop 10.242.60.68
default interface GigabitEthernet0/2.108
Policy routing matches: 0 packets, 0 bytes
route-map pbr, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 4431693 packets, 1083168116 bytes

pe01# show ip route vrf vrf

Routing Table: vrf
Gateway of last resort is 10.242.60.66 to network 0.0.0.0

x.y.z.a/29 is subnetted, 2 subnets
S x.y.z.a [1/0] via 10.242.60.66
S x.y.z.a [1/0] via 10.242.60.66
10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
B 10.10.12.0/22 [200/0] via p.q.r.s, 3w0d
B 10.11.12.0/24 [200/0] via p.q.r.s, 3w0d
C 10.242.60.64/29 is directly connected, GigabitEthernet0/2.108
B 10.242.30.84/30 [200/0] via p.q.r.s, 3w0d
a.b.c.d/28 is subnetted, 1 subnets
B a.b.c.d [200/0] via p.q.r.s, 3w0d
S* 0.0.0.0/0 [1/0] via 10.242.60.66

pe01.usac#show ip policy
Interface       Route map
Gi0/2.108     pbr

[Francesco Molino]

Hi

The sequence permit 20 isn't important as by default, traffic not catched will follow the normal routing. You can remove the statement.

For the sequence 10, you're using an acl with log keyword that's not supported by pbr.

Can you remove this keyword in all your ace and test again please?

[daniel.miller1]

thanks for reply, I was skimming around and saw that suggestion too, (that the log statement may force processing to a different level and not allow to process properly)
I did remove 'log' and have been testing.

of interest:

route map incremented some traffic while I had the ACL blown away to change. stopped incrementing after new acl in place.

pe01#show route-map
route-map pbr, permit, sequence 10
Match clauses:
ip address (access-lists): acl_108
Set clauses:
ip vrf vrf next-hop 10.242.60.68
default interface GigabitEthernet0/2.108
Policy routing matches: 25 packets, 1600 bytes



debug policy: the access list appears to be inspecting some traffic, particularly from .83 but still not seeing from .76.

pe01.anthc.anc.usac#show log | inc 10.10.12.
Feb 8 19:55:34.425 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 44, FIB policy match
Feb 8 19:55:34.425 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 44, PBR Counted
Feb 8 19:55:34.425 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 44, FIB policy rejected - normal forwarding
Feb 8 19:55:34.425 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 53, FIB policy match
Feb 8 19:55:34.425 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 53, PBR Counted
Feb 8 19:55:34.425 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 53, FIB policy rejected - normal forwarding
Feb 8 19:55:34.429 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 40, FIB policy match
Feb 8 19:55:34.429 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 40, PBR Counted
Feb 8 19:55:34.429 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 40, FIB policy rejected - normal forwarding
Feb 8 19:55:34.429 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 40, FIB policy match
Feb 8 19:55:34.429 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 40, PBR Counted
Feb 8 19:55:34.429 AKST: IP: s=10.226.59.10 (GigabitEthernet0/2.108), d=10.10.12.83, len 40, FIB policy rejected - normal forwarding
pe01#show log | inc 10.10.12.7
pe01#

[daniel.miller1]

 duplicate response.  I guess my posts took a while to show up.

debug policy:  it appears it processes some of the PBR, but im just not catching traffic from 10.10.12.7x... im wondering now if its even coming to me...

[Francesco Molino]

Can you share more information about your design to validate that pbr is applied on the right interface?

Also why having a set clause interface with the same interface on which PBR is applied to?

Can you ping your next hop up?

On your debug, it saying FIB policy refected and doing a normal forwarding, that means pbr isn't working.

[daniel.miller1]

sure.  

"Can you share more information about your design to validate that pbr is applied on the right interface?"

MPLS PE routers in separate cities. one PE router is at customer prem in one city, directly attached to customer.  other PE router is in another city directly attached to customer.

network->customer rtr->PE->vpnv4 mpls->PE->customer rtr->network

"Also why having a set clause interface with the same interface on which PBR is applied to?"

I am trying anything possible to catch traffic and force it out the int gi0/2.108.  I have removed that statement with no change.  will gladly try again.

"Can you ping your next hop up?"

yes sir.

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.242.60.65, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
pe01#ping vrf vrf 10.242.60.68

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.242.60.68, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
pe01#

"On your debug, it saying FIB policy refected and doing a normal forwarding, that means pbr isn't working."

hmm.  I see.  I was taking it as evidence that it was attempting to match, but not finding a match and rejecting based on not finding the match.  is this not working because it has an MPLS label?  i attempted to set mpls-lable in the route-map but that didnt change anything.

[daniel.miller1]

more testing:   an access list applied outbound is showing that traffic is attempting to go where I want it to, but the route map cant find it and direct traffic.  toggled 'set mpls-label' and doesnt seem to help.  im reading that PBR may not be supported coming out of mpls.  if that is the case I may have to try moving it to the incoming upstream router before it gets encapsulated.

interface GigabitEthernet0/2.108
 encapsulation dot1Q 108
 ip vrf forwarding vrf
 ip address 10.242.60.65 255.255.255.248
 ip access-group 105 out
 no ip redirects
 no ip proxy-arp
 ip mtu 1500
 ip policy route-map pbr
!

access-list 105 permit ip host 10.10.12.76 10.226.59.0 0.0.0.255 log
access-list 105 permit ip host 10.10.12.77 10.226.59.0 0.0.0.255 log
access-list 105 permit ip host 10.10.12.80 10.226.59.0 0.0.0.255 log
access-list 105 permit ip any any

!

show log:

Feb 9 14:39:18.223 AKST: %SEC-6-IPACCESSLOGP: list 105 permitted tcp 10.10.12.76(49210) -> 10.226.59.10(28500), 1 packet
Feb 9 14:41:18.381 AKST: %SEC-6-IPACCESSLOGP: list 105 permitted tcp 10.10.12.76(49211) -> 10.226.59.10(28500), 1 packet
Feb 9 14:42:29.470 AKST: %SEC-6-IPACCESSLOGP: list 105 permitted tcp 10.10.12.77(2054) -> 10.226.59.10(7780), 1 packet
Feb 9 14:44:29.471 AKST: %SEC-6-IPACCESSLOGP: list 105 permitted tcp 10.10.12.76(49210) -> 10.226.59.10(28500), 5 packets
Feb 9 14:46:29.473 AKST: %SEC-6-IPACCESSLOGP: list 105 permitted tcp 10.10.12.76(49211) -> 10.226.59.10(28500), 1 packet

pe01# show route-map
route-map pbr, permit, sequence 10
Match clauses:
ip address (access-lists): acl_108
Set clauses:

mpls label
ip vrf vrf next-hop 10.242.60.68
ip next-hop recursive 10.242.60.68
default interface GigabitEthernet0/2.108
Policy routing matches: 0 packets, 0 bytes

[Richard Burts]

The best clue for identifying the problem is this "force it out the int gi0/2.108". You are applying the ip policy statement on the outbound interface. But for PBR to work you need to apply the statement on the inbound interface that receives the traffic rather than on the outbound interface.

HTH

Rick

[Francesco Molino]

Totally agree with Richards, that's why I asked at the beginning:

Also why having a set clause interface with the same interface on which PBR is applied to?

Anyway, can you share a quick drawing showing your mpls cloud and where you're trying to apply PBR?