Policy-based routing

Just a small lab taking a closer look at how policy-based routing works.

Requirements:

  1. Configure a default-route on R3 towards R1s local interface (Gi1.13)
  2. Configure a default-route on R4 & R6 towards R1s local interface (Gi1.146)
  3. Configure a default-route on R5 towards R1s DMVPN-interface (Tu0)
  4. Configure static routes thru the DMVPN-cloud on R3 for R5’s Lo0, and vice versa on R5 for R3’s lo0
  5. Configure policy-routing on R1 so that traffic sourced from R4s G1.146 is routed to R3 over Gi1.13
  6. Configure policy-routing on R1 so that traffic sourced from R6s Gi1.146 is routed to R5 over DMVPN

Let’s start with the basic static routes first:

! 1-1 R3

ip route 0.0.0.0 0.0.0.0 Gi1.13 155.1.13.1

! 2-1 R4 & R6

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! 3-1 R5

ip route 0.0.0.0 0.0.0.0 Tu0 155.1.0.1

! 4-1
! R3

ip route 150.1.5.5 255.255.255.255 Tu0 155.1.0.5

! R5

ip route 150.1.3.3 255.255.255.255 Tu0 155.1.0.3

That should be all the routing we need to start with. Notice however that R1 doesn’t have a clue what to do with the packets trying to reach loopbacks and will instead timeout.

R1#sh ip route static 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 a - application route
 + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

R1#

We’ll solve this problem by using policy-based routing and manually setting next-hop ip-address depending on source address instead. First we need access-lists to separate traffic coming from R4 and R6.

ip access-list extended SRC-R4
 10 permit ip host 155.1.146.4 any
ip access-list extended SRC-R6
 10 permit ip host 155.1.146.6 any

Next step is to use a route-map to manually set the next-hop address depending on which ACL matches.

route-map PBR_LAB permit 10

 match ip address SRC-R4
 set ip next-hop 155.1.13.3
route-map PBR_LAB permit 20
 match ip address SRC-R6
 set ip next-hop 155.1.0.5

Last step is to activate policy-based routing on our incoming interface, in this case R1s Gi1.146.

interface Gi1.146
 ip policy route-map PBR_LAB

All done! To verify that traffic is routed correctly we can use traceroute.

R4#ping 150.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/10 ms

R4#traceroute 150.1.3.3
Type escape sequence to abort.
Tracing the route to 150.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 4 msec 4 msec
 2 155.1.13.3 4 msec * 3 msec

R6#ping 150.1.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/12/27 ms

R6#traceroute 150.1.5.5
Type escape sequence to abort.
Tracing the route to 150.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 5 msec 4 msec
 2 155.1.0.5 5 msec

R1#sh route-map 
route-map PBR_LAB, permit, sequence 10
 Match clauses:
 ip address (access-lists): SRC-R4 
 Set clauses:
 ip next-hop 155.1.13.3
 Policy routing matches: 20 packets, 1280 bytes
route-map PBR_LAB, permit, sequence 20
 Match clauses:
 ip address (access-lists): SRC-R6 
 Set clauses:
 ip next-hop 155.1.0.5
 Policy routing matches: 14 packets, 1004 bytes

If we however change the source-address in either R4 or R6 our access-list in R1 will no longer match, so packets will just timeout instead.

R6#ping 150.1.5.5 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
Packet sent with a source address of 150.1.6.6 
.....
Success rate is 0 percent (0/5)

For more information how to configure policy-based routing I managed to find the section in CiscoDoc at: 

Configuration Guides -> IP Routing: Protocol-Independent Configuration Guide – > Policy-based Routing

 

Policy-based Routing – The Basics

Detta blir ett kort inlägg om policy-based routing där vi återigen använder oss av route maps för att modifiera routingen.

Satte upp följande topologi med OSPF som routing-protokoll:

Policy-based routing

Låt oss säga att vi nu vill göra en form av lastbalansering och skicka trafik som ska till 10.1.1.0/24 & 10.1.2.0/24 via R3, och trafik till 10.1.3.0/24 & 10.1.4.0/24 via R4. Möjligtvis hade vi kunnat åstadkomma detta genom att justera metrics i en evighet men det går att lösa betydligt enklare med hjälp av “Policy-based routing”.

Vi skapar först två access-listor:

access-list 100 permit ip any 10.1.1.0 0.0.0.255
access-list 100 permit ip any 10.1.2.0 0.0.0.255
access-list 110 permit ip any 10.1.3.0 0.0.0.255
access-list 110 permit ip any 10.1.4.0 0.0.0.255

Och sedan tillhörande route-map:

route-map PBR permit 10
 match ip address 100
 set ip next-hop 10.23.0.3

route-map PBR permit 20
 match ip address 110
 set ip next-hop 10.24.0.4

Till skillnad från gårdagens distribution-lab så aktiverar vi policy-routing på önskat interface, i detta fall R2’s fa1/0 mot R1:

interface FastEthernet1/0
 no switchport
 ip address 10.12.0.2 255.255.255.0
 ip policy route-map PBR

Detta gäller dock endast trafik som flödar GENOM routern, om vi även vill applicera en policy på trafik som genereras från den egna router används kommandot: ip local policy route-map PBR.

Gör vi nu en traceroute från R1 kan vi se effekten detta har:

Tracing the route to 10.1.1.1
1 10.12.0.2 40 msec 40 msec 32 msec
 2 10.23.0.3 56 msec 52 msec 40 msec
 3 10.35.0.5 84 msec * 56 msec
Tracing the route to 10.1.2.1
1 10.12.0.2 60 msec 40 msec 24 msec
 2 10.23.0.3 60 msec 44 msec 24 msec
 3 10.35.0.5 68 msec * 68 msec
Tracing the route to 10.1.3.1
1 10.12.0.2 32 msec 64 msec 28 msec
 2 10.24.0.4 60 msec 44 msec 44 msec
 3 10.45.0.5 44 msec * 64 msec
Tracing the route to 10.1.4.1
1 10.12.0.2 44 msec 56 msec 20 msec
 2 10.24.0.4 60 msec 24 msec 52 msec
 3 10.45.0.5 52 msec * 44 msec

Genom debug-kommandot “debug ip policy” kan vi se vad som sker när vi pingar från R1 (10.12.0.1) till R5’s 10.1.3.1 in action:

*Mar 1 00:33:04.367: IP: s=10.12.0.1 (FastEthernet1/0), d=10.1.3.1, len 28, FIB policy match
*Mar 1 00:33:04.367: IP: s=10.12.0.1 (FastEthernet1/0), d=10.1.3.1, g=10.24.0.4, len 28, FIB policy routed
*Mar 1 00:33:04.411: IP: s=10.12.0.1 (FastEthernet1/0), d=10.1.3.1, len 28, FIB policy match
*Mar 1 00:33:04.411: IP: s=10.12.0.1 (FastEthernet1/0), d=10.1.3.1, g=10.24.0.4, len 28, FIB policy routed

Easy! 🙂