policy_routing_top

Due to some winter illness and the fact that I had to swap cables with my home production network to make this topology work, it took some time to physically put this all together, so getting it setup just to lab was quite the undertaking but once all said and done I have this to show for it:

R1#show ip route ospf
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/66] via 172.12.123.3, 00:15:03, Serial0/0
     5.0.0.0/32 is subnetted, 1 subnets
O       5.5.5.5 [110/2] via 172.12.15.5, 00:15:03, FastEthernet0/1
     172.12.0.0/24 is subnetted, 4 subnets
O       172.12.34.0 [110/65] via 172.12.123.3, 00:15:03, Serial0/0
O       172.12.24.0 [110/65] via 172.12.123.2, 00:15:03, Serial0/0
R1#

And that is what I am looking for, now let’s set some Policy Routing, and we will test if it is working / what is happening on the network with the “traceroute” command. Essentially we are working from R5, going through the NBMA to gets to network 4.4.4.4 on R4. So appropriately, I will start this off with a traceroute to see what our path looks like:

R5#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.15.1 4 msec 0 msec 4 msec
  2 172.12.123.3 32 msec 32 msec 32 msec
  3 172.12.34.4 32 msec *  32 msec

So it is taking the R3 path to get to R4’s loopback, however I want traffic going to 4.4.4.4 to take R2’s path through the topology, so these are the things required to make this work:

  • Create Standard or Extended ACL to match traffic on incoming interface
  • Create route-map and match the ACL with “match ip address (acl #)”
  • In route-map “set ip next-hop” to create the clause routing the traffic
  • Apply to incoming interface of traffic with “ip policy route-map (name)”

I will just be using a standard ACL to route all traffic coming from R5 to R2, using the remote interface address and not a network address, and lets see what happens:

R1(config)#access-list 5 permit 172.12.15.5 0.0.0.255
R1(config)#route-map R5toR2 permit 10
R1(config-route-map)#match ip add 5

R1(config-route-map)#set ip next-hop ?
  A.B.C.D              IP address of next hop
  dynamic              application dynamically sets next hop
  peer-address         Use peer address (for BGP only)
  recursive            Recursive next-hop
  verify-availability  Verify if nexthop is reachable

R1(config-route-map)#set ip next-hop 172.12.123.2 ?
  A.B.C.D  IP address of next hop
  <cr>

R1(config-route-map)#set ip next-hop 172.12.123.2 1.1.1.1 ?
  A.B.C.D  IP address of next hop
  <cr>

R1(config-route-map)#set ip next-hop 172.12.123.2 1.1.1.1 2.2.2.2 ?
  A.B.C.D  IP address of next hop
  <cr>

R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#int fa0/1
R1(config-if)#ip policy route-map R5toR2
R1(config-if)#

I’ve highlight the actual configs needed to make this route-map work (remember it must be configured on the router with incoming traffic), and I’ve also left a curious discovery in the output, that the next-hop option allows you to keep putting in IP addresses. I assume it is for redundancy if one of the next-hop IP’s becomes unavailable it has others to try.

However, that being said, lets try another ping to 4.4.4.4:

R5#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.15.1 4 msec 0 msec 4 msec
  2 172.12.123.2 32 msec 32 msec 32 msec
  3 172.12.123.1 24 msec 24 msec 24 msec
  4 172.12.123.3 56 msec 56 msec 52 msec
  5 172.12.34.4 56 msec *  52 msec
R5#

That is what is referred to in the CCNP industry as sub-optimal routing at its finest, though not quite a routing loop, although it’d be easy to create with PBR. To understand why this is happening, you must examine R2’s route table, and how it see’s routes to destinations:

R2#show ip route

Gateway of last resort is not set

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/66] via 172.12.123.3, 01:08:58, Serial0/0
     5.0.0.0/32 is subnetted, 1 subnets
O       5.5.5.5 [110/66] via 172.12.123.1, 01:08:58, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O       172.12.34.0 [110/65] via 172.12.123.3, 01:08:58, Serial0/0
O       172.12.15.0 [110/65] via 172.12.123.1, 01:08:58, Serial0/0
C       172.12.24.0 is directly connected, FastEthernet0/1
C       172.12.123.0 is directly connected, Serial0/0
R2#

So R2 is getting this traffic, looking at its own route table, and sending the traffic back out it’s Serial0/0 interface to reach what it knows as the route to 4.4.4.4 being 172.12.123.3. So the traceroute traffic comes back to R1 no longer with the route-map being applied both because the source address is different (R2 is source address now), but also because the the Serial0/0 interface on R1 has no route-map so it will route it as normal to 172.12.123.3 to deliver the traffic.

The moral of the story, is that blanket Policy Routing with a Standard ACL has it’s place in some networks, but it is a good way to introduce sub-optimal routing on the network.

I intended to finish with Extended Access-List usage to save the day, but I’ll save that for another post, as I am starting to feel blah again. I will “wr mem” all routers so we can go through how to correct this madness on my next post, hope to see you there!

*** Also one detail I always miss with OSPF / NBMA, ALWAYS USE NEIGHBOR STATEMENTS FROM HUBS TO SPOKES FOR ADJACENCIES TO FORM! (AND DON’T FORGET IP OSPF PRI 0 ON SPOKES INTERFACES!) ***