My journey to CCIE RS — IP Routing 2

My two bibles signed by the master Jeff Doyle :)

This is the second article about IP Routing of my notes series, gathered over years of work and studies. Hundreds of pages of notebook with key notes and remarks I found important working with Routing and Switching for almost 15 years.

I believe this information will help not only with the certification exam, but also on the daily lives of others (like me) when dealing with Cisco infrastructure.

For those who have not read the previous articles, follow the 2 links on “Switching 1”, “Switching 2”, “PPP”, “Frame relay” and “IP Routing 1”. Below is the second part about “IP Routing” exploring Enhanced Object Tracking (EOT), Policy Routing, Generic Routing Encapsulation Tunnel (GRE) and a great list of Show commands + filters that I think efficient.

Enhanced Object Tracking (EOT)

This is the traditional known tracking, also known as response time reporter (RTR).

Basically, it reliably monitors anything for end-to-end connectivity.

EOT adds “application intelligence” to the end-to-end reliability service because there are dozens of protocols to monitor with EOT (telnet, ssh, ping, etc.). The most common test is “echo” (ping).

DOC: IP Application Services Configuration Guide

DOC: IP SLAs Configuration Guide

EOT is not recommended for very complex environments, but adds a certain level of intelligence in simple environments. A good example is an access router that is behind a modem or transceiver using EOT to verify connectivity to the destination.

Policy Routing

While normal routing is destination based, Routing Policies can be decided based on:

• Source
• Destiny
• Protocol Type
• Input interface

Basically, everything that fits into an extended ACL can be used to adjust Routing Policy.

One downside is that configuration must be done manually and therefore does not scalable at all. Also, most platforms support policy routing only in software (processing skyrockets).

• NOTE: High end devices support hardware policy routing depending on the used PFC.

Traffic criteria is defined by a match in route-maps:

• permit — routed by policy
• deny — routed normally through the RIB

Action is defined by a “set” in route-maps:

• can forward to next-hop, interface or set parameter.

NOTE: When routing directly to an interface we should always use P2P interfaces, avoiding L3 -> L2 resolution problems.

NOTE: As routing policy is usually performed in software it can generate high CPU utilization. Newer versions have “policy cache”.

DOC: PBR

Two policy-routing modes:

• policy — applied to inbound traffic
• local policy — applied to locally sourced traffic

NOTE: Some devices had a bug that included “local PBR” traffic from the control plane itself (eg routing protocols), altering the routing behavior.

NOTE: In CCIE lab the typical use of PBR is usually to override the default routing.

NOTE: Never run “debug ip policy” with the output to the console, can crash the router (then, it’s history…). Best method is to enable an ACL on the router that should receive traffic just to count packets through matches.

PBR’s downside is that there is no way to check through the control plane if PBR has created a topology loop. A loop when the router forwards the packet through the same interface as it arrived (usually the packet is dropped).

To apply PBR you need to have a whole vision of the network. Mixing PBRs can be $ # !T, beware.

When PBR is directed to a multipoint interface, it also queries the RIB to decide next-hop and to encapsulate L3 -> L2 (or it will fail mapping). Therefore always use P2P or next-hop IP interface.

NOTE: The ideal is to always check through debug with ACL filtering.

If PBR is unable to define the destination interface through RIB recursion, PBR will be rejected and traffic will be forwarded normally (FIB policy rejected — normal forwarding).

You need to understand the network behavior, so always make sure the topology agrees with what you want to do before applying PBR… or the packet may go the wrong way and cause a loop.

Setting route-map without an ACL to “match” means that EVERYTHING will be handled in PBR.

When PBR points to a next-hop on ethernet you should use <set ip next-hop verify-availability>. This is because PBR uses recursion for interface line status and not end-to-end connectivity.

• Over serial interface and frame relay it works.
• Verify-availability over CDP does not work well on ethernet because it will detect the directly connected SW (not the routers or equipment connected to the SW).
• — NOTE: The ethernet problem can be fixed with “L2 protocol tunnel” (very bad) or with EOT (tracking) because it is end-to-end (much better !!!).

NOTE: Traceroute in IOS does not use ICMP, uses UDP ECHO. Therefore everything that changes ping will not work with traceroute (debugs show different behavior for each one). So if testing with ping (ICMP) already adds UDP to test traceroute too.

Generic Routing Encapsulation Tunnel (GRE)

• IP Protocol 47 (IP in IP is 4)
• Used to carry other protocols such as payload over an IPV4 network (eg IPV4, IPV6, etc).

The main difference between GRE and other tunneling protocols is that GRE is multiprotocol and can encapsulate practically anything.

Steps:

1. Create tunnel interface (default mode is GRE)
2. Define source and destination (test connectivity between them)
3. Apply payload protocols
4. optional keepalive (off by default)

Recursive tunnel failure:

• The tunnel destination must not allow recursion to the tunnel interface itself:
• — 1.1.1.1 via tunnel 1 -> tunnel 1 via 1.1.1.1 -> 1.1.1.1 via tunnel 1 ->…
• IOS detects such a failure and disables the interface.
• This could be due to a static or dynamic routing failure where the router learns the tunnel destination interface IP through the tunnel itself. The main cause is when we use dynamic routing in the tunnel and tunnel source interface, using incorrect metrics or AD.

GRE (like PBR) is process switched, but some platforms support hardware GRE.

By default, the tunnel remains UP / UP if there is a route to the destination IP but it does not mean there is end-to-end connectivity. To perform this end-to-end tracking we must enable bidirectional keepalives. If you do not enable a reliable tunnel routing protocol, always use keepalives on both sides.

GRE has a default protection mechanism that gives a lower priority to dynamically learned routes through the tunnel. IOS accomplishes this by using very low tunnel BW (eg 100Kb) and very high delay (eg 50000 usec) so that routing protocols give preference to other routes learned through physical interfaces.

So the main caution is that the destination interface should NEVER be learned through the tunnel. Both routers should NEVER propagate the source address of the tunnel through the tunnel itself. The key solution in this case is to filter such an address (eg for RIP and EIGRP we can use distribute-list).

• NOTE: The filtered address must be from the route advertised by the routing protocol and not the destination address itself (eg loopback 1.1.1.1/24 will be learned via EIGRP 1.1.1.0/24).

Reliable Backup Interface with GRE

GRE can be used to monitor end-to-end (mostly multipoint) links using two-way keepalives. A good solution used with legacy systems where other solutions are not supported.

• Just configure source, destination, keepalives, retries and no protocol required.
• Negative point is that the convergence time is high (almost 30 sec).

First option is the “backup interface” configured in the tunnel that tracks the multipoint interface, pointing the backup to some secondary link. Ex: frame relay when a circuit goes down and the multipoint remains UP… any scenario that does not allow end-to-end reliability.

Second option is to apply a static route pointing to the tunnel and a floating route pointing to the secondary link. The drawback is the constant GRE overhead (header, processed in software etc).

Other tunnels:

• GRE encapsulates everything. Required to encapsulate CLNS (IS-IS).
• IP in IP is more efficient with smaller header but only encapsulates IPV4.
• IPV6-IP only encapsulates IPV6.

Show Commands for IP Routing

ping X sou Y

trace X sou Y

sh arp

sh nhrp (for DMVPNs)

sh ip int bri

sh ip int bri | ex una

sh ip route

sh ip static route

sh ip policy

sh ip int

sh route-map

sh ip sla stat

sh ip sla conf

sh track

sh track bri

sh backup

Does this IP Routing content help you in everyday tasks?

Is it missing something important?

Tell me in the comments.

If you like this content, please share. Don’t forget to follow me and TechRebels by clicking “follow” down below :)

About the author:

Giuliano Barros is Network Consultant at PS Network Experts.

Gratuated in Computer Science, CCIE certified by Cisco Systems and work for 15 years with projects for medium and big size companies.

linkedin.com/in/giulianobarros