Category Archives: Policy Based Routing

IP SLA configuration, verification, “object tracking” configured and explained, quite an extensive subject and read so brace yourself!

SLA_Topology_New

IP SLA explanation and examples of when to use it

An IP SLA (Service Level Agreement) is an agreement between the Service Provider and (you) the customer, that you will get an agreed upon level of uptime / bandwidth for your money, and IP SLA configuration on a router is a mechanism to measure and verify that the service being provided by the carrier is within the agreed upon SLA.

This tracking can include both the uptime of service, and the bandwidth speed measured by the delay, when sending a packet to a destination and receiving a reply back.

It can be sent back to some sort of third party Syslog server to display in a nice graphical format for “Accounting” purposes to keep your ISP honest, however it is also used by other features at Layer 3 on the CLI that we as ROUTE candidates are interested in!

For example, and this is from the SWITCH Exam material, but HSRP (Hot Standby Routing Protocol) which runs on the LAN between a fail-over pair of Routers, that have identical configurations and remain in an Active / Standby role in case the Active router goes down it can fail over to the Standby.

As HSRP runs on the LAN side (making it a SWITCH topic), you can tie it back to IP SLA configurations, so if the Active router stops getting responses back from pings sent out its ISP gateway HSRP can tell the Standby router to make itself the Active router.

On a more ROUTE topic, you can also tie it into PBR, as Policy Routing does no kind of polling to verify the next hop you configured is alive / reachable – This is where IP SLA can be configured and tied into the PBR configuration to verify the configured next hop.

IP SLA configuration concepts and IP SLA Terminology (what things are called)

The most common use for IP SLA is to generate traffic originating from the local router in the form of a ping to another IP address, to confirm its reachable, you can measure much more detailed information such as Delay and Jitter but for the ROUTE we will keep it to tracking some pings.

Also you can configure multiple “SLA Operations” to multiple different destinations, that generate different types of traffic, to track completely different types of data statistics at the same time.

When configuring an “Operation” of IP SLA, the local router sending the traffic is called the “Sender”, and the destination device is called the “Receiver” and can be a router or a host depending on what kind of traffic you are sending / requesting back.

For example if an “Operation” is configured as a simple ping / response, the “Receiver” could be a laptop on a  remote network, as that device could respond back to the ping.

If you want more details like timestamps / delay it took to respond on the remote device / etc, you will need a “Receiver” like a Cisco router, that is capable of generating that “Operations” request as a regular web server or laptop may not be able to send the requested data (also things like looking at Jitter / Delay / other values).

Here is a quick list for exam day purposes of what types of traffic can be configured:

  • ICMP – Pings, jitter
  • RTP – VOIP traffic
  • TCP – Established Connections
  • UDP – Pings, jitter
  • DNS
  • HTTP
  • FTP

Although for detailed data (anything outside a ping response), you would need to configure the remote router to respond to the “Operation” configuration correctly.

However for ROUTE exam and really from what I’ve seen, the most common “Operation” to configure and troubleshoot is for pings / internet connectivity to the ISP, so that is what I will be configuring.

Enough theory and definitions, lets get configuring:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip sla ?
  <1-2147483647>          Entry Number
  auto                    IP SLAs Auto Configuration
  enable                  Enable Event Notifications
  ethernet-monitor        IP SLAs Auto Ethernet Configuration
  group                   Group Configuration or Group Scheduling
  key-chain               Use MD5 Authentication for IP SLAs Control Messages
  logging                 Enable Syslog
  low-memory              Configure Low Water Memory Mark
  reaction-configuration  IP SLAs Reaction-Configuration
  reaction-trigger        IP SLAs Trigger Assignment
  reset                   IP SLAs Reset
  responder               Enable IP SLAs Responder
  restart                 Restart An Active Entry
  schedule                IP SLAs Entry Scheduling

R1(config)#ip sla 1 ?
  <cr>

R1(config)#ip sla 1
R1(config-ip-sla)#

To start just from Global configuration mode, type “ip sla #”, and it will drop you into SLA configuration mode to configure the “operation”. I will break this up into different segments of ? output as there is quite a bit:

First looking at “Operation” options

R1(config-ip-sla)#?
IP SLAs entry configuration commands:
  dhcp         DHCP Operation
  dns          DNS Query Operation
  ethernet     Ethernet Operations
  exit         Exit Operation Configuration
  ftp          FTP Operation
  http         HTTP Operation
  icmp-echo    ICMP Echo Operation
  icmp-jitter  ICMP Jitter Operation
  path-echo    Path Discovered ICMP Echo Operation
  path-jitter  Path Discovered ICMP Jitter Operation
  tcp-connect  TCP Connect Operation
  udp-echo     UDP Echo Operation
  udp-jitter   UDP Jitter Operation
  voip         Voice Over IP Operation

R1(config-ip-sla)#icmp-echo ?
  Hostname or A.B.C.D  Destination IP address or hostname, broadcast disallowed

R1(config-ip-sla)#icmp-echo 5.5.5.5 ?
  source-interface  Source Interface (ingress icmp packet interface)
  source-ip         Source Address
  <cr>

R1(config-ip-sla)#icmp-echo 5.5.5.5 source-ip 1.1.1.1 ?
  <cr>

R1(config-ip-sla)#icmp-echo 5.5.5.5 source-ip 1.1.1.1
R1(config-ip-sla-echo)#

I could have ended it at a destination address, but for the heck of it I configured R1’s loopback to be a source-ip for the operation, so if either loopback goes down I assume the operation bites the dust.

Also note it dropped me into “echo” configuration mode highlighted in red, so I will look at my options using ? again and go from there.

Configuration of the icmp-echo “Operation”:

R1(config-ip-sla-echo)#?
IP SLAs Icmp Echo Configuration Commands:
  default            Set a command to its defaults
  exit               Exit operation configuration
  frequency          Frequency of an operation
  history            History and Distribution Data
  no                 Negate a command or set its defaults
  owner              Owner of Entry
  request-data-size  Request data size
  tag                User defined tag
  threshold          Operation threshold in milliseconds
  timeout            Timeout of an operation
  tos                Type Of Service
  verify-data        Verify data
  vrf                Configure IP SLAs for a VPN Routing/Forwarding instance

R1(config-ip-sla-echo)#frequency ?
  <1-604800>  Frequency in seconds (default 60)

R1(config-ip-sla-echo)#frequency 10 ?
  <cr>

R1(config-ip-sla-echo)#frequency 10
R1(config-ip-sla-echo)#

So I set IP SLA operation # 1 to do an ICMP echo sorced from 1.1.1.1 to remote destination 5.5.5.5 with a frequency of every 10 seconds, now to apply it and get this party started:

R1(config-ip-sla-echo)#exit
R1(config)#ip sla schedule 1 ?
  ageout      How long to keep this Entry when inactive
  life        Length of time to execute in seconds
  recurring   Probe to be scheduled automatically every day
  start-time  When to start this entry
  <cr>

R1(config)#ip sla schedule 1 life ?
  <0-2147483647>  Life seconds (default 3600)
  forever         continue running forever

R1(config)#ip sla schedule 1 life forever ?
  ageout      How long to keep this Entry when inactive
  recurring   Probe to be scheduled automatically every day
  start-time  When to start this entry
  <cr>

R1(config)#ip sla schedule 1 life forever start-time ?
  after     Start after a certain amount of time from now
  hh:mm     Start time (hh:mm)
  hh:mm:ss  Start time (hh:mm:ss)
  now       Start now
  pending   Start pending

R1(config)#ip sla schedule 1 life forever start-time now ?
  ageout     How long to keep this Entry when inactive
  recurring  Probe to be scheduled automatically every day
  <cr>

R1(config)#ip sla schedule 1 life forever start-time now
R1(config)#
ASR#5
[Resuming connection 5 to r5 … ]
[OK]

R5#debug ip packet
IP packet debugging is on

Lets see some IP SLA traffic! :
R5#
May 21 23:02:50.965: IP: tableid=0, s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5 (Loopback5), routed via RIB
May 21 23:02:50.965: IP: s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5, len 64, rcvd 4
May 21 23:02:50.965: IP: tableid=0, s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), routed via FIB
May 21 23:02:50.965: IP: s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), len 64, sending
R5#
May 21 23:03:00.963: IP: tableid=0, s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5 (Loopback5), routed via RIB
May 21 23:03:00.967: IP: s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5, len 64, rcvd 4
May 21 23:03:00.967: IP: tableid=0, s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), routed via FIB
May 21 23:03:00.967: IP: s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), len 64, sending
R5#
May 21 23:03:10.965: IP: tableid=0, s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5 (Loopback5), routed via RIB
May 21 23:03:10.965: IP: s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5, len 64, rcvd 4
May 21 23:03:10.965: IP: tableid=0, s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), routed via FIB
May 21 23:03:10.965: IP: s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), len 64, sending
R5#u all
All possible debugging has been turned off
R5#

As can be seen at the very top, if you exit once from all the way into SLA configuration, it drops you back into Global configuration mode.

From there “ip sla schedule # …” is the command to start the operation and defining for how long / often it should run, I gave mine a “life” of “forever” so it continuously runs forever and a start-time of “now” to turn it on immediately – Though there are options as to how long it runs and when to start it!

As can be seen I hopped over to R5 quick and ran a “debug ip packet” and sure enough we are now seeing a ping sourced from 1.1.1.1 hitting 5.5.5.5 every 10 seconds on the dot!

There are two verification commands, that give two very different outputs

“show ip sla statistics”

R1#sh ip sla stat
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 1 milliseconds
Latest operation start time: 23:12:51.010 UTC Sun May 21 2017
Latest operation return code: OK
Number of successes: 63
Number of failures: 0
Operation time to live: Forever

R1#

I started to highlight the important parts, but its all important, look at that info!

Operation start time, Operation id #, # of successes / fails, operation life time, this gives you the statistics of the operation at work whereas the second command is more geared towards the configuration itself (as you might guess by the name):

“show ip sla configuration”

R1#sh ip sla config
IP SLAs Infrastructure Engine-III
Entry number: 1
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 5.5.5.5/1.1.1.1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
   Operation frequency (seconds): 10  (not considered if randomly scheduled)
   Next Scheduled Start Time: Start Time already passed
   Group Scheduled : FALSE
   Randomly Scheduled : FALSE
   Life (seconds): Forever
   Entry Ageout (seconds): never
   Recurring (Starting Everyday): FALSE
   Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
   Number of statistic hours kept: 2
   Number of statistic distribution buckets kept: 1
   Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
   Number of history Lives kept: 0
   Number of history Buckets kept: 15
   History Filter Type: None

R1#

This will also show a more complete view of life in terms of age-out time and all other fields I didn’t configure, so this is really the command to verify the configuration of the “Operation” where as “statistics” verification command is to see how the operation is succeeding or failing.

How SLA ties into PBR with something called “Enhanced Object Tracking”

I have created an addition to the Topology, a loopback interface, that will represent another route to the destination of 5.5.5.5:

SLA_Topology_New_2

Enhanced Object Tracking is the configuring of “track objects” that detect when the SLA is starting to slip, for example if it misses a ping it can be configured with a delay value so that it will not report back as unreachable until the delay value hits zero.

Track objects are configured because Cisco IOS does not allow for things like HSRP or PBR to refer directly back to IP SLA, however it can refer to a “track object” that then refers to the SLA that is running.

So first things first, the track object must locally reference the SLA # that PBR is also being performed on, so I will need to remove the configs and set them from R4… so one sec here:

R5#debug ip packet
IP packet debugging is on
R5#
May 22 00:07:19.470: IP: tableid=0, s=4.4.4.4 (FastEthernet0/1), d=5.5.5.5 (Loopback5), routed via RIB
May 22 00:07:19.470: IP: s=4.4.4.4 (FastEthernet0/1), d=5.5.5.5, len 64, rcvd 4
May 22 00:07:19.474: IP: tableid=0, s=5.5.5.5 (local), d=4.4.4.4 (FastEthernet0/1), routed via FIB
May 22 00:07:19.474: IP: s=5.5.5.5 (local), d=4.4.4.4 (FastEthernet0/1), len 64, sending
R5#u all
All possible debugging has been turned off
R5#

So we have the same config sourced from 4.4.4.4 going to 5.5.5.5 now.

So the first task is to set configure a track object:

R4(config)#track ?
  <1-1000>    Tracked object
  resolution  Tracking resolution parameters
  timer       Polling interval timers

R4(config)#track 5 ip sla 1 ?
  reachability  Reachability
  state         Return code state
  <cr>

R4(config)#track 5 ip sla 1 reachability ?
  <cr>

R4(config)#track 5 ip sla 1 reachability

Note here it drops me into configuration mode for this tracking object

R4(config-track)#?
Tracking instance configuration commands:
  default        Set a command to its defaults
  default-state  Default object state
  delay          Tracking delay
  exit           Exit from tracking configuration mode
  no             Negate a command or set its defaults

R4(config-track)#delay ?
  down  Delay down change notification
  up    Delay up change notification

R4(config-track)#delay down ?
  <0-180>  Seconds to delay

R4(config-track)#delay down 30 ?
  up  Delay up change notification
  <cr>

R4(config-track)#delay down 30
R4(config-track)#

So it is polling for reachability every 10 seconds, but it now will have a total of 30 seconds before this track object reports it as Down / Unreachable, and for this example we’ll need to tie this track number to an IP route configured for the destination address:

R4(config)#ip route 5.5.5.5 255.255.255.255 172.12.45.5 ?
  <1-255>    Distance metric for this route
  multicast  multicast route
  name       Specify name of the next hop
  permanent  permanent route
  tag        Set tag for this route
  track      Install route depending on tracked item
  <cr>

R4(config)#ip route 5.5.5.5 255.255.255.255 172.12.45.5 track 5

So now the route to that is being tracked, lets look at what it looks like in a some different scenarios on its own, before we involve PBR at all:

“show tracking” to verify your tracked object

R4(config)#do show track
Track 5
  IP SLA 1 reachability
  Reachability is Up
    1 change, last change 00:07:17
  Delay down 30 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    STATIC-IP-ROUTING 0
R4(config)#

So it’s looking pretty good, so lets shut down R5’s loopback and see how this goes:

R4(config)#do sh track
Track 5
  IP SLA 1 reachability
  Reachability is Up, delayed Down (23 secs remaining)
    1 change, last change 00:11:26
  Delay down 30 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 3
  Tracked by:
    STATIC-IP-ROUTING 0
R4(config)#do sh ip sla stat
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 00:21:09 UTC Mon May 22 2017
Latest operation return code: Timeout
Number of successes: 82
Number of failures: 3
Operation time to live: Forever

R4(config)#

Before I could get back to routers to issue the command again, I got this console message:

R4(config)#
May 22 00:21:31.104: %TRACKING-5-STATE: 5 ip sla 1 reachability Up->Down
R4(config)#

So lets look at some things to see what this has changed if anything:

IP Route Table:

R4#sh ip route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [1/0] via 172.12.14.1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback4
      172.12.0.0/16 is variably subnetted, 6 subnets, 2 masks
C        172.12.14.0/24 is directly connected, FastEthernet0/1
L        172.12.14.4/32 is directly connected, FastEthernet0/1
C        172.12.45.0/24 is directly connected, FastEthernet0/0
L        172.12.45.4/32 is directly connected, FastEthernet0/0
C        172.12.55.0/24 is directly connected, Loopback55
L        172.12.55.4/32 is directly connected, Loopback55
R4#

I tried to look at the route more detailed with “sh ip route 5.5.5.5” but said no route exists in the routing table, so I checked CEF to see if the route is even being considered at all:

R4#sh ip cef
Prefix               Next Hop             Interface
0.0.0.0/0            no route
0.0.0.0/8            drop
0.0.0.0/32           receive
1.1.1.1/32           172.12.14.1          FastEthernet0/1
4.4.4.4/32           receive              Loopback4
127.0.0.0/8          drop
172.12.14.0/24       attached             FastEthernet0/1
172.12.14.0/32       receive              FastEthernet0/1
172.12.14.1/32       attached             FastEthernet0/1

No it isn’t, if CEF doesn’t see you as a route, you are not a route. However of course in the running configuration:

R4#sh run | i 5.5.5.5
ip route 5.5.5.5 255.255.255.255 172.12.45.5 track 5
 icmp-echo 5.5.5.5 source-ip 4.4.4.4
access-list 5 permit 5.5.5.5
R4#

To round off the reaction of tying the SLA to the IP route, and after it went down the route seemed to just disappear from the router other than the running config, IP SLA is still running even though it continues to fail:

R4#sh ip sla stat
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 00:45:19 UTC Mon May 22 2017
Latest operation return code: Timeout
Number of successes: 82
Number of failures: 148
Operation time to live: Forever

R4#

Now I did a “no shut” on Lo5 on R5, but the failures continue to increment on the “sh ip sla stat”, and the route is not being brought back into the route table.

I will have to re-visit this, as I’m not finding an answer on the internet very easily to this one, so I will need to research why this happens and revisit this so I can keep moving.

Configuring PBR with the Tracking Object

***One important note about Route-Maps and configuring tracking, if the same sequence has a line allowing the traffic, it will see the verify line and once it sees it cannot verify reachability it will go to the next set command which is “next-hop …” and route traffic there anyways so if you see any more commands within the same sequence that should be a huge red flag on exam day***

So I had to actually completely remove and reconfigure the tracking object, as it would not let go of that Track being “Down”, but once I did I tied it to my Policy Route like this:

R4(config)#access-list 5 permit 5.5.5.5
R4(config)#route-map PBR permit 10
R4(config-route-map)#match ip add 5
R4(config-route-map)#set ip next-hop ?
  A.B.C.D              IP address of next hop
  dynamic              application dynamically sets next hop
  encapsulate          Encapsulation profile for VPN nexthop
  peer-address         Use peer address (for BGP only)
  recursive            Recursive next-hop
  self                 Use self address (for BGP only)
  verify-availability  Verify if nexthop is reachable

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

R4(config-route-map)#set ip next-hop verify-availability 5.5.5.5 ?
  <1-65535>  Sequence to insert into next-hop list

R4(config-route-map)#set ip next-hop verify-availability 5.5.5.5 10 ?
  track  set the next hop depending on the state of a tracked object

R4(config-route-map)#set ip next-hop verify-availability 5.5.5.5 10 track ?
  <1-1000>  tracked object number

R4(config-route-map)#set ip next-hop verify-availability 5.5.5.5 10 track 5
R4(config-route-map)#route-map PBR permit 20
R4(config-route-map)#exit
R4(config)#

That is a really long command, I am hoping I don’t have to configure that off the top of my head on exam day!

So now I am going to see how THIS reacts to the tracking when the interface is shut down, hopefully it doesn’t just yank the route and not return it again, that was a bit frustrating to not resolve (yet):

R4#sh track
Track 5
  IP SLA 1 state
  State is Up, delayed Down (5 secs remaining)
    1 change, last change 00:11:09
  Delay up 5 secs, down 30 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    ROUTE-MAP 0
R4#sh track
May 22 01:40:43.256: %TRACKING-5-STATE: 5 ip sla 1 state Up->Down

After 30 seconds of being down, the tracking set it to down, so lets see if I “no shut” the interface if this will work any different than the static route:

R5(config-if)#no shut
R5(config-if)#
ASR#4
[Resuming connection 4 to r4 … ]

R4#sh ip route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [1/0] via 172.12.14.1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback4
      5.0.0.0/32 is subnetted, 1 subnets
S        5.5.5.5 [1/0] via 172.12.45.5
      172.12.0.0/16 is variably subnetted, 6 subnets, 2 masks
C        172.12.14.0/24 is directly connected, FastEthernet0/1
L        172.12.14.4/32 is directly connected, FastEthernet0/1
C        172.12.45.0/24 is directly connected, FastEthernet0/0
L        172.12.45.4/32 is directly connected, FastEthernet0/0
 –More–
May 22 01:42:28.256: %TRACKING-5-STATE: 5 ip sla 1 state Down->Up
C        172.12.55.0/24 is directly connected, Loopback55
L        172.12.55.4/32 is directly connected, Loopback55
R4#

So not only was I able to to verify that it didn’t remove the 5.5.5.5 route even when it was unreachable to the SLA operation, and also saw it come back up within what I believe was the 5 second delay time I set on track object as “Up” delay value.

So I’m getting tired of beating this topic to death, so I’ll end it here, but if this were to be applied to an interface and the SLA tracking went to a Down state the PBR would be disabled and normal routing would take over.

My brain is kind of melting at this point and I need to try to get one topic down, so I will update the static routing portion if I find a good answer, cause I actually see that a lot at my work and the fact its just not bringing routes back into the table is odd to me.

Policy Based Routing / Local Policy Routing, and Route-Map configuration and explanation, review for exam day!

OSPF_Base_Topology

I will be using this Topology not as an OSPF course, but to perform Policy Based Routing (PBR) to influence how traffic travels from R5 to destination network 172.12.23.0, but first we need to review the basics of PBR:

  • PBR effects packets on the Ingress interface it is configured on, not traffic generated by the router it is configured on, that is called “Local Policy Routing”
  • Packets can be routed by interface, or by “next-hop” via Route-Maps
  • Route-Maps must be used for PBR, so ACL’s must also be configured

Now if using an interface to “set” as an exit, it should be a non-multi access link (Point-to-Point), so the traffic isn’t being put on a Broadcast segment and reaching multiple hosts. If configuring an interface, you can define multiple interfaces in the Route-Map clause, in case the first one goes down it has a backup interface to take if specified.

If using the “set” for a next-hop ip add, you simply define the IP address to set as the next hop, and you can also have multiple next-hop’s in case one route goes down.

When it comes to doing a “match” for incoming data traffic, there are two options with PBR:

  • Match on “match ip add #” where # is an ACL # defining what traffic is going to be impacted by the Route-Map
  • By “match length …” where it actually matches not on Prefix Length, but on Packet length, which is a very special case use like QoS

Before going any further, to touch on this Length value being matched on, it will match on the packets length itself. This is generally used as said for QoS, as VOIP or Video packets are generally relatively small and pre-determined sizes, and the “Length” match is measured in Bytes specifically.

I just “wr er” all my routers thinking I was done with OSPF, blah, let me spin them up again quick to show these values, I’ll be leaving Area 34 completely out of this example:

R1(config-router)#do sh ip route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback1
      172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
C        172.12.15.0/24 is directly connected, FastEthernet0/1
L        172.12.15.1/32 is directly connected, FastEthernet0/1
O IA     172.12.23.0/24 [110/65] via 172.12.123.3, 00:00:48, Serial0/0/0
                        [110/65] via 172.12.123.2, 00:00:48, Serial0/0/0
C        172.12.123.0/24 is directly connected, Serial0/0/0
L        172.12.123.1/32 is directly connected, Serial0/0/0
R1(config-router)#

As can be seen, there is an equal Cost calculated by OSPF via R2 and R3 to the 172.12.23.0 /24 network, so lets run a few traceroutes from R5 to see which path is taken, if either is preferred:

R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 37 msec 32 msec 32 msec
  3 172.12.23.100 32 msec *  36 msec
R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 36 msec 33 msec 32 msec
  3 172.12.23.100 36 msec *  32 msec
R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  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.23.100 33 msec *  32 msec
R5#

As can be seen, R2 is the preferred route to the Switch at 172.12.23.100, so first we will configure it to prefer R3 as its next-hop to the Switch but we must first ask ourselves what the source address we want to matched on to incur this Policy.

For this I will use R5’s loopback 5.5.5.5, to confirm the inbound interface will differentiate the traffic coming from R5 as to where it sends it across the network.

So first we test 5.5.5.5 as a source for the traceroute, and get to work on R1’s config:

R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.3 36 msec 32 msec 32 msec
  3  *
    172.12.23.100 32 msec *
R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.3 36 msec 33 msec 32 msec
  3 172.12.23.100 32 msec *  32 msec

Now this is odd, I ran traceroute with source 5.5.5.5 a lot more times than on screen, but it seems to prefer the path to R3 rather than R2, however we are going to tell R1 to change its mind about that.

Before the configuration, though, I’d like to explain the steps I am about to take in order to accomplish the task of performing Policy Based Routing:

  • Configuring the ACL with the source traffic address (5.5.5.5) or if your doing it by length configuring your Packet Length… however that is done
  • Creating a Route-Map that matches on the ACL for source traffic defined
  • Apply the route map to the Ingress interface with the “ip policy route-map …” command

So lets get some dirt under R1’s fingernails:

R1#
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 5 permit 5.5.5.5
R1(config)#route-map PBR permit 10
R1(config-route-map)#match ip add 5
R1(config-route-map)#set ip next-hop 172.12.123.2

R1(config-route-map)#route-map PBR permit 20
R1(config-route-map)#int fa0/1
R1(config-if)#ip policy route-map PBR
R1(config-if)#

I didn’t think I’d get that all in one smooth config with no errors, but there is each step in order, notice I didn’t bother messing with the “permit any” on the ACL, because the Route-Map Sequence 20 is what takes precedence in this configuration, and I ended it with the catch-all clause of “Let all other traffic not matched on flow normally” at the end.

So lets see if our traffic is now hitting that Route-Map at its most basic configuration, and taking R2 as the next hop instead of R3:

R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 0 msec 4 msec
  2 172.12.123.2 32 msec 32 msec 32 msec
  3 172.12.23.100 33 msec *  33 msec
R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 36 msec 32 msec 32 msec
  3 172.12.23.100 32 msec *  32 msec

There it is, that simple!

Now I want to look at our options for matching certain criteria, if it has limits, and what those limits are (and I found the verbiage a bit odd as well) so lets check it out:

Packet Length Matches

R1(config)#route-map PBR permit 15
R1(config-route-map)#match length ?
<0-2147483647>  Minimum packet length

R1(config-route-map)#match length 100000 ?
<0-2147483647>  Maximum packet length

R1(config-route-map)#match length 100000 100000 ?
<cr>

So for Packet Length, you get one Primary and one Fallback option, and that’s it. It is not often Cisco puts its foot down on limiting backup criteria in commands, but it is obviously not a fan of matching a ton of Packet Length.

Also a very important note – It does not indicate it matches by the “byte” in the Route-Map ? output, so remember that for exam day, even though I’d really doubt it will come up on the ROUTE exam.

Interface Matches

R1(config-route-map)#match interface ?
(All interface types)

R1(config-route-map)#match interface serial 0/0/0 ?
(All interface types)

R1(config-route-map)#match interface serial 0/0/0 interface s0/0/1 ?
% Unrecognized command
R1(config-route-map)#match interface serial 0/0/0 interface ?
% Unrecognized command
R1(config-route-map)#match interface serial 0/0/0 serial 0/0/1 ?
(All interface types)

I left out the gigantic list of all interface types possible after the ?, but also left in the syntax errors I made, to demonstrate the syntax of this command. I kept going for a third interface but stopped there, so you can have up to 3+ redundant interfaces to “set” that traffic “match”ed by your PBR whereas Packet Length was limited to 2.

Next-Hop Matches

R1(config-route-map)#match ip next-hop 10.10.10.1 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#match ip next-hop 10.10.10.1 10.10.10.2 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#match ip next-hop 10.10.10.1 10.10.10.2 10.10.10.3 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#$xt-hop 10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#$xt-hop 10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4

And it continues on presumable forever, so you can set backup next-hops until you pass out from exhaustion typing right on the keyboard.

So these are the ways we “set” where our traffic goes, with one interesting command that can prepend each of them, called “default” which immediately makes me think “default route” – Lets take a look:

R1(config-route-map)#set ip ?
address     Specify IP address
default     Set default information
df          Set DF bit
global      global routing table
next-hop    Next hop address
precedence  Set precedence field
qos-group   Set QOS Group ID
tos         Set type of service field
vrf         VRF name

 

R1(config-route-map)#set default ?
interface  Default output interface

Not only are they set in slightly different ways, but they also have nothing to do with a default route, it actually refers to the default behavior of the packets transmission.

If you see “default” in the PBR route-map sequence “set” commands, that means that it is telling the Route-Map to first use the default method of routing the packet (Ask the IP Route Table where to send it) before falling back to the PBR set on the interface to tell the packet how to be routed.

Its a very special use modifier in PBR, because it defeats the purpose of Path Manipulation, but it does exist (and is configured in slightly different syntax forms) that we need to know about.

Now a couple of verification commands to verify Policy Based Routing:

  • show ip policy
  • show route (shows route-maps configured)
  • traceroute (to verify path taken)
  • debug ip policy

So I’ve demonstrated how to use the traceroute command to verify the PBR is working, however lets look at the other examples quick:

R1#sh ip policy
Interface      Route map
Fa0/1          PBR
R1#

This is saying the Fa0/1 has a PBR configuration using Route-Map PBR, so lets look at that:

R1#sh route PBR
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): 5
  Set clauses:
    ip next-hop 172.12.123.2
  Policy routing matches: 18 packets, 1080 bytes
route-map PBR, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
R1#

The red is my actual PBR configuration, while the blue is my catch-all clause on the Route-Map to allow all other traffic to route as normal.

As mentioned above, PBR only applies to Ingress traffic, however you can configure locally generated traffic on the router to do “Local Policy Routing”

Local policy routing is used for all practical purposes (at this point in my studies), for if you want to test your PBR assigned to an interface by creating a loopback on the local router, and using the “traceroute x.x.x.x source x.x.x.x” command to simulate traffic coming from that source.

It is configured with the following command in global configuration:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip local policy route-map PBR
R1(config)#int lo5
R1(config-if)#ip add 5.5.5
*May 19 23:26:26.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback5, changed state to up
R1(config-if)#ip add 5.5.5.5 255.255.255.255
R1(config-if)#^Z
R1#t
*May 19 23:26:49.287: %SYS-5-CONFIG_I: Configured from console by console
R1#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.123.2 32 msec 36 msec 32 msec
  2 172.12.23.100 32 msec *  28 msec
R1#

So that is PBR in all its glory, that is as far as I’ll go into it as I have a LOT more ground to cover, however it is simply a route-map configured to manipulate traffic, then applied to an Ingress interface receiving that traffic.

Next up, NTP, only this time with only 2 routers that are both running 15.x IOS code to get a true idea of the full list of features, as 12.x does not support NTPv4 – See you there!

Part 6: Troubleshooting of sub-optimal routing via route-maps / redist/ policy routing, and an old friend OSPF distance comes to save the day! (GREAT review!)

labbers_delight_rev3

Not /fin with this Topology of course, after this lab of fine tuning some sub-optimal routing I am taking copies of all “sh run” to be able to spin this lab up again if it ever gets the “wr er”, however it will be /fin for review and onto the subject of VPN’s.

So, Part 6, I am so ready to get this review over with – it’s almost taking as long as the initial learning!

As I recall our Local Policy Routing uncovered a case of sub-optimal routing, where OSPF paths are being preferred over much better link speeds, because it’s AD of 110 is lower than RIP’s 120. There are 2 different ways to address this:

  • Create a Policy Route on R2 setting R3 as the next hop for certain networks
  • Change the AD itself either via route-map or redistribution

So my initial thoughts is Policy Route on S0/0 directing traffic to a next-hop of 172.12.23.3 (Ethernet segment) would almost almost definitely introduce more sub-optimal routing to track down and fix, however I am not quite sure the best way to change that AD.

 

I haven’t seen it done before in a route map, so I’m going to try to tack it onto the Route-Map on R3 Redistributing those EIGRP routes into OSPF

 

So to get this configured, I need to check out the route-map for R3 to see where to insert my clause for changing the AD:

R3#show route
route-map EIGRP2RIP, deny, sequence 10
  Match clauses:
    tag 120
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map EIGRP2RIP, permit, sequence 20
  Match clauses:
  Set clauses:
    tag 200
  Policy routing matches: 0 packets, 0 bytes
route-map RIP2EIGRP, deny, sequence 10
  Match clauses:
    tag 200
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map RIP2EIGRP, permit, sequence 20
  Match clauses:
  Set clauses:
    tag 120
  Policy routing matches: 0 packets, 0 bytes
route-map EIGRP2OSPF, deny, sequence 5
  Match clauses:
    tag 110
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map EIGRP2OSPF, permit, sequence 10
  Match clauses:
  Set clauses:
    tag 200
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2EIGRP, deny, sequence 10
  Match clauses:
    tag 200
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2EIGRP, permit, sequence 20
  Match clauses:
  Set clauses:
    tag 110
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2RIP, deny, sequence 5
  Match clauses:
    tag 120
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2RIP, permit, sequence 10
  Match clauses:
  Set clauses:
    tag 110
  Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, deny, sequence 10
  Match clauses:
    tag 110
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 20
  Match clauses:
  Set clauses:
    tag 120
  Policy routing matches: 0 packets, 0 bytes
R3#

Oh yeah, it’s like that, once you get to route-mapping this output gets long and confusing fast! That is why show run is helpful as well, but probably not available come exam day. I located and highlighted in red our EIGRP2OSPF route-map, so I will put it smack dab in the middle, except I have no idea the output to look for but know that I am doing a “permit” on the sequence and “set”ing something:

RR3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#route-map EIGRP2OSPF permit 7
R3(config-route-map)#set ?
as-path           Prepend string for a BGP AS-path attribute
  automatic-tag     Automatically compute TAG value
  clns              OSI summary address
  comm-list         set BGP community list (for deletion)
  community         BGP community attribute
  dampening         Set BGP route flap dampening parameters
  default           Set default information
  extcommunity      BGP extended community attribute
  interface         Output interface
  ip                IP specific information
  ipv6              IPv6 specific information
  level             Where to import route
  local-preference  BGP local preference path attribute
  metric            Metric value for destination routing protocol
  metric-type       Type of metric for destination routing protocol
  mpls-label        Set MPLS label for prefix
  nlri              BGP NLRI type
  origin            BGP origin code
  tag               Tag value for destination routing protocol
  traffic-index     BGP traffic classification number for accounting
  vrf               Define VRF name
  weight            BGP weight for routing table

R3(config-route-map)#set ip ?
address     Specify IP address
  default     Set default information
  df          Set DF bit
  next-hop    Next hop address
  precedence  Set precedence field
  qos-group   Set QOS Group ID
  tos         Set type of service field

R3(config-route-map)#set metric ?
+/-<metric>     Add or subtract metric
  <0-4294967295>  Metric value or Bandwidth in Kbits per second
  <cr>

R3(config-route-map)#set metric

I color coded in red where my commands are on the CLI, and the output from the ? as there is so much output available for “set” options, however we do NOT have anything in there for Administrative Distance. I thought it might be under “set ip” or “set metric” however I was wrong, so very very wrong.

 

Trying using “distance …” command on R2 / Redistribution options

 

Looking back on my notes from 10 months ago (which is why it is good to make your own blog for studies), the administrative distance for OSPF routes can be changed locally right on the router, and the changes will only be locally significant which will be perfect for this scenario we are running into! First let us look at R2’s sub-optimal route table once more:

R2#sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:42:05, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:42:05, Serial0/0
     33.0.0.0/24 is subnetted, 1 subnets
O E2    33.33.33.0 [110/2] via 172.12.123.3, 00:42:05, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:42:05, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
O E2    4.4.4.4 [110/20] via 172.12.123.3, 00:04:54, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E2    172.12.34.0 [110/20] via 172.12.123.3, 00:04:56, Serial0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:42:08, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:42:08, Serial0/0
R2#

I just got even MORE EXCITED because I completely forgot, I left RIP and EIGRP AS 200 Redistribution as default E2 external routes, while EIGRP AS 100 is E1 – So if I can change it by External route type that would route traffic exactly right! Lets check it out:

R2(config-router)#distance ?
  <1-255>  Administrative distance
  ospf     OSPF distance

Ah yes, I remember this now, we will either have to make all external routes with an AD of 121, or make an access-list that allows certain routes to get an AD of 121, referenced here:

https://loopedback.com/2016/06/15/ospf-to-rid-4-ways-to-change-ad-sub-optimal-routing-route-loops/

Being that I am currently lazy and a bit fried from work / VPN theory, I’m going to try to just use the “distance ospf # …” command in OSPF configuration to change the local external AD, I will need to review and re-lab that mentioned page at some point but not as another part of this lab session:

R2(config-router)#distance ospf external 121
R2(config-router)#do sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:00:26, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
R       100.0.0.0 [120/2] via 172.12.23.3, 00:00:26, FastEthernet0/0
     33.0.0.0/24 is subnetted, 1 subnets
R       33.33.33.0 [120/1] via 172.12.23.3, 00:00:26, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:00:26, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
R       4.4.4.4 [120/2] via 172.12.23.3, 00:00:00, FastEthernet0/0
     172.12.0.0/24 is subnetted, 4 subnets
R       172.12.34.0 [120/1] via 172.12.23.3, 00:00:08, FastEthernet0/0
R       172.12.15.0 [120/2] via 172.12.23.3, 00:00:08, FastEthernet0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
R       11.11.11.0 [120/2] via 172.12.23.3, 00:00:08, FastEthernet0/0
R2(config-router)#

Well, I guess I will be reviewing that old page sooner than I thought, eh? So I removed the distance command, and will read through the link posted above quick to see what needs to be done here.

So after a quick skim, we are going to need an access-list to reference in OSPF, this uses the “distance # (ip address) …” command in OSPF config, and I know we need the RID this route is learned off of but being the other spoke I don’t know if it needs to be the hub or R3 / other spoke’s RID, so my first though is to check our neighbor table to see if we even have the ASBR locked and loaded as a neighbor:

R2(config)#do sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
11.11.11.1        1   FULL/DR         00:01:58    172.12.123.1    Serial0/0
R2(config)#

Nope, on a Hub and Spoke OSPF network, your only ally (neighbor) is the Hub, so we will need to use it’s RID right there in the neighbor table to configure this as follows:

R2(config)#access-list 11 permit host 4.4.4.4
R2(config)#access-list 11 permit 172.12.34.0 0.0.0.255
R2(config)#router ospf 1
R2(config-router)#distance 121 ?
  A.B.C.D  IP Source address
  <cr>

R2(config-router)#distance 121 11.11.11.1 ?
  A.B.C.D  Wildcard bits

R2(config-router)#distance 121 11.11.11.1 0.0.0.255 ?
  <1-99>       IP Standard access list number
  <1300-1999>  IP Standard expanded access list number
  WORD         Standard access-list name
  <cr>

R2(config-router)#distance 121 11.11.11.1 0.0.0.255 11 ?
  <cr>

R2(config-router)#distance 121 11.11.11.1 0.0.0.255 11
R2(config-router)#

I have no idea if this is going to work, but excellent review I hadn’t even though of. DRUM ROLL PLEASE, as here we see the new and optimally routing table for R2:

(Failure, same routes). I won’t even bother with the output. It took doing a “clear ip ospf proc” and a “clear ip route *” to finally get these results:

R2#sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
R       1.1.1.1 [120/2] via 172.12.23.3, 00:00:25, FastEthernet0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
R       100.0.0.0 [120/2] via 172.12.23.3, 00:00:25, FastEthernet0/0
     33.0.0.0/24 is subnetted, 1 subnets
R       33.33.33.0 [120/1] via 172.12.23.3, 00:00:26, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
R       3.3.3.3 [120/2] via 172.12.23.3, 00:00:27, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
R       4.4.4.4 [120/2] via 172.12.23.3, 00:00:27, FastEthernet0/0
     172.12.0.0/24 is subnetted, 4 subnets
R       172.12.34.0 [110/20] via 172.12.123.3, 00:00:02, Serial0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:00:02, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:00:02, Serial0/0
R2#

So I have managed to turn all OSPF into RIP routes again, and I am not sure how I did that with this command only specifying those 2 routes learned from 11.11.11.1 to have an AD of 121. Time to review exactly what I did here.

I can’t see any glaring mistakes, so I am wondering if maybe due to how the ACL is being called out, if that implicit deny is not kicking in quite right, so I put an explicit deny on there:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#access-list 11 deny any
R2(config)#do show access-list 11
Standard IP access list 11
    10 permit 4.4.4.4
    20 permit 172.12.34.0, wildcard bits 0.0.0.255
    30 deny   any
R2(config)#

Now lets clear ip ospf proc again and see what we get:

R2#sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:00:32, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:00:32, Serial0/0
     33.0.0.0/24 is subnetted, 1 subnets
O E2    33.33.33.0 [110/2] via 172.12.123.3, 00:00:32, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:00:32, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
O E2    4.4.4.4 [110/20] via 172.12.123.3, 00:00:33, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E2    172.12.34.0 [110/20] via 172.12.123.3, 00:00:36, Serial0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:00:36, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:00:36, Serial0/0
R2#

I just cannot win with this method… WAIT A MINUTE! THAT WILDCARD MASK SHOULD BE 0.0.0.0 NOT THE NETWORK MASK OF 0.0.0.255! LETS TRY THIS AGAIN:

R2#sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
R       1.1.1.1 [120/2] via 172.12.23.3, 00:00:09, FastEthernet0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
R       100.0.0.0 [120/2] via 172.12.23.3, 00:00:09, FastEthernet0/0
     33.0.0.0/24 is subnetted, 1 subnets
R       33.33.33.0 [120/1] via 172.12.23.3, 00:00:09, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
R       3.3.3.3 [120/2] via 172.12.23.3, 00:00:10, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
R       4.4.4.4 [120/2] via 172.12.23.3, 00:00:10, FastEthernet0/0
     172.12.0.0/24 is subnetted, 4 subnets
R       172.12.34.0 [110/20] via 172.12.123.3, 00:00:00, Serial0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:00:00, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:00:00, Serial0/0
R2#

The oddity is, only the E1 routes are remaining OSPF, there might be something to that but for now I am going to remove the distance command from R2 and see if there are any options in the redistribute command on R3.

So I wasn’t able to touch AD in Redistribution, but I was able to change the metric-type (as I’d had been able to in the route-map for EIGRP2OSPF as well, so lets see if applying that same command to R2 that allowed O E1 routes to stay holds steady.

Aaaaand, it did not. I have a feeling that not having a neighbor relationship to that ASBR is making things difficult, so I am resetting the works and putting a policy route on S0/0 as I said I would not be viable in the beginning of the lab as we are running out of options 🙂

 

Using Policy Routing to accomplish my task, and end this never ending lab

 

I’m going brain dead for the night, and while I could review past material for days on end, I need to wrap up the review (for now) and finish this lab tonight – So I will use Policy Routing on R2 to accomplish overcoming the sub-optimal routing we set out to destroy:

R2(config)#ip access-list extended GOTOYOURHOME
R2(config-ext-nacl)#10 permit ip host 11.11.11.1 host 4.4.4.4
R2(config-ext-nacl)#exit
R2(config)#route-map GOHOMEBALL permit 10
R2(config-route-map)#match ip add GOTOYOURHOME
R2(config-route-map)#set ip next-hop 172.12.23.4
R2(config-route-map)#exit
R2(config)#int s0/0
R2(config-if)#ip policy route GOHOMEBALL ?
  <cr>

R2(config-if)#ip policy route GOHOMEBALL

(I hope you enjoyed the Happy Gilmore references) Aaaaand:

R1#traceroute 4.4.4.4 source 11.11.11.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.2 36 msec 32 msec 33 msec
  2  *  *  *
  3  *  *  *
  4  *  *  *
  5  *  *  *
  6  *  *  *
  7  *
ASR#2
[Resuming connection 2 to r2 … ]

R2(config-route-map)#^Z
R2#de
*Mar  1 17:24:20.014: %SYS-5-CONFIG_I: Configured from console by console
R2#debug ip pack
IP packet debugging is on
R2#
*Mar  1 17:24:25.624: IP: tableid=0, s=11.11.11.1 (Serial0/0), d=4.4.4.4 (Serial0/0), routed via FIB
*Mar  1 17:24:25.624: IP: s=11.11.11.1 (Serial0/0), d=4.4.4.4 (FastEthernet0/0), g=172.12.23.4, len 28, forward
*Mar  1 17:24:25.624: IP: s=11.11.11.1 (Serial0/0), d=4.4.4.4 (FastEthernet0/0), len 28, encapsulation failed
R2#

SO THIS HAS ONCE AGAIN FAILED, BUT I FINALLY GOT IT, USING THE DISTANCE COMMAND ON R2, AND THIS WRAPS THIS LAB ON UP!

After looking at the extended ip route command for the network, I noticed in its configuration for the route it was learned via 33.33.33.3, not via our only neighbor 11.11.11.1, so I repeated the same syntax only with 33.33.33.3 as the remote RID:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#access-list 11 permit host 4.4.4.4
R2(config)#access-list 11 permit 172.12.34.0 0.0.0.255
R2(config)#router ospf 1
R2(config-router)#distance 121 33.33.33.3 0.0.0.0 ?
  <1-99>       IP Standard access list number
  <1300-1999>  IP Standard expanded access list number
  WORD         Standard access-list name
  <cr>

R2(config-router)#distance 121 33.33.33.3 0.0.0.0 11
R2#clear ip ospf proc
Reset ALL OSPF processes? [no]: yes
R2#
*Mar  1 17:40:54.304: %OSPF-5-ADJCHG: Process 1, Nbr 11.11.11.1 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
R2#
*Mar  1 17:41:10.094: %OSPF-5-ADJCHG: Process 1, Nbr 11.11.11.1 on Serial0/0 from LOADING to FULL, Loading Done

AAAAAAAAAND:

R2(config)#do sh ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:02:16, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:02:16, Serial0/0
     33.0.0.0/24 is subnetted, 1 subnets
O E2    33.33.33.0 [110/2] via 172.12.123.3, 00:02:16, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:02:16, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
R       4.4.4.4 [120/2] via 172.12.23.3, 00:00:08, FastEthernet0/0
     172.12.0.0/24 is subnetted, 4 subnets
R       172.12.34.0 [120/1] via 172.12.23.3, 00:00:10, FastEthernet0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:02:19, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:02:19, Serial0/0
R2(config)#

I honestly I did not think I would be able to get this, but there it is, made possible by the distance command in OSPF config in R2. I am saving all routers and running for the door before I find another issue with the config – See you next time for some VPN configuration and theory!

EDIT:

To note for future reference, this is what led me to my answer:

R2#show ip route 4.4.4.4 255.255.255.255
Routing entry for 4.4.4.4/32
  Known via “ospf 1”, distance 110, metric 20
  Tag 200, type extern 2, forward metric 64
  Last update from 172.12.123.3 on Serial0/0, 00:00:22 ago
  Routing Descriptor Blocks:
  * 172.12.123.3, from 33.33.33.3, 00:00:22 ago, via Serial0/0
      Route metric is 20, traffic share count is 1
      Route tag 200

That was a great save, just goes to show, any problem can be worked through if you work at it hard enough. I will also note it tickles me that a configuration I didn’t even think of or mention about as a solution was what ended up saving the day 🙂 Pretty awesome!

Part 5: Turning “IP Routing” on for Layer 3 SW1, Policy / Local Policy Routing, found sub-optimal routing due to AD! (Will be 6th lab to troubleshoot)

labbers_delight_rev3

I took a quick moment to post before this, advising not to study or lab tired, cause as can be seen towards the end of my Part 4 of this lab I am just tired and swinging at air.

Anyway, we now have R1 and R3 both acting as ASBR’s, with R1 doing 2-way route-tagged Distribution and R3 doing 3-way tagged Route Redistribution. We even still have authentication running on all routing domains, life does not get much better than this!

Honestly the fact that I have all protocol Authentication configurations documented, and how that all fits together, in addition to a solid understand of Distribute-List configuration I am very happy. The fact that I was able to get Multi-Point 2-way and 3-way routing to play nice (with some troubleshooting) is awesome, so Policy Routing is going to be my wrap up here to this lab because I have wanted to make the Summary Route do sub-optimal for half the routes since this began! 🙂

 

Quickly turning on L3 functionality for SW1 and testing connectivity

 

I probably didn’t need the new topic blue header for this, but I never know what I’m in for starting out with something new to the lab, so I put SW1 on the RIP network and want to see if it’s pingable with just a management IP for Vlan1.

So the quick config on SW1:

SW1(config)#ip routing
SW1(config)#router rip
SW1(config-router)#no auto
SW1(config-router)#network 172.12.23.0

And then a quick test from R5 to see if it can see it all the way down there:

R5#ping 172.12.23.1

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

Woohoo! Sweet Sweet connectivity, now to path selection / manipulation with PBR.

 

Policy Routing Configuration / Local Policy Routing configuration

 

Again once you know route-map configuration, PBR is a walk in the park to setup and apply, which is what I say right before I run into 1000 unforseen problems. So I would like half the traffic from our Summary Route to take a different path over the NBMA, as it won’t do equal cost load balancing by default the way EIGRP will, so I’ll set it myself:

R1(config)#$ 105 permit ip 100.1.0.0 0.0.255.255 172.12.23.0 0.0.0.255
R1(config)#$ 105 permit ip 100.2.0.0 0.0.255.255 172.12.23.0 0.0.0.255
R1(config)#$ 105 permit ip 100.3.0.0 0.0.255.255 172.12.23.0 0.0.0.255
R1(config)#$ 105 permit ip 100.4.0.0 0.0.255.255 172.12.23.0 0.0.0.255
R1(config)#route-map SummaryTrafficHop permit 10
R1(config-route-map)#match ip add 105
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 SummaryTrafficHop
R1(config-if)#

So it is now set up on R1 to filter said networks in the summary route, let’s test the preferred route in general from R5, then the networks involved in the Policy Route:

R5#traceroute 172.12.23.1

Type escape sequence to abort.
Tracing the route to 172.12.23.1

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.3 32 msec 36 msec 32 msec
  3 172.12.23.1 32 msec *  32 msec
 
R5#traceroute 172.12.23.1 source 100.4.0.1

Type escape sequence to abort.
Tracing the route to 172.12.23.1

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 32 msec 32 msec 36 msec
  3  *
    172.12.23.1 32 msec *
R5#traceroute 172.12.23.1 source 100.5.0.1

Type escape sequence to abort.
Tracing the route to 172.12.23.1

  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.23.1 32 msec *  32 msec
R5#

This really surprised me at first, as when there was a Router connected to R2 and R3 via FastEthernet, we would see those traceroute returns up to R1 and back to the other spoke even using OSPF across the board. With a switch on the Ethernet segment however, it is that “One and Done” I was talking about wasn’t possible to truly configure PBR along a network path. I personally think Chris Bryant did a really horse sh*t job of teaching that section, and as much as I love his training, I would say that right to his face 🙂

So for future reference, if this type of Topology pops up with Policy Routing in question, you will need to configure Policy Routes on the next-hop Router to then direct traffic onto the Ethernet to its destination rather than back over the NBMA.

THAT BEING SAID, I THINK WE NEED TO INTRODUCE A LITTLE ANARCHY TO THE NETWORK, AND DOING SO WITH A POLICY ROUTE:

R1(config)#access-list 111 permit ip 11.11.11.0 0.0.0.255 host 4.4.4.4
R1(config)#route-map LocalNextHop permit 10
R1(config-route-map)#match ip add 111
R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#

Now I know I don’t even NEED to tell you at this point, but that is a sub-optimal path even if it zip across the FastEthernet instead of across the Serial Link and Back to R3 to reach R4’s loopback address of 4.4.4.4, but lettuce see what happens when we traceroute it:

R1(config)#access-list 111 permit ip 11.11.11.0 0.0.0.255 host 4.4.4.4
R1(config)#route-map LocalNextHop permit 10
R1(config-route-map)#match ip add 111
R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#do traceroute 4.4.4.4 source 11.11.11.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.3 76 msec 32 msec 32 msec
  2 172.12.34.4 33 msec *  32 msec
R1(config-route-map)#

… The result of this traceroute displeases me. However, after staring at that configuration for a moment, I realize I completely spaced putting in the actual local policy statement.

This is why I made a post about studying tired, and why I am wrapping this up !

R1(config)#ip local policy route LocalNextHop
R1(config)#do traceroute 4.4.4.4 source 11.11.11.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.2 32 msec 32 msec 32 msec
  2 172.12.123.1 24 msec 24 msec 24 msec
  3 172.12.123.3 56 msec 52 msec 57 msec
  4 172.12.34.4 56 msec *  52 msec
R1(config)#

I am a bit surprised by this, I would have thought it would take the ethernet segment over to R3, I must advice R3’s route table quick to understand this madness of sending back over the Serial Link rather than through the Ethernet:

R2#show ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 02:03:41, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 02:03:41, Serial0/0
     33.0.0.0/24 is subnetted, 1 subnets
O E2    33.33.33.0 [110/2] via 172.12.123.3, 02:03:41, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 02:03:41, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
O E2    4.4.4.4 [110/20] via 172.12.123.3, 02:03:42, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E2    172.12.34.0 [110/20] via 172.12.123.3, 02:03:44, Serial0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 02:03:44, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 02:03:44, Serial0/0
R2#

I smell a 6th lab needed for sub-optimal routing, and changing AD’s! This should have taken the path through the RIP domain to get to R4 (along with other traffic), however it’s the tie breaker (it’s AD) beat RIP 110 vs 120 so the OSPF route is in the route table as an E2 route.

This is a good note to end it on for me, next lab I will be troubleshooting some sub-optimal routing I find around the network with PBR and AD changes, then it is time to learn about and configure some VPN’s on our Authenticated and Redistributed monster of a network 🙂

Part 1: Setting up the new, bigger, and better lab to configure everything we’ve learned up to this point!

 

labbers_delight

As previously mentioned I believe, this will be a multi-part lab in which I will configure “Multi-Point” 2-way Redistribution / Policy-Routing / Distribute-Lists / Route-Maps / and troubleshooting all along the way.

Here are a few things I know I want to achieve over the several parts of this lab:

  • Authentication deep dive for all 3 protocols in Topology
  • DEEP Dive look at Redistribution with Route-Map tagging and Distribute-Lists
  • Policy Routing and Local Policy Routing configuration
  • 3-way Redistribution on R3 if possible, things might get crazy
  • Deep Dive into Policy Routing capabilities, applying around the network
  • Random other topics as I can think of them

I will be working as much with route-maps as possible, as they really are a huge chunk of all of those topics, so I believe those are critical to understand inside out. I have done a “wr er” and “reload” on all routers, and am going to configure the core network in the Topology, but I may review some of my previous posts to get my brain tuned up to lab until my brain melts out of my skull.

That being said I will just configure it for tonight, and add to it slowly while I am fresh, I don’t want to do anything while I am in zombie mode (like now) after a long work day.

So this will all be review, and as I said, saturate this network completely with all the concepts I have posted about and troubleshoot issues as needed.

I am going to whip up this Topology now, and we will get this party started on my next post, see you there 🙂

The extended traceroute command, and Local Policy Routing Configuration!

policy_routing_top

Still working with the same Topology seen above, I want to round off the Policy Routing videos to see if I can bring that into some scenario or freestyle lab, and see how crazy one can get with Policy Routing.

The first thing to note that I have amazingly not known at all until this video, from a router there are two ways to do extended traceroutes (like extended pings):

  • Type “traceroute” and hit enter to fill in options exactly like an extended ping
  • “traceroute (dest IP) source (source IP)” to simulate traffic from that network

Also to note on the second method, you can actually source several different ways, shown with the extended options as I fill them out, so there shall be a bit of output:

R1#traceroute 4.4.4.4 ?
numeric  display numeric address
port     specify port number
probe    specify number of probes per hop
source   specify source address or name
timeout  specify time out
ttl      specify minimum and maximum ttl
<cr>

R1#traceroute 4.4.4.4 source ?
A.B.C.D            Source address
Async              Async interface
BVI                Bridge-Group Virtual Interface
CDMA-Ix            CDMA Ix interface
CTunnel            CTunnel interface
Dialer             Dialer interface
FastEthernet       FastEthernet IEEE 802.3
Lex                Lex interface
Loopback           Loopback interface
MFR                Multilink Frame Relay bundle interface
Multilink          Multilink-group interface
Null               Null interface
Port-channel       Ethernet Channel of interfaces
Serial             Serial
Tunnel             Tunnel interface
Vif                PGM Multicast Host interface
Virtual-PPP        Virtual PPP interface
Virtual-Template   Virtual Template interface
Virtual-TokenRing  Virtual TokenRing

R1#traceroute 4.4.4.4 source 10.20.30.40 ?
numeric  display numeric address
port     specify port number
probe    specify number of probes per hop
timeout  specify time out
ttl      specify minimum and maximum ttl
<cr>

R1#traceroute 4.4.4.4 source 10.20.30.40

% Invalid source address- IP address not on any of our up interfaces


R1#

It’s like a build your own sundae, you can just keep adding scoops of detail to your traceroute, but as can be seen highlighted in red text we have an important message. The source IP address must be on one of our “Up” interfaces on the local router, so beine this requires a Physical or Logical interface that is in “Up” status, it sounds like Loopback interfaces is the way to go as they won’t go down unless administratively.

However if we are using an extended traceroute, it is because we are simulating traffic from another network for testing the path, but as we well know Policy Routing requires an interface of the incoming traffic to Policy Route and this is where Local Policy Routing comes into play.

To makes things harder on my already exhausted brain, I assigned loopback names to match the IP addresses:

R1(config)#int lo ?
  <0-2147483647>  Loopback interface number (<- What!!!)

R1(config)#int lo1234
*Mar  1 17:00:40.658: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1234, changed state to up
R1(config-if)#ip add 10.20.30.40 255.255.255.0
R1(config-if)#int lo4321
*Mar  1 17:01:03.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback4321, changed state to up
R1(config-if)#ip add 40.30.20.10 255.255.255.0
R1(config-if)#

Another interesting thing, you can make an interface loopback 2,147,483,647 (2.1 billion), I have been setting my bar way too low for loopback interface numbers. Back to the matter at hand, I now have my two loopbacks just created as well as lo1 with IP address 1.1.1.1 /32 to use in the lab.

So the structure of of how you create the route-map is the same of making an ACL / matching it on a route-map / set ip next-hop (ip addy), however there is no incoming interface on the local router so we will examine where we apply this route-map if not to an incoming interface.

To start I will send an initial traceroute to see my current path so I know how to alter it:

R1(config)#do traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 172.12.123.3 32 msec 32 msec 36 msec
2 172.12.34.4 32 msec *  32 msec
R1(config)#do traceroute 4.4.4.4 source 40.30.20.10

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1  *  *  *
2  *  *  *
3  *  *  *
4  *  *  *
5  *

This is a good learning lesson, because I just made these loopbacks, but forgot to add them to OSPF so no other routers would know a route back, so I’ll add them to OSPF and we’ll try again:

R1(config)#router ospf 1
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
R1(config-router)#network 10.20.30.40 0.0.0.255 area 0
R1(config-router)#network 40.30.20.10 0.0.0.255 area 0
R1(config-router)#do traceroute 4.4.4.4 source 40.30.20.10

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.3 36 msec 33 msec 32 msec
  2 172.12.34.4 32 msec *  32 msec
R1(config-router)#

Much better. So being that 172.12.123.3 is the preferred path to R4’s loopback of 4.4.4.4, I want our 2 new loopback interfaces to route traffic towards R2 instead, so I will create a multi-line ACL this time for Policy Routing and create the Route-map:

R1(config)#access-list 105 permit ip host 10.20.30.40 host 4.4.4.4
R1(config)#access-list 105 permit ip host 40.30.20.10 host 4.4.4.4
R1(config)#route-map LocalNextHop permit 10
R1(config-route-map)#match ip add 105
R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#

I am still not sure if you can have multiple route-maps on an interface, I will lab the scenario because I think it makes sense that one interface can have multiple networks coming into it that it needs to route different places, however for now I can confirm that 1 route-map can contain multi-line ACL’s to direct more than one line of traffic towards a next hop destination.

So no incoming interface, where do we configure the route-map? The answer is – Globally:

R1(config)#ip local ?
  policy  Enable policy routing
  pool    IP Local address pool lists

R1(config)#ip local policy ?
  route-map  Policy route map

R1(config)#ip local policy route-map ?
  WORD  Route map name

R1(config)#ip local policy route-map LocalNextHop ?
  <cr>

R1(config)#ip local policy route-map LocalNextHop
R1(config)#

And to test it out, we will use our new friend extended traceroute:

R1#traceroute 4.4.4.4 source 40.30.20.10

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.2 32 msec 32 msec 32 msec
  2 172.12.123.1 25 msec 24 msec 24 msec
  3 172.12.123.3 56 msec 56 msec 56 msec
  4 172.12.34.4 56 msec *  52 msec
R1#traceroute 4.4.4.4 source 1.1.1.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.3 33 msec 32 msec 32 msec
  2 172.12.34.4 32 msec *  32 msec
R1#

I’ve highlighted first one of the IP addresses called out in the ACL, then our lo1, to show that we have not only sub-optimal routing (described in last post how to fix), but that it does in fact attempt to take R2 because of the Local Policy Routing happening whereas 1.1.1.1 goes right to R3.

As mentioned how to overcome that sub-optimal routing you see in the first trace is picked apart in detail in my last post, so please read up on how PBR is not one and done on a single router as taught in the video courses I am watching.

Just a couple more points on Local Policy Routing to wrap this up:

  • Local Policy Routing will not effect any other Policy Routing assigned to interfaces
  • Local Policy Route-maps must be named differently than any existing route-maps currently configured on the router

So basically for local policy routing, you just need to remember the global command to apply it, and off to the races you go. I will be doing one more freestyle lab with PBR to see its limitations, as you learn things like in my training materials it did not mention that error we saw saying it needs to be an “Up” interface on the router.

So I invite you or future me to check out the next post of just messing around with PBR in general to see what we can break and fix, and then it is onward to VPNs. Thee ya!

Using Extended ACL’s for Policy Routing to overcome sub-optimal routing

policy_routing_top

As seen in the previous look at policy routing using a standard ACL, it led to sub-optimal routing due to only routing on the source, and not both source and destination addresses – for this we will use an Extended ACL to correct. So I took the old commands off, nothing fancy:

R1(config)#no access-list 5
R1(config)#no route-map R5toR2
R1(config)#int fa0/1
R1(config-if)#no ip policy route-map R5toR2
R1(config-if)#exit
R1(config)#

As can be seen, just really go through each step of setting it up, add a no to the front using ctrl + a to jump to the front of command, and now it’s good to go to setup an Extended ACL. So now we add the new configs to R1, and see what a traceroute shows:

R1(config)#access-list 105 permit ip host 172.12.15.5 host 4.4.4.4
R1(config)#route-map NextHop permit 10
R1(config-route-map)#match ip add 105
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 NextHop
R1(config-if)#
ASR#5
[Resuming connection 5 to r5 … ]

R5#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

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

I am disappointed with this result because it verifies that Chris Bryant did a poor job on his teaching of this section, their obviously needs to be some extra configuration along the route path which wasn’t mentioned at all in the training videos, and even his logical topology did not match his physical setup.

So now that I’ve got my moaning and groaning about that out of my system, we’ll need to review R2 and how to make it not throw that traffic back out S0/0 as it has in it’s route-table to do so and no policy routing is setup over there.

So I noticed one thing right away that needs to be addressed:

R2#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.1 32 msec 32 msec 32 msec
  2 172.12.123.3 64 msec 64 msec 64 msec
  3 172.12.34.4 64 msec *  60 msec
R2#

So what we see here is that even though 4.4.4.4 is on R4 off FastEthernet0/1, it is sending traffic back over both serial interfaces to get there. Now there is a couple of options here which I will demonstrate, the first being a quick static route to save the day:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#ip route 4.4.4.4 255.255.255.255 fa0/1
R2(config)#exit
R2#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1  *
    172.12.24.4 0 msec *
R2#
ASR#5
[Resuming connection 5 to r5 … ]

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.24.4 32 msec *  32 msec
R5#

Just to illustrate from both points of view, problem solved, but given that network 4.4.4.4 is shared in the OSPF domain, I don’t want a static route overriding it so I will remove it and see what kind of route-map will allow this traffic to pass but all other traffic to route normally:

R2(config)#no ip route 4.4.4.4 255.255.255.255 fa0/1
R2(config)#access-list 105 permit ip host 172.12.15.5 host 4.4.4.4
R2(config)#route-map NextHop permit 10
R2(config-route-map)#match ip add 105
R2(config-route-map)#set ip next-hop 172.12.24.4
R2(config-route-map)#route-map NextHop permit 20
R2(config-route-map)#int s0/0
R2(config-if)#ip policy route-map NextHop
R2(config-if)#

Now theoretically, I should be able to get to 4.4.4.4 through R2 from R5, but from R2 it should again need to take the long way around, lets see what happens between the two:

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.24.4 32 msec *
R5#
ASR#2
[Resuming connection 2 to r2 … ]

R2#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.1 36 msec 32 msec 32 msec
  2 172.12.123.3 60 msec 60 msec 64 msec
  3 172.12.34.4 64 msec *  61 msec
R2#

And there it is, I am so glad that worked, because it’s getting late and that is when things tend not to work and drive me bonkers 🙂

So as can be seen, you will need to follow the path of the traffic and apply route-maps to router interfaces to keep the traffic moving as you configure it, otherwise you will not achieve optimal ‘route manipulation’ you are trying to achieve.

I am going to remove all PBR configs from routers, and decide whether I want to delve further into Policy Routing with a free-style sort of lab, or move on to Local Policy Routing.