1.2 Routing Concepts

This whole chunk of the blueprint doesn’t really make sense because it’s mostly topics that will be covered under individual routing protocols. The only subsections I’m going to cover under 1.2 are 1.2b. VRF-Lite (covered in a separate post), Policy Based Routing (PBR, which I’ll cover below), and Bidirectional Forwarding Detection (BFD, which I’ll cover in the next post). Everything else will be covered as part of EIGRP, OSPF, and BGP.

1.2.c Static Routing

OK, I lied. One quick word about Static Routing. The legend has always been (at least according to CBT Nuggets) that the rules of the lab explicitly say that static routing isn’t allowed. But I think Floating Static Routes are worth mentioning here. Also, there’s an entire chapter (Chapter 3) of Routing TCP/IP, Volume 1, 2/e (Carroll, Doyle) dedicated to static routing that’s a pretty good read.

Configuring a floating static route is pretty simple, you just set the administrative distance (AD) at the end of the line to something higher than your routing protocol AD.

R1
conf t
ip route 192.1.1.0 0.0.0.255 192.0.0.6 111

R1: OSPF route.

Then we shut down the link to 192.0.0.2

R1: Gig 0/1 shutdown.
R1: Floating static route success.
1.2.d Policy Based Routing

PBR with route-maps is basically the If/Then statements of routing. The topology is pretty similar to the one from the previous post about VRF-lite, with some minor changes.

PBR Topology

The idea is that R1 is currently taking the shortest path to the Finance_Server and the HR_Server, through R2. OSPF is running on all of the routers and on SW1. SW2 is just L2. The task that we want to accomplish with PBR is to have the HR traffic go across R3 and R4 to the HR_Server. All other traffic will go through R2, which includes Finance user traffic to Finance_Server or HR_Server, as well as HR user traffic to the Finance_Server. For the purposes of this lab, we’re not doing any type of segmentation. Anybody can talk to anybody.

For reference material, I’m still using Routing TCP/IP, Volume 1, 2/e, specifically Chapter 14: Route Maps. Here’s a great quote from that chapter, “Policy routes are nothing more than sophisticated static routes.”

Match IP Address

The interesting thing with PBR route maps, when you type match ? you get about 20 options. But the only ones used for PBR are match ip address [ACL] and match length <0-2147483647>. We’ll probably match on IPs 99% of the time, so we’ll look at that first.

The config is pretty straightforward, it’s just three steps:
1. Define the ACLs.
2. Create the route-map.
3. Apply the route-map to the interfaces.

R1
conf t
! This first one could have just been a standard ACL.
access-list 110 permit ip 192.168.10.0 0.0.0.255 any
!This second one is only for the HR subnet talking to the HR server.
access-list 120 permit ip 192.168.20.0 0.0.0.255 host 192.2.2.20

!Create the route-map.
route-map RM_PBR permit 10
match ip address 110
set ip next-hop 192.0.0.2
route-map RM_PBR permit 20
match ip address 120
set ip next-hop 192.0.0.6

!Apply it to the interface(s).
interface gig 0/0.10
ip policy route-map RM_PBR
interface gig 0/0.20
ip policy route-map RM_PBR

That’s it. Pretty simple config. Let’s verify with a traceroute from the HR PC.

PC2 traceroute.
R1: debup ip packets 120.
Match Length

Another interesting thing mentioned in the Routing TCP/IP book is segregating small packets (telnet) from big packets (ftp) using the match length option. I feel like it’s an obscure enough knob to turn that it could definitely show up on the lab.

R1:
conf t
route-map RM_length
!Match a minimum of 1000 octets and maximum of 1600 octets.
match length 1000 1600
set ip next-hop 192.0.0.6

Local Policy

So far this has all been policy applied to an ingress interface. What about local traffic originating from the router? We can apply a route-map using a global config command, ip local policy route-map RM_length. One thing to avoid would be accidentally applying policy to control plane traffic, routing updates for instance, which prevent the hellos from going out the correct interfaces. We can avoid this with a match statement that matches on the local IP of the router, but no set statement, which means “just route normally.” For instance:

R1
conf t
!ACL that defines the local ip addresses.
access-list 1 permit host 192.0.0.1
access-list 1 permit host 192.0.0.5
access-list 1 permit host 192.0.0.9
access-list 1 permit host 192.0.0.13

!Define the route map and tell it to ignore anything originating from those 4 local IPs, just route them normally.
route-map RM_length 10
match ip address 1
route-map RM_length 20
match length 0 400
set ip next-hop 192.0.0.6

!Then apply the route map with the local policy.
ip local policy route-map RM_length

PBR QoS

We’re going to hit up QoS in section 4 of the CCIE blueprint.

Published by Gregory Leeson

(CCIE Security, #60398). A Cisco networking nut.

Leave a comment