Query re Policy Routing set interface command

From: Roy Waterman (roy.waterman@gmail.com)
Date: Wed Jan 07 2009 - 12:03:38 ARST


Hi ppl I have a question regarding the operation of Policy Routing when
using the set interface command.

This is going to be somewhat lengthy so apologies in advance :)

The topology goes:

   - PC1 f0/0 ---- (10.1.123.0/24) ---- f0/0 R3

   - R3 f0/1 ---- (172.16.34.0/24) ---- f0/1 R4 --- (172.16.46.0/24) ---
                        f0/0 R6

   - R3 s0/1 --- DLCI 306 --- (172.16.36.0/24) (FR Switch) --- DLCI 603 ---
                        s0/1 R6

   - R3 s0/0 ---- (172.16.35.0/24) ---- s0/0 R5 --- (172.16.56.0/24) ---
                        s0/0 R6

OSPF is being used on R3, R4, R5 and R6.

R6 has a loopback interface with IP: 60.60.60.60 which is advertised by
OSPF.

The least cost path to 60.60.60.60 as seen by R3 is via R4 (total metric of
10+10+1).

Ok, now on R3 I have the following config:

   - access-list 100 permit icmp host 10.1.123.1 host 60.60.60.60

   - route-map POLICY permit 30
    match ip address 100
    match length 100 100
    set interface Serial0/1 <=== FR link to R6

   - interface FastEthernet0/0
    ip address 10.1.123.3 255.255.255.0
    ip policy route-map POLICY <=== PBR applied to incoming int f0/0

Ok, so when I ping from PC1 (10.1.123.1) to 60.60.60.60 with a byte size of
100, I expect PBR to policy route those packets out R3 s0/1.
However, I also expected that R3 checks its frame map for the destination of
60.60.60.60, sees if it has a L3 to L2 mapping for the destination
60.60.60.60 and if so, passes the icmp on its merry way to R6.

However! (again), what actually happens is that:

   - R3 seems to check the FIB for destination 60.60.60.60
   - R3 sees that it is learnt via R3s link to R4 (next hop ip 172.16.34.4)
   - R3 then USES the next hop ip of 172,16.34.4 and sees if there is a
   corresponding Frame Relay L3 to L2 mapping for 172.16.34.4, and if there is,
   things work...

OK, to test this, with the 60.60.60.60 mapping:

   - R3(config-if)#*frame map ip 60.60.60.60 306*
   R3(config-if)#^Z
   - PC1#*ping ip 60.60.60.60 repeat 1 size 100*

   Type escape sequence to abort.
   Sending 1, 100-byte ICMP Echos to 60.60.60.60, timeout is 2 seconds:
   . <======================
   Success rate is 0 percent (0/1)
   - R3#
   *Mar 1 22:10:34.450: IP: s=10.1.123.1 (FastEthernet0/0), d=60.60.60.60,
   len 100, FIB policy match
   *Mar 1 22:10:34.454: IP: s=10.1.123.1 (FastEthernet0/0), d=60.60.60.60,
   len 100, policy match
   *Mar 1 22:10:34.454: IP: route map POLICY, item 30, permit
   *Mar 1 22:10:34.458: IP: s=10.1.123.1 (FastEthernet0/0), d=60.60.60.60
   (Serial0/1), len 100, policy routed
   *Mar 1 22:10:34.458: IP: *FastEthernet0/0 to Serial0/1 172.16.34.4*
   *Mar 1 22:10:34.462: Serial0/1:*Encaps failed--no map entry link 7(IP)*

With the 172.16.34.4 mapping:

   - R3(config-if)#*frame map ip 172.16.34.4 306
   *R3(config-if)#^Z
   - PC1#*ping ip 60.60.60.60 repeat 1 size 100
   *
   Type escape sequence to abort.
   Sending 1, 100-byte ICMP Echos to 60.60.60.60, timeout is 2 seconds:
   ! <===================
   - R3#
   *Mar 1 22:29:07.578: IP: s=10.1.123.1 (FastEthernet0/0), d=60.60.60.60,
   len 100, FIB policy match
   *Mar 1 22:29:07.582: IP: s=10.1.123.1 (FastEthernet0/0), d=60.60.60.60,
   len 100, policy match
   *Mar 1 22:29:07.582: IP: route map POLICY, item 30, permit
   *Mar 1 22:29:07.582: IP: s=10.1.123.1 (FastEthernet0/0), d=60.60.60.60
   (Serial0/1), len 100, policy routed
   R3#
   *Mar 1 22:29:07.586: IP: FastEthernet0/0 to Serial0/1 172.16.34.4

I saw a similar behaviour regardless of whichever interface I used for the
set interface command.
Namely that R3 would check FIB for next hop IP, and then try to find a L3 to
L2 entry (via ARP or otherwise dependent on interface) for the interface
mentioned in *set interface*

According to the following Cisco doc: Understanding Policy Based Routing (
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009481d.shtml),
it mentions checking for a L2 entry for
the destination (in this case 60.60.60.60)...

Has the behaviour changed or I am missing something here?

Please advise.

-- 
Regards
Roy

Blogs and organic groups at http://www.ccie.net



This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:36 ARST