rms.koenig-solutions.comrms.koenig-solutions.com/sync...iproutingnet.docx · web viewip routing....

IP ROUTING

Cisco IP Classless CommandWhen Cisco routers have to forward packets, they will check their routing table and they use longest prefix matching to find the best match. If you don’t have a best match then the router will use a default route (if you have one). Otherwise, the packet will be dropped.

The forwarding behavior that I described above is called classless routing and it has been the default since IOS 11.3. This is an ancient version, it went end-of-sale around 1998 so classless routing is the only thing that most people know about nowadays.The other method is called classful routing and it works slightly different. Instead of trying to explain this with text it’s better to see it in action with some examples.Don’t confuse classful and classless routing with classful and classless routing protocols. Those are two different things…

To demonstrate the difference between classless and classful routing I will use the following topology:

R2 has four loopback interfaces that we will try to reach from R1. To do this, we’ll use some static routes on R1. Let’s take a look at the configuration…

ConfigurationClassless Routing

Let’s start with the default mode, classless routing. Here’s what the routing table of R1 looks like:

R1#show ip route static172.16.0.0/24 is subnetted, 2 subnetsS 172.16.0.0 [1/0] via 192.168.12.2S 172.16.1.0 [1/0] via 192.168.12.2S* 0.0.0.0/0 [1/0] via 192.168.12.2

We have three static routes. Let’s try to ping each loopback interface on R2:

R1#ping 172.16.0.2

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/28/68 ms

This ping works because we have a specific 172.16.0.0 /24 route in the routing table. Let’s try 172.16.1.2:

R1#ping 172.16.1.2


This ping also works because we have a specific 172.16.1.0 /24 route in the routing table. Let’s try 172.16.2.2:

R1#ping 172.16.2.2


This ping works, there is no specific entry for it in the routing table but we can use the default route for it. Last but not least, let’s try 10.10.10.2:

R1#ping 10.10.10.2


This ping also works because of the default route. So far everything is working as expected. Now let’s take a look at classful routing.

Classful Routing

First we have to disable classless routing on R1:

R1(config)#no ip classless

Also to make this work, you have to disable CEF (Cisco Express Forwarding):

R1(config)#no ip cef

Now we are ready for some tests. First of all, let me show you the routing table again:

R1#show ip route static 172.16.0.0/24 is subnetted, 2 subnetsS 172.16.0.0 [1/0] via 192.168.12.2S 172.16.1.0 [1/0] via 192.168.12.2S* 0.0.0.0/0 [1/0] via 192.168.12.2

Nothing has changed in the routing table, it’s exactly the same. Only the forwarding decisions of the router have changed. Let’s try those pings again:

R1#ping 172.16.0.2

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/24/60 msR1#ping 172.16.1.2

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/56 ms

The first two pings are successful because we have two matching entries in the routing table: 172.16.0.0 /24 and 172.16.1.0 /24. Before I try a ping to 172.16.2.2, let’s enable a debug:

R1#debug ip packet IP packet debugging is on

Now let’s try that ping:

R1#ping 172.16.2.2

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:

Success rate is 0 percent (0/5)

This ping doesn’t work anymore and this is what the debug tells us:

R1#IP: s=192.168.12.1 (local), d=172.16.2.2, len 100, unroutable.

So why does this ping fail? Classful routing works a bit different. R1 will check its routing table and sees that it has an entry for major network 172.16.0.0 which has two subnets: 172.16.0.0 /24 and 172.16.1.0 /24. There is no entry for 172.16.2.0 /24 so the router thinks this subnet is unreachable. Instead of using the default route, the router will drop this packet.What about the 10.10.10.0 /24 subnet? Let's try a ping:

R1#ping 10.10.10.2


This ping works because the router uses the default route for this. It can use the default route because there is no major network (10.0.0.0) that it has to check.

IP Classless and OSPF

To make it even more confusing (or interesting), there is an exception with classful routing .If you have a default route that is advertised by OSPF then the router will act as if its doing classless routing.

Let's get rid of the default route on R1:

R1(config)#no ip route 0.0.0.0 0.0.0.0 192.168.12.2

Now we will configure OSPF and R2 will advertise a default route on R2:

R1(config)#router ospf 1R1(config-router)#network 192.168.12.0 0.0.0.255 area 0R2(config)#router ospf 1R2(config-router)#network 192.168.12.0 0.0.0.255 area 0R2(config-router)#default-information originate always

Let's take a look at R1:

R1#show ip route | include 0.0.0.0/0O*E2 0.0.0.0/0 [110/1] via 192.168.12.2, 00:01:26, FastEthernet0/0

R1 now uses the default route from OSPF. Let's try that ping to 172.16.2.2 again:

R1#ping 172.16.2.2


And our ping is working...even though we don't have an entry that matches 172.16.2.2 under the major network 172.16.0.0, the router can use the OSPF default route.

SummaryClassful routing can be confusing, let me summarize the rules:

Classless routing: the router will use longest prefix matching to find the best entry in the routing table. If you don't have any specific routes then the default route will be used, otherwise the packet will be dropped.

Classful routing: the router will use longest prefix matching to find the best entry in the routing table. If you don't have any specific routes then you can only use the default route if you don't have an entry for the major network in your routing table.

Nobody uses classful routing anymore but at least you now know how it works..

ICMP Redirect on Cisco IOSICMP redirect messages are used by routers to inform hosts that there is a better next hop to reach a certain destination. Take a look at the following topology for an example:

Let me explain the topology above:

R1, R2 and the host are connected to the 192.168.12.0 /24 network. R1 is connected to an ISP to reach the Internet, it will use a default route to get there.

R2 is connected to R3, there’s a server behind R3 that is reachable at IP address 3.3.3.3. R1 uses a static route to reach 3.3.3.3. Hosts on the 192.168.12.0 /24 network will use R1 as their default gateway.Whenever our host tries to reach 3.3.3.3 then it will send its packets to its default gateway. R1 however has a static route for this destination that points to R2.

This is a bit pointless since packets from the host will enter and exit the same interface on R1. To prevent this from happening, our routers can use ICMP redirect.When R1 receives IP packets from the host with 3.3.3.3 as its destination then it will send an ICMP redirect message telling the host to use R2 as their gateway for this destination. Most hosts will respect these ICMP messages and will use R2 to reach 3.3.3.3 from now on.

Cisco IOS routers will send ICMP redirects when the following conditions are met:

The IP packet should be received and transmitted on the same interface. The source IP address of the incoming packet should be on the same subnet as the new next hop

IP address. The IP packet doesn’t use source routing. ICMP redirect has to be enabled, on Cisco IOS routers this is enabled by default.Let’s take a look at some configuration examples so you can see how this works. I’ll use the following topology for this:

I will use the same topology but I’ve added a couple of hosts:

Windows 8 host Linux host

Cisco router as host (IP routing disabled)Let’s see how these hosts act when they receive an ICMP redirect.

ConfigurationFirst let me show you the routing tables of R1 and R2:

R1#show ip route static | begin viaS* 0.0.0.0/0 [1/0] via 192.168.14.4 3.0.0.0/32 is subnetted, 1 subnetsS 3.3.3.3 [1/0] via 192.168.12.2

R1 has two static routes, a default route and an entry for 3.3.3.3. Here’s R2:

R2#show ip route static | begin viaS 3.3.3.3 [1/0] via 192.168.23.3

R2 only has a static route for 3.3.3.3 with R2 as its next hop.

Let’s enable ICMP debugging on R1, this will show us when R1 is sending ICMP redirects:

R1#debug ip icmp ICMP packet debugging is on

alle hosts even proberen…

Windows Host

We will start with the Windows host. Let’s send a ping to 3.3.3.3:

C:Usersvmware>ping 3.3.3.3

Pinging 3.3.3.3 with 32 bytes of data:Reply from 3.3.3.3: bytes=32 time=4ms TTL=254Reply from 3.3.3.3: bytes=32 time=1ms TTL=254Reply from 3.3.3.3: bytes=32 time=2ms TTL=254Reply from 3.3.3.3: bytes=32 time=2ms TTL=254

Ping statistics for 3.3.3.3:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 4ms, Average = 2ms

We don’t see anything spectacular on the host but R1 generates the following message:

R1#ICMP: redirect sent to 192.168.12.100 for dest 3.3.3.3, use gw 192.168.12.2

It's telling our Windows host to use R2 as the gateway to reach 3.3.3.3. Here's what it looks like in wireshark:

Above you can see that the ICMP type 5 message is an ICMP redirect. Now take a look at the next packet that the host will send:

This IP packet that is destined for 3.3.3.3 now uses the MAC address of R2 as the destination. We can confirm this by checking the MAC address on R2:

R2#show interfaces FastEthernet 0/0 | include address Hardware is MV96340 Ethernet, address is 0017.5aed.7af0 (bia 0017.5aed.7af0)

The windows host doesn't really notify us that its traffic has been redirected but you can see that something happened behind the scenes.

Supposedly you should be able to see an entry in the windows routing table that you can see with the route print command. I tried this on a windows 7 and 8 host but couldn't find anything...

Let's try another host!

Linux Host

This time we'll try a Linux host, I used the desktop version of Ubuntu. When we send a ping we see this:

$ ping 3.3.3.3PING 3.3.3.3 (3.3.3.3) 56(84) bytes of data.From 192.168.12.1: icmp_seq=1 Redirect Network(New nexthop: 192.168.12.1)64 bytes from 192.168.12.1: icmp_seq=1 ttl=254 time=4.56 ms64 bytes from 192.168.12.1: icmp_seq=2 ttl=254 time=1.25 ms

This is great, our linux host tells us that it received the ICMP redirect. You can also verify this with the following command:

$ ip route get 3.3.3.33.3.3.3 via 192.168.12.2 dev eth0 src 192.168.12.101 cache <redirected>

Above you see a cached entry for 3.3.3.3. Whenever we try to reach this IP address, we'll use R2 as the default gateway.

Cisco Device

Last but not least, let's see what a Cisco device does with the ICMP redirect. I will use a router that has IP routing disable:

Host(config)#ip default-gateway 192.168.12.1Host(config)#no ip routing

Here's how you can verify that this router doesn't have a routing table anymore:

Host#show ip route Default gateway is 192.168.12.1

Host Gateway Last Use Total Uses InterfaceICMP redirect cache is empty

There's no routing table and this device will use 192.168.12.1 as its default gateway. It also shows us the ICMP redirect cache which is empty at the moment. Let's send a ping to 3.3.3.3:

Host#ping 3.3.3.3Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/202/1000 ms

Now take a look at the routing table:

Host#show ip routeDefault gateway is 192.168.12.1

Host Gateway Last Use Total Uses Interface3.3.3.3 192.168.12.2 0:00 12 FastEthernet0/0

The router stored an entry for 3.3.3.3 in its ICMP redirect cache. You can verify this with another command:

Host#show ip redirects Default gateway is 192.168.12.1

Host Gateway Last Use Total Uses Interface3.3.3.3 192.168.12.2 0:07 12 FastEthernet0/0

The show ip redirects command will tell us the same thing.

ConclusionYou have now seen how ICMP redirects help to redirect traffic to another gateway. Although this might sound useful, it's also a security risk. These messages are very simple to spoof and all our hosts accepted the redirect packet without any issues. For this reason it's probably a good idea to disable this on your hosts.

You can also disable it on your Cisco IOS routers:

R1(config)#interface FastEthernet 0/0R1(config-if)#no ip redirects

If you use the no ip redirects command then it will no longer send ICMP redirect messages to hosts.That's all we have for now, I hope this has been useful! If you have any questions, feel free to leave a comment!

CEF (Cisco Express Forwarding)

Perhaps you have heard about the term “wirespeed” before. It’s something the marketing department likes to use when it comes to selling networking equipment. It means that packets can be forwarded without any noticeable delay. Oh btw, for the remaining of this lesson the words “multilayer switch” and “router” are the same thing. Everything that I explain about the multilayer switches from now on also applies to routers.Let’s take a look at the difference between layer 2 and multilayer switches from the switch’s perspective:

You know that layer 2 switches only will switch Ethernet frames within a VLAN, and if we want we can filter traffic based on layer 2 (for example with port-security). The multilayer switch can do the same but is also able to route between VLANS and filter on layer 3 or 4 using access-lists.

Forwarding on layer 2 is based on the destination MAC address. Our switch learns the source MAC addresses on incoming frames and it builds the MAC address table. Whenever an Ethernet frame enters one of our interfaces, we’ll check the MAC address table to find the destination MAC address and we’ll send it out the correct interface.

Forwarding on layer 3 is based on the destination IP address. Forwarding happens when the switch receives an IP packet where the source IP address is in a different subnet than the destination IP address.When our multilayer switch receives an IP packet with its own MAC address as the destination in the Ethernet header there are two possibilities: If the destination IP address is an address that is configured on the multilayer switch then the IP

packet was destined for this switch. If the destination IP address is an address that is not configured on the multilayer switch then we

have to act as a gateway and “route” the packet. This means we’ll have to do a lookup in the routing table to check for the longest match. Also we have to check if the IP packet is allowed if you configured an ACL.

Back in the days…switching was done at hardware speed while routing was done in software. Nowadays both switching and routing is done at hardware speed. In the remaining of this lesson you’ll learn why.Let’s take a look at the difference between handling Ethernet Frames and IP Packets:

The life of a layer 2 switch is simple:

1. The switch will verify the checksum of the Ethernet frame to make it sure it’s not corrupted or altered.

2. The switch receives an Ethernet frame and adds the source MAC address to the MAC address table.

3. The switch forwards the Ethernet frame to the correct interface if it knows the destination MAC address. If not, it will be flooded.

There is no alteration of the Ethernet frame!Now let’s see what we have to do when we receive an IP packet on a multilayer switch:

In the example above H1 is sending an IP packet towards H2. Note that they are in different subnets so we will have to route it. When our multilayer switch receives the IP packet this is what will happen:

1. The switch will verify the checksum of the Ethernet frame to make it sure it’s not corrupted or altered.

2. The switch will verify the checksum of the IP packet to make it sure it’s not corrupted or altered.

The multilayer switch will check the routing table, notices that 192.168.20 /24 is directly connected and the following will happen:

1. Check the ARP table to see if there’s a layer 2 to 3 mapping for H2. If there is no mapping the multilayer switch will send an ARP request.

2. The destination MAC address changes from FFF (Multilayer switch Fa0/1 ) to BBB (H2).

3. The source MAC address changes from AAA (H1) to GGG (Multilayer switch Fa0/2).4. The TTL (time to live) field in the IP packet is decreased by 1 and because of this the IP header

checksum will be recalculated.5. The Ethernet frame checksum must be recalculated.6. The Ethernet frame carrying the IP packet will be sent out of the interface towards H2.As you can see there are quite some steps involved if we want to route IP packets.

When we look at multilayer switches there is a “separation of duties”. We have to build a table for the MAC addresses, fill a routing table, ARP requests, check if an IP packet matches an access-list etc and we need to forward our IP packets. These tasks are divided between the “control plane” and the “data plane”. Let me give you an illustration:

The control plane is responsible for exchanging routing information using routing protocols, building a routing table and ARP table.The data plane is responsible for the actual forwarding of IP packets. The routing table isn’t very suitable for fast forwarding because we have to deal with recursive routing. What is recursive routing? Let me give you an example:

In the example above I have three routers. R3 has a loopback interface that we want to reach from R1. I will use static routes for reachability:

R1(config)#ip route 3.3.3.0 255.255.255.0 192.168.23.3R1(config)#ip route 192.168.23.0 255.255.255.0 192.168.12.2

The first static route is to reach the loopback0 interface of R3 and points to the FastEthernet0/0 interface of R3. The second static route is required to reach network 192.168.23.0/24.

R1#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 -IS-IS level-2 ia - IS-IS inter area, * - candidate default, per-user static route o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 192.168.12.0/24 is directly connected, FastEthernet0/0 3.0.0.0/24 is subnetted, 1 subnetsS 3.3.3.0 [1/0] via 192.168.23.3S 192.168.23.0/24 [1/0] via 192.168.12.2

Whenever R1 wants to reach 3.3.3.0/24 we have to do 3 lookups:

The first lookup is to check the entry for 3.3.3.0 /24. It’s there and the next hop IP address is 192.168.23.3

The second lookup is for 192.168.23.3. There’s an entry and the next hop IP address is 192.168.12.2.

The third and last lookup is for 192.168.12.2. There’s an entry and it is directly connected.R1 has to check the routing table 3 times before it knows where to send its traffic. Doesn’t sound very efficient right? Doing multiple lookups to reach a certain network is called recursive routing.

Most of the time all incoming and outgoing IP packets will be processed and forwarded by the data plane but there are some exceptions, first let me show you this picture:

Most of the IP packets can be forwarded by the data plane. However there are some “special” IP packets that can’t be forwarded by the data plane immediately and they are sent to the control plane, here are some examples:

IP packets that are destined for one of the IP addresses of the multilayer switch. Routing protocol traffic like OSPF, EIGRP or BGP. IP packets that have some of the options set in the IP header. IP packets with an expired TTL.The control plane can forward outgoing IP packets to the data plane or use its own forwarding mechanism to determine the outgoing interface and the next hop IP address. An example of this is local policy based routing. If you have never heard about policy based routing, don’t worry…it’s covered in CCNP ROUTE.

Our multilayer switch has many more steps to take than the layer 2 switches so theoretically it should be slower right?

One reason that multilayer switches are able to forward frames and packets at wirespeed is because of special hardware called ASICs in the dataplane.

Information like MAC addresses, the routing table or access-lists are stored into these ASICs. The tables are stored in content-addressable memory (CAM) and ternary content addressable memory (TCAM). The CAM table is used to store layer 2 information like:

o The source MAC address.o The interface where we learned the MAC address on.o To which VLAN the MAC address belongs.

Table lookups are fast! Whenever the switch receives an Ethernet frame it will use a hashing algorithm to create a “key” for the destination MAC address + VLAN and it will compare this hash to the already hashed information in the CAM table. This way it is able to quickly lookup information in the CAM table.

The TCAM table is used to store “higher layer” information like:o Access-lists.o Quality of service information.o Routing table.

The TCAM table can match on 3 different values:o 0 = must be 0.o 1 = must be 1.o X = 0 or 1 both acceptable.

Longest match will return a hit. Useful for a lookup where we don’t need an exact match. (routing table or ACLs for example).Because there are 3 values we call it ternary.So why are there 2 types of tables?

When we look for a MAC address we always require an exact match. We require the exact MAC address if we want to forward an Ethernet frame. The MAC address table is stored in a CAM table.Whenever we need to match an IP packet against the routing table or an access-list we don’t always need an exact match. For example an IP packet with destination address 192.168.20.44 will match: 168.20.44 /32 168.20.0 /24 168.0.0 /16Information like the routing table are stored in a TCAM table for this reason. We can decide whether all or some bits have to match.

Here’s an example of a TCAM table:

If we want to match IP address 192.168.10.22 the multilayer switch will first see if there’s a “most specific match”. There is nothing that matches 192.168.10.22 /32 so we’ll continue if there is anything else that matches. In this case there is an entry that matches 192.168.10.0 /24. The example above applies to routing table lookups, access-lists but also quality of service, VLAN access-lists and more.

Now you know all the steps a multilayer switch has to take when it has to forward ip packets, the control/data plane and that we use different tables stored in special hardware called ASICs. Let’s take a closer look at the actual ‘forwarding’ of IP packets.

There are different switching methods to forward IP packets. Here are the different switching options: Process switching:

o All packets are examined by the CPU and all forwarding decisions are made in software…very slow!

Fast switching (also known as route caching):o The first packet in a flow is examined by the CPU; the forwarding decision is cached in

hardware for the next packets in the same flow. This is a faster method.

(CEF) Cisco Express Forwarding (also known as topology based switching):o Forwarding table created in hardware beforehand. All packets will be switched using

hardware. This is the fastest method but there are some limitations. Multilayer switches and routers use CEF.

When using process switching the router will remove the header for each Ethernet frame, look for the destination IP address in the routing table for each IP packet and then forward the Ethernet frame with the rewritten MAC addresses and CRC to the outgoing interface. Everything is done in software so this is very CPU-intensive.

Fast switching is more efficient because it will lookup the first IP packet but it will store the forwarding decision in the fast switching cache. When the routers receive Ethernet frames carrying IP packets in the same flow it can use the information in the cache to forward them to the correct outgoing interface.The default for routers is CEF (Cisco Express Forwarding). Let’s take a closer look at CEF:

The multilayer switch will use the information from tables that are built by the (control plane) to build hardware tables. It will use the routing table to build the FIB (Forwarding Information Base) and the ARP table to build the adjacency table. This is the fastest switching method because we now have all the layer 2 and 3 information required to forward IP packets in hardware.I should mention that some "lower end" routers don't have dedicated hardware for forwarding, they store these tables in software.

Are you following me so far? Let’s take a look at the forwarding information table and the adjacency table on some routers. If you want to follow me along you can take a look at your multilayer switch OR use routers in GNS3:

I’ll use the same topology that I showed you earlier. 3 routers and R3 has a loopback0 interface.

I’ll use static routes to have full connectivity:

R1(config)#ip route 3.3.3.0 255.255.255.0 192.168.23.3R1(config)#ip route 192.168.23.0 255.255.255.0 192.168.12.2R2(config)#ip route 3.3.3.0 255.255.255.0 192.168.23.3R3(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2

These are the static routes that I’ll use.Now let me show you the routing and FIB table:

R1#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route


C 192.168.12.0/24 is directly connected, FastEthernet0/0 3.0.0.0/24 is subnetted, 1 subnetsS 3.3.3.0 [1/0] via 192.168.23.3S 192.168.23.0/24 [1/0] via 192.168.12.2R1#show ip cef Prefix Next Hop Interface

0.0.0.0/0 drop Null0 (default route handler entry)0.0.0.0/32 receive3.3.3.0/24 192.168.12.2 FastEthernet0/0192.168.12.0/24 attached FastEthernet0/0192.168.12.0/32 receive192.168.12.1/32 receive192.168.12.2/32 192.168.12.2 FastEthernet0/0192.168.12.255/32 receive192.168.23.0/24 192.168.12.2 FastEthernet0/0224.0.0.0/4 drop224.0.0.0/24 receive255.255.255.255/32 receive

Show ip cef reveals the FIB table to us.You can see there’s quite some stuff in the FIB table, let me explain some of the entries:

0.0.0.0/0 is for the null0 interface. When we receive IP packets that match this rule then it will be dropped.

0.0.0.0/32 is for all-zero broadcasts. Forget about this one since we don’t use it anymore. 3.3.3.0/24 is the entry for the loopback0 interface of R3. Note that the next hop is 192.168.12.2

and NOT 192.168.23.3 as in the routing table! 192.168.12.0/24 is our directly connected network. 192.168.12.0/32 is reserved for the exact network address. 192.168.12.1/32 is the IP address on interface FastEthernet 0/0. 192.168.12.2/32 is the IP address on R2’s FastEthernet 0/0 interface. 192.168.12.255/32 is the broadcast address for network 192.168.12.0/24. 224.0.0.0/4 matches all multicast traffic. It will be dropped if multicast support is disabled

globally. 224.0.0.0/24 matches all multicast traffic that is reserved for local network control traffic (for

example OSPF, EIGRP). 255.255.255.255/32 is the broadcast address for a subnet.Let’s take a detailed look at the entry for network 3.3.3.0 /24:

R1#show ip cef 3.3.3.0 3.3.3.0/24, version 8, epoch 0, cached adjacency 192.168.12.20 packets, 0 bytes via 192.168.23.3, 0 dependencies, recursive next hop 192.168.12.2, FastEthernet0/0 via 192.168.23.0/24 valid cached adjacency

The version number tells us how often this CEF entry was updated since the table was generated. We can see that in order to reach 3.3.3.0/24 we need to go to 192.168.23.3 and that a recursive lookup is required. The next hop is 192.168.12.2. It also says that it’s a valid cached adjacency. There are a number of different adjacencies:

Null adjacency: used to send packets to the null0 interface. Drop adjacency: you’ll see this for packets that can’t be forwarded because of encapsulation

errors, routes that cannot be resolved or protocols that are not supported. Discard adjacency: this is for packets that have to be discarded because of an access-list or

other policy. Punt adjacency: used for packets that can't be forwarded by CEF. They will be "punted" to the

next switching method (fast switching and process switching). Glean adjacency: used for directly connected routes. It's used to tell the router that it should

check the ARP table since it can reach the device directly.Packets that are not forwarded by CEF are handled by the CPU. If you have many of those packets then you might see performance issues.

You can see how many packets have been handled by the CPU:

R1#show cef not-cef-switched CEF Packets passed on to next switching layerSlot No_adj No_encap Unsupp'ted Redirect Receive Options Access FragRP 0 0 0 0 17 0 0 0

You can use the show cef not-cef-switched command to verify this; the number of packets are listed per reason: No_adj: adjacency is incomplete. No_encap: ARP information is incomplete. Unsupp’ted: packet has features that are not supported. Redirect: ICMP redirect. Receive: These are the packets that were destined for an IP address configured on a layer 3

interface, packets that are meant for our router. Options: There are IP options in the header of the packet. Access: access-list evaluation failure. Frag: packet fragmention error.We can also take a look at the adjacency table that stores the layer 2 information for each entry:

R1#show adjacency summary Adjacency Table has 1 adjacency Table epoch: 0 (1 entry at this epoch)

Interface Adjacency Count FastEthernet0/0 1

You can use the show adjacency summary command to take a quick look how many adjacencies we have. An adjacency is a mapping from layer 2 to 3 and comes from the ARP table.

R1#show adjacency Protocol Interface AddressIP FastEthernet0/0 192.168.12.2(9)

R1 only has a single interface that is connected to R2. You can see the entry for 192.168.12.2 which is the FastEthernet 0/0 interface of R2. Let’s zoom in on this entry:

R1#show adjacency detail Protocol Interface AddressIP FastEthernet0/0 192.168.12.2(9) 0 packets, 0 bytes CC011D800000CC001D8000000800 ARP 03:55:00 Epoch: 0

We can see there’s an entry for 192.168.12.2 and it says:

CC011D800000CC001D8000000800

What does this number mean? It’s the MAC addresses that we require and the Ethertype…let me break it down for you:

CC011D800000 is the MAC address of R2’s FastEthernet0/0 interface.

R2#show interfaces fastEthernet 0/0FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is cc01.1d80.0000 (bia cc01.1d80.0000)

• CC001D800000 is the MAC address of R1’s FastEthernet0/0 interface.

R1#show interfaces fastEthernet 0/0FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is cc00.1d80.0000 (bia cc00.1d80.0000)

0800 is the Ethertype. 0x800 stands for IPv4.

Thanks to the FIB and adjacency table we have all the layer 2 and 3 information that we require to rewrite and forward packets. Keep in mind before actually forwarding the packet we first have to rewrite the header information:

Source MAC address. Destination MAC address. Ethernet frame checksum. IP Packet TTL. IP Packet Checksum.Once this is done we can forward the packet. Now you have an idea what CEF is about and how packets are dealt with.

Every now and then students ask me what the difference is between routers and switches since a multilayer switch can route, and a router can do switching if you want.

The difference is getting smaller but switches normally only use Ethernet. If you buy a Cisco Catalyst 3560 or 3750 you’ll only have Ethernet interfaces. They have ASICs so switching of frames can be done at wire speed. Routers on the other hand have other interfaces like serial links, wireless and they can be upgraded with modules for VPN, VoIP etc. You can’t configure stuff like NAT/PAT on a (small) switch. The line is getting thinner however…

I hope this lesson has helped you to understand CEF!

TCLSH and Macro Ping Test on Cisco Routers and SwitchesWhen you are studying for CCIE R&S you will have to check connectivity every now and then. It’s a good idea to use ping to check if you can reach all IP addresses of the routers and switches in your network. If you have many devices and many IP addresses it will take too much time to ping each IP address manually.

Luckily you can use TCLSH (Tool Control Language) on your Cisco routers and devices, a scripting language that is used a lot by Cisco and one of the things it can do is ping IP addresses for us.

First you should check the active IP addresses on your device using the following command:

Router#show ip aliasAddress Type IP Address PortInterface 192.168.12.1 Interface 192.168.13.1 Interface 192.168.1.1

The show ip alias command will show you all active IP addresses on your device. You can also use show ip interface brief | exclude unassigned to see all IP addresses of active interfaces:

Router#show ip interface brief | exclude unassignedInterface IP-Address OK? Method Status ProtocolFastEthernet0/0 192.168.12.1 YES manual up up Serial0/0.1 192.168.13.1 YES manual up up Loopback0 192.168.1.1 YES manual up up

Copy and paste these to notepad…do this for all your routers and switches. Now we can use TCLSH to automatically ping all these IP addresses, this is how it works:

Router#tclshRouter(tcl)#foreach address {+>1.1.1.1+>2.2.2.2+>3.3.3.3+>150.1.4.4+>} { ping $address repeat 3 size 1500 }

Type escape sequence to abort.Sending 3, 1500-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:!!!Success rate is 100 percent (3/3), round-trip min/avg/max = 4/8/12 msType escape sequence to abort.Sending 3, 1500-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:!!!Success rate is 100 percent (3/3), round-trip min/avg/max = 4/4/4 ms

Type escape sequence to abort.Sending 3, 1500-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:!!!Success rate is 100 percent (3/3), round-trip min/avg/max = 1/1/1 msType escape sequence to abort.Sending 3, 1500-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:!!!Success rate is 100 percent (3/3), round-trip min/avg/max = 1/4/8 msRouter(tcl)#tclquit

The script above will ping all my IP addresses 3 times and set the packet size to 1500 bytes. Something you should remember is that you need to type tclquit to exit TCLSH scripting.You can use TCLSH on routers and most switches. In case your switch doesn’t support TCLSH you can also create a macro that does a similar job. Here’s how to do it:

Switch#configure terminalSwitch(config)#macro name PING_TESTEnter macro commands one per line. End with the character '@'.do ping 192.168.12.1do ping 192.168.13.1do ping 192.168.1.1@

First we will create a macro called PING_TEST. A macro can only be applied from the global configuration so we need to add “do” in front of our ping. The macro is stored in the running configuration as you can see here:

Switch#show run | begin macromacro name PING_TESTdo ping 192.168.12.1do ping 192.168.13.1do ping 192.168.1.1@

Now we will test our macro:

Switch(config)#macro global apply PING_TEST

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 msType escape sequence to abort.Sending 5, 100-byte ICMP Echos to 192.168.13.1, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 msType escape sequence to abort.Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 msSwitch(config)#

From the global configuration just type macro global apply and the name of your macro. As you can see it pings all our IP addresses.That’s all for now, I hope this helps you to save time at your CCIE lab exam!

InterVLAN RoutingIn this lesson we are going to take a look at routing between VLANs. When we want communication between different VLANs we’ll need a device that can do routing. We could use an external router but it’s also possible to use a multilayer switch (aka layer 3 switches).Let’s look at the different options!

Router on a Stick

SW1 has two VLANs so we have two different subnets. If we want communication between these VLANs we’ll have to use a device that can do routing. In this example we’ll use a router for the job. R1 will need access to both VLANs so we’ll create a 802.1Q trunk between SW1 and R1. Here’s how to configure this:

SW1(config)#interface fa0/3SW1(config-if)#switchport trunk encapsulation dot1q SW1(config-if)#switchport mode trunk SW1(config-if)#switchport trunk allowed vlan 10,20

This is how we configure SW1. Make interface fa0/3 a trunk port and for security measures I made sure that only VLAN 10 and 20 are allowed.

R1(config)#interface fa0/0.10R1(config-subif)#encapsulation dot1Q 10R1(config-subif)#ip address 192.168.10.254 255.255.255.0R1(config)#interface fa0/0.20R1(config-subif)#encapsulation dot1Q 20R1(config-subif)#ip address 192.168.20.254 255.255.255.0

Create two sub-interfaces on the router and tell it to which VLAN they belong. Don’t forget to add an IP address for each VLAN.

R1#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route


C 192.168.10.0/24 is directly connected, FastEthernet0/0.10C 192.168.20.0/24 is directly connected, FastEthernet0/0.20

The router will be able to route because these two networks are directly connected.

C:\Documents and Settings\H1>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.10.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.10.254C:\Documents and Settings\H2>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 192.168.20.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.20.254

Don’t forget to set your IP address and gateway on the computers.

Let’s try a ping:

C:\Documents and Settings\H1>ping 192.168.20.1

Pinging 192.168.20.1 with 32 bytes of data:

Reply from 192.168.20.1: bytes=32 time<1ms TTL=128Reply from 192.168.20.1: bytes=32 time<1ms TTL=128Reply from 192.168.20.1: bytes=32 time<1ms TTL=128Reply from 192.168.20.1: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

That’s how you do it. So why would you want to use a solution like this? It’s cheap! You don’t need a multilayer switch for your routing. Any layer 2 switch will do.

The Cisco Catalyst 2960 is a layer 2 switch; the cheapest multilayer switch is the Cisco Catalyst 3560. Compare the price on those two and you’ll see what I’m talking about.

Some of the disadvantages of this solution is that your router is a single point of failure and that traffic flows up and down on the same link which might cause congestion.

So what other solutions do we have?

SVI (Switch Virtual Interface)

This is the picture of a multilayer switch. This switch has routing capabilities! I can configure something called a SVI (Switch Virtual Interface) for each VLAN and put an IP address on it. This IP address can be used for computers as their default gateway. Here’s how to configure it:

SW1(config)#ip routingSW1(config)#interface vlan 10SW1(config-if)#no shutdownSW1(config-if)#ip address 192.168.10.254 255.255.255.0SW1(config)#interface vlan 20SW1(config-if)#no shutdownSW1(config-if)#ip address 192.168.20.254 255.255.255.0

Start by enabling routing using the ip routing command. If you forget this your switch won’t build a routing table! Next step is to create a SVI for VLAN 10 and 20 and configure IP addresses on them. This configuration might look familiar if you worked with layer 2 switches before. On a layer 2 switch like the Cisco Catalyst 2950/2960 we also have a SVI but you can only use it for remote management.

Once you create a SVI and type no shutdown it will normally be “up” since it’s only a virtual interface, there are however a number of requirements or it will show up as “down”:

The VLAN has to exist in the VLAN database and it should be active. At least one access or trunk port should use this VLAN actively and it should be in

spanning-tree forwarding mode.Simply said: the VLAN has to be active somehow or your SVI will go down.

I have two computers in VLAN 10 and created a SVI for VLAN 10.

SW1#show ip interface brief vlan 10Interface IP-Address OK? Method Status ProtocolVlan10 192.168.10.254 YES manual up up

You’ll see that the status says up/up so that’s good.

If I shutdown one interface nothing will change, my SVI will still show up/up because interface fa0/2 is still active.

SW1#show ip interface brief vlan 10Interface IP-Address OK? Method Status ProtocolVlan10 192.168.10.254 YES manual up down

Once I shut both interfaces we don’t have anything active anymore in VLAN 10. As a result the SVI will go to up/down.

Now if I want I can exclude an interface from the SVI state. Imagine I want to make sure that whatever happens to interface fa0/2 doesn’t influence the SVI state:

SW1(config)#interface fa0/2SW1(config-if)#switchport autostate exclude

I can use the switchport autostate exclude command. This means it won’t influence the state of the SVI interface anymore. Fa0/1 is the only interface that can now influence the SVI state, as soon as it goes down you’ll see that SVI state go down as well, even though fa0/2 is still up and running.

Enough about the SVI, there’s another method we can use our multilayer switch for routing. By default all interfaces on a switch are switchports (layer 2) but we can change them to routed ports (layer 3). A routed port is the exact same interface as what we use on a router.

Routed PortBy default all interfaces on a switch are switchports (layer 2) but we can change them to routed ports (layer 3). A routed port is the exact same interface as what we use on a router.

Here’s an example of the routed port. SW2 is a layer 2 switch and SW3 is a multilayer switch. The fa0/16 interface on SW3 has been configured as a router port so it can be used as the default gateway for the clients in VLAN 10.

SW2(config)#interface fa0/16SW2(config-if)#switchport mode access SW2(config-if)#switchport access vlan 10

I’m going to configure the fa0/16 interface to SW3 as a normal access port and put it in VLAN 10.

SW3(config)#interface fa0/16SW3(config-if)#no switchportSW3(config-if)#ip address 192.168.10.254 255.255.255.0

Make it a routed port by typing no switchport and put an IP address on it, it can now be used by the computers as a gateway!There are two things you should remember about this routed port:

It’s no longer a switchport so it’s not associated with any VLAN. It’s a routed port but it doesn’t support sub-interfaces like a router does.

What should you use? The SVI or the routed port? If you only have one interface in a VLAN it’s fine to use the routed port, configure an IP address on it and you are ready to go. If you have multiple interfaces in a VLAN you should use the SVI.

Routing ProtocolsMultilayer switches can use routing protocols. Let me show you an example:

I have two multilayer switches and the link in between is layer 2. Let's configure these switches:

SW2(config-if)#switchport trunk encapsulation dot1q SW2(config-if)#switchport mode trunkSW3(config-if)#switchport trunk encapsulation dot1q SW3(config-if)#switchport mode trunk

I’m creating a 802.1q trunk in between the switches but it doesn’t matter what you pick. I also could have used access interfaces and use a single VLAN.

SW2(config)#vlan 10SW2(config)#interface vlan 10SW2(config-if)#ip address 192.168.10.1 255.255.255.0SW3(config)#vlan 10SW3(config)#interface vlan 10SW3(config-if)#ip address 192.168.10.2 255.255.255.0

Create a SVI interface on each Switch and configure an IP address.

SW3#ping 192.168.10.1


The switches can reach each other so the SVI interfaces and trunk are working.

SW2(config)#ip routingSW2(config)#router eigrp 10SW2(config-router)#network 192.168.10.0SW2(config)#ip routingSW3(config)#router eigrp 10SW3(config-router)#network 192.168.10.0

Let’s configure EIGRP to see if we can form a neighbor adjacency.

SW2 %DUAL-5-NBRCHANGE: EIGRP-IPv4:(10) 10: Neighbor 192.168.10.2 (Vlan10) is up: new adjacency

There goes…the switches have found each other.

SW3#show ip eigrp neighbors EIGRP-IPv4:(10) neighbors for process 10H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num0 192.168.10.1 Vl10 13 00:01:25 1 200 0 1

We have successfully configured EIGRP between these two switches using the SVI interfaces.

We can also do this with the routed ports!

Same switches but now I’m going to make the link in between layer 3 by using the routed ports.

SW2(config)#no interface vlan 10SW2(config)#interface fa0/16SW2(config-if)#no switchportSW2(config-if)#ip address 192.168.10.1 255.255.255.0SW3(config)#no interface vlan 10SW3(config)#interface fa0/16SW3(config-if)#no switchportSW3(config-if)#ip address 192.168.10.2 255.255.255.0

Get rid of the SVI interfaces and change the interfaces to routed ports. Don’t forget to add an IP address.

SW2(config)#router ospf 10SW2(config-router)#network 192.168.10.0 0.0.0.255 area 0SW#(config-if)#router ospf 10SW3(config-router)#network 192.168.10.0 0.0.0.255 area 0

Let’s configure OSPF this time just for fun!

SW2#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface192.168.10.2 1 FULL/DR 00:00:37 192.168.10.2 FastEthernet0/16

We have established an OSPF neighbor adjacency by using the routed ports!

These are all the methods how you can configure routing on your multilayer switches. The router on a stick, SVI interfaces and the routed port. I hope this lesson has been useful to you!

Cisco Offset-List CommandWhen you run a routing protocol like EIGRP or OSPF you can influence the metric of the routing protocol by changing the bandwidth (OSPF or EIGRP) or by changing the delay (EIGRP). RIP uses hop count so you need to add some extra routers in between to increase the hop count.

Instead of changing these parameters to influence your routing, you can also use an offset-list.

The offset-list lets you increase the metric when you send a routing update to your neighbor or when you receive it.You can use this for RIP or EIGRP, it is not supported for OSPF.

Let me show you an example to see what I mean:

We have two routers running RIP version 2. The router on the left (R1) has two loopback interfaces that have been advertised in RIP. Here’s what the routing table of R2 looks like:

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


1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/1] via 192.168.12.1, 00:00:17, FastEthernet0/0 11.0.0.0/24 is subnetted, 1 subnetsR 11.11.11.0 [120/1] via 192.168.12.1, 00:00:17, FastEthernet0/0

Nothing special here, we see the two prefixes with a hop count of 1. Let’s increase the hop count of the first prefix by using an outbound offset-list on R1:

R1(config)#router ripR1(config-router)#offset-list ? <0-99> Access list of networks to apply offset (0 selects all networks) <1300-1999> Access list of networks to apply offset (expanded range) WORD Access-list name

You need to enter the routing protocol configuration and use the offset-list command. I can choose between all networks or use a standard access-list to make a selection. Let’s use an ACL:

R1(config-router)#offset-list 1 ? in Perform offset on incoming updates out Perform offset on outgoing updates

Once you pick the access-list you have to decide whether the offset-list is in- or outbound. I’ll use outbound so that R2 receives a higher hop count from R1. The last option lets you set the metric:

R1(config-router)#offset-list 1 out ? <0-16> Offset

When you use RIP we don’t have a lot of choice. Let’s try a hop count of 5:

R1(config-router)#offset-list 1 out 5

Last but not least, don’t forget to create the access-list or the offset-list will apply to all prefixes:

R1(config)#access-list 1 permit 1.1.1.0 0.0.0.255

Here’s the result:

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



Above you can see that prefix 1.1.1.0 /24 has its hop count increase by 5, it’s now 6 in total.

You have now seen the outbound offset-list, let’s try the inbound one. I’ll create an access-list on R2 that increases the hop count of the 11.11.11.0 /24 prefix:

R2(config)#access-list 2 permit 11.11.11.0 0.0.0.255

That’s the access-list, and here’s the offset-list:

R2(config-router)#offset-list 2 in 10

It should increase the hop count of this prefix by 10 whenever R2 learns about this prefix, here’s the routing table of R2:

R2#show ip route rip *Aug 21 12:48:19.211: %SYS-5-CONFIG_I: Configured from console by consoleCodes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP + - replicated route, % - next hop override



Great! You can see that the total hop count is now 11.

There's one more little thing I'd like to share about the offset-list. By default the offset-list will be applied to all interfaces, if you only want to influence the metric of routing updates that you receive from a particular interface then you need to specify this. Here's how:

R2(config-router)#offset-list 2 in 10 ? Async Async interface Auto-Template Auto-Template interface BVI Bridge-Group Virtual Interface CDMA-Ix CDMA Ix interface CTunnel CTunnel interface Dialer Dialer interface FastEthernet FastEthernet IEEE 802.3 [output omitted]

When you configure the offset-list you can specify the interface after the metric, here's an example:

R2(config-router)#offset-list 2 in 10 FastEthernet 0/0

This tells the router only to increase the metric for routing updates that we receive on the FastEthernet 0/0 interface.

How to configure Administrative DistanceWhen two or more sources are giving you information about a certain prefix you need to choose which information you are going to use. For example OSPF might tell you to go “left” if you want to reach network X, EIGRP might tell you that you need to go “right”. Who do you trust? OSPF or EIGRP? You can’t put both in the routing table for network X.

The administrative distance solves this problem. When two sources give us information about the exact same network we’ll have to make a decision and it’s done by looking at the administrative distance. Let me show you the different values:

Source Administrative Distance

Directly connected 0

Static route 1

EIGRP summary 5

External BGP 20

EIGRP 90

IGRP 100

OSPF 110

IS-IS 115

RIP 120

ODR 160

External EIGRP 170

Internal BGP 200

Unknown 255

The lower the better…as you can see EIGRP has a lower administrative distance (90) than OSPF (110) so we will use EIGRP in my example.

Keep in mind:

The administrative distance is only local and can be different for each router. The administrative distance can be modified.Especially when we use redistribution we sometimes have to change the administrative distance. Let me show you how you can do this:

Router(config)#router eigrp 12 Router(config-router)#distance eigrp 90 160

Above we have EIGRP and with the distance command I can change the administrative distance for EIGRP globally. Internal EIGRP will keep its AD of 90 but external EIGRP will have an AD of 160. You will see this change in the routing table:

Router#show ip route eigrp 3.0.0.0/24 is subnetted, 1 subnetsD EX 3.3.3.0 [160/1734656] via 192.168.12.2, 00:00:30, FastEthernet0/0D EX 192.168.23.0/24 [160/1734656] via 192.168.12.2, 00:00:30,FastEthernet0/0

You can verify it by looking at the routing table, the external networks on router Jack now have an AD of 160.

We can change the AD of the other routing protocols as well, here are some examples:

Router(config)#router ospf 1Router(config-router)#distance ospf external 150 inter-area 80 intra-area 80

For OSPF you can change the external, inter-area and intra-area administrative distance. In my example I’ve set the external distance (type 5 and 7 external LSAs) to 150. Inter-area distance is 80 and intra-area is 80. This means that your router will now prefer OSPF information above EIGRP (AD 90).

The downside of the two examples above is that it applies to all prefixes. I can also change the administrative distance only for certain prefixes, here's how to do it:

R1(config)#router ripR1(config-router)#distance 70 0.0.0.0 255.255.255.255 MY_PREFIXESR1(config)#ip access-list standard MY_PREFIXESR1(config-std-nacl)#permit 1.1.1.0 0.0.0.255

I use the distance command and combine it with a standard access-list called “MY_PREFIXES”. All networks that match this access-list will have their AD changed to 70.

Router#show ip route rip R 192.168.12.0/24 [120/10] via 192.168.23.2, 00:00:15, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [70/10] via 192.168.23.2, 00:00:15, FastEthernet0/0

Above you see the new administrative distance for network 1.1.1.0 /24.

That's all I wanted to show you for now, if you have any questions feel free to ask!

How to configure Policy Based RoutingPolicy-based routing can be used to change the next hop IP address for traffic matching certain criteria. This can be useful to overrule your routing table for certain traffic types. I will show you how to configure policy based routing.

Configurationhere’s the topology that we will use:

Take a look at the topology picture above. OSPF is configured on all routers. Since we are using Gigabit interfaces everywhere, traffic from R1 destined to 4.4.4.4 would normally be load balanced between R2 and R3. However, I changed the cost on the Gigabit Ethernet 0/3 interface of R1 so that all traffic will go from R1 > R2 > R4.

Let’s verify this:

R1#show ip ospf interface GigabitEthernet 0/2 | include Cost: Process ID 1, Router ID 192.168.13.1, Network Type BROADCAST, Cost: 1R1#show ip ospf interface GigabitEthernet 0/3 | include Cost: Process ID 1, Router ID 192.168.13.1, Network Type BROADCAST, Cost: 1000

Above you can see the increased cost. Let’s try a quick traceroute from H1:

H1#traceroute 4.4.4.4 probe 1Type escape sequence to abort.Tracing the route to 4.4.4.4VRF info: (vrf in name/id, vrf out name/id) 1 192.168.1.254 7 msec 2 192.168.12.2 6 msec 3 192.168.24.4 8 msec

Now let’s say that I want to use the link in between R1 and R3 to reach 4.4.4.4. I could influence the metric for OSPF, but this applies to all traffic. What if I wanted to use this link for certain traffic only?We could use the link in between R1/R2 for the majority of our traffic and use the link between R1/R3 only for certain traffic. This can be very useful. For example, imagine that the link between R1/R3 is a dedicated link that offers QoS for VoIP traffic.

This is something we can achieve with PBR_H1 (Policy Based Routing). Let me show you how!

Right now, all traffic is sent towards R2:

R1#show ip route | include 4.4.4.4O 4.4.4.4 [110/3] via 192.168.12.2, 00:16:48, GigabitEthernet0/2

Now let’s say that we want all ICMP traffic from H1 destined for 4.4.4.4 to cross the link between R1/R3. Here’s how to do this:

R1(config)#ip access-list extended ICMP_H1R1(config-ext-nacl)#permit icmp host 192.168.1.100 host 4.4.4.4

First, I create an access-list that matches my traffic. Now we have to create a route-map:

R1(config)#route-map PBR_H1 permit 10R1(config-route-map)#match ip address ICMP_H1R1(config-route-map)#set ip next-hop 192.168.13.3

Whenever the traffic matches the access-list, we will change the next hop to 192.168.13.3 (R3).

Last but not least, let’s activate it:

R1(config)#interface GigabitEthernet 0/1R1(config-if)#ip policy route-map PBR_H1

Let’s see if it works, to see it in action I will enable a debug on R1:

R1#debug ip policy Policy routing debugging is on

Now let’s send a ping from H1:

H1#ping 4.4.4.4 repeat 1Type escape sequence to abort.Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:!Success rate is 100 percent (1/1), round-trip min/avg/max = 13/13/13 ms

The ping is working, let’s see what R1 thinks of it:

R1#IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 100, FIB policy matchIP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 100, PBR_H1 CountedIP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, g=192.168.13.3, len 100, FIB policy routed

Above you can see that it has been policy routed towards 192.168.13.3. We can also verify this by looking at the route-map:

R1#show route-map PBR_H1route-map PBR_H1, permit, sequence 10 Match clauses: ip address (access-lists): ICMP_H1 Set clauses: ip next-hop 192.168.13.3Nexthop tracking current: 0.0.0.0192.168.13.3, fib_nh:0,oce:0,status:0

Policy routing matches: 1 packets, 114 bytes

Let’s try some traffic that doesn’t match our access-list. Telnet for example:

H1#telnet 4.4.4.4Trying 4.4.4.4 ... Open

H1 is able to connect but it’s not policy routed:

R1#IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 40, FIB policy rejected(no match) - normal forwarding

As you can see above, this telnet traffic is routed using the normal path.

There is one more thing I’d like to show you. With policy-based routing, there is a difference between traffic that is going through the router and traffic that is originated from the router.The example above is for traffic that went through our router. What if we want to policy route traffic that is originated from R1? We will have to use another command to activate it. Let’s create another route-map:

R1(config)#ip access-list extended ICMP_R1R1(config-ext-nacl)#permit icmp host 192.168.12.1 host 4.4.4.4R1(config-ext-nacl)#permit icmp host 192.168.13.1 host 4.4.4.4

R1(config)#route-map PBR_R1 permit 10R1(config-route-map)#match ip address ICMP_R1R1(config-route-map)#set ip next-hop 192.168.13.3

The route-map above will redirect all traffic from R1 to 4.4.4.4 towards R3. To activate this, we need to use another command:

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

This time, we need to use the ip local policy command. Let’s test this:

R1#ping 4.4.4.4 repeat 1Type escape sequence to abort.Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:!Success rate is 100 percent (1/1), round-trip min/avg/max = 19/19/19 msR1#IP: s=192.168.12.1 (local), d=4.4.4.4, len 100, policy matchIP: route map PBR_R1, item 10, permit

IP: s=192.168.12.1 (local), d=4.4.4.4 (GigabitEthernet0/3), len 100, policy routedIP: local to GigabitEthernet0/3 192.168.13.3

Great, our traffic from R1 is policy routed.

ConclusionPolicy-based routing allows us to overrule the global routing table for traffic that matches our access-list. This can be a great way to redirect traffic for certain applications. To activate PBR, there is a difference for traffic that is going through the router or that is originated by the router:

Use the ip policy command under the interface for traffic that is going through the router.

Use the ip policy local command globally for traffic that is originated by the router.

Introduction to RedistributionMost networks you encounter will probably only run a single routing protocol like OSPF or EIGRP. Maybe you find some old small networks that are still running RIP that need migration to OSPF or EIGRP. What if you have a company that is running OSPF and you just bought another company and their network is running EIGRP?

It’s possible that we have multiple routing protocols on our network and we’ll need some method to exchange routing information between the different protocols. This is called redistribution. We’ll look into some of the issues that we encounter. What are we going to do with our metrics? OSPF uses cost and EIGRP uses K-values and they are not compatible with each other….RIP uses hop count.Redistribution also adds another problem. If you “import” routing information from one routing protocol into another it’s possible to create routing loops.

If you don’t feel 100% confident about your knowledge on OSPF and EIGRP then I suggest you stop reading now and read more about OSPF / EIGRP or do some labs. One routing protocol can be difficult but when you mix a couple of them the fun really starts…

Having said that, let’s take a look at a possible redistribution scenario:

Look at the topology picture above. We have routers running EIGRP in AS 1 with the 10.0.0.0 /8 network. OSPF has multiple areas and we have 20.0.0.0 /8 there. At the bottom there are two RIP routers in the 30.0.0.0 /8 network. If we want to have full connectivity in this network we’ll have to do some redistribution.

Redistribution is not just for between routing protocols, we have multiple options:

Between routing protocols (RIP, OSPF, EIGRP, BGP). Static routes can be redistributed into a routing protocol. Directly connected routes can be redistributed into a routing protocol.Normally you use the network command to advertise directly connected routes into your routing protocol. You can also use the redistribute connected command which will redistribute it into the routing protocol. Let’s take a look at some real routers:

In the topology picture above I have three routers. R1 is running EIGRP and R3 is running RIP. R2 is in the middle and is running EIGRP and RIP. If we want to do redistribution we’ll have to do it on R2. Let’s take a look shall we?

R1(config)#router eigrp 12R1(config-router)#no auto-summaryR1(config-router)#network 192.168.12.0 R1(config-router)#network 1.1.1.0 0.0.0.255R2(config)#router eigrp 12R2(config-router)#no auto-summaryR2(config-router)#network 192.168.12.0R2(config-router)#exitR2(config)#router ripR2(config-router)#version 2R2(config-router)#no auto-summary R2(config-router)#network 192.168.23.0R3(config)#router rip

R3(config-router)#version 2R3(config-router)#no auto-summary R3(config-router)#network 192.168.23.0 R3(config-router)#network 3.3.3.0

Here are the router configurations, nothing special…I only advertised the links to get EIGRP and RIP up and running.

R1#show ip route


C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsC 1.1.1.0 is directly connected, Loopback0R2#show ip route


C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsD 1.1.1.0 [90/156160] via 192.168.12.1, 00:05:01, FastEthernet0/0R 3.0.0.0/8 [120/1] via 192.168.23.3, 00:00:12, FastEthernet1/0C 192.168.23.0/24 is directly connected, FastEthernet1/0R3#show ip route


3.0.0.0/24 is subnetted, 1 subnetsC 3.3.3.0 is directly connected, Loopback0C 192.168.23.0/24 is directly connected, FastEthernet0/0

Here are the routing table of all three routers after configuring RIP and EIGRP. You can see R2 has learned the loopback interfaces of R3 and R1. R1 and R3 don’t have anything in their routing table because R2 is not advertising anything. As you can see redistribution is not done automatically.Before I show you the redistribution configurations there are two things you should be aware of:

Redistribution happens outbound. If I configure redistribution on R2 then nothing will changein the routing table of R2.o R2 will redistribute EIGRP routing information into RIP and advertise it to R3.o R2 will redistribute RIP routing information into EIGRP and advertise it to R3.

o You need the networks in your local routing table before you can do redistribution. You can’t advertise (or redistribute) what you don’t have…

When we redistribute from one routing protocol into another we have to use a seed metric. Each routing protocols uses a different metric: OSPF: Cost EIGRP: K-Values (bandwidth, delay, load and reliability) RIP: Hop countSomehow we have to convert the metric from one routing protocol to another. This is something that doesn’t happen automatically…we have to tell the router what metric to use and it’s different for each routing protocol.

Protocol Default Seed Metric

RIP Infinity

EIGRP Infinity

OSPF 20 except BGP is 1.

BGP BGP metric is set to IGP metric

This table is important to remember. If you redistribute something into RIP then the default seed metric is infinity. What does RIP do with routes that have an infinite metric? That’s right…they don’t show up in your routing table! This means you have to configure a default hop count for everything you redistribute into RIP or it’s not going to work.The same thing applies to redistributing into EIGRP. You have to configure the K-values yourself otherwise redistribution is not going to work.

OSPF is friendlier…if you redistribute into OSPF then the redistributed routes will have a default cost of 20 unless the routing information comes from BGP…which has a cost of 1.

R2(config)#router ripR2(config-router)#default-metric 5R2(config)#router eigrp 12R2(config-router)#default-metric 1500 100 255 1 1500

Here’s an example how you can configure the default seed metric by using the default-metric command. Default-metric 5 sets the hop count to 5 for everything we redistribute into RIP.

For EIGRP you have to specify the K-values. In my example I’m using a bandwidth of 1500, a delay of 100, reliability 255 (which means 100%), load of 1 (1%) and a MTU of 1500. In case you are wondering these are just values that I made up. Everything we redistribute into EIGRP will have this metric.

Now you have an idea what redistribution is about, in the upcoming lessons I will show you how to redistribute between different routing protocols. Let me know if you have any questions!

How to configure Redistribution between EIGRP and RIPIn previous lessons I explained the basics of redistribution and I also showed you how to configure redistribution between OSPF and RIP. This time we’ll take a look at redistribution between EIGRP and RIP. Let’s take a look at the topology that we will use:

Above we have 3 routers. Router R1 and R2 are configured for EIGRP. R2 and R3 are both configured for RIP.

First we will configure EIGRP and RIP without any redistribution:

R1(config)#router eigrp 12R1(config-router)#no auto-summary R1(config-router)#network 1.1.1.0 0.0.0.255R1(config-router)#network 192.168.12.0R2(config)#router eigrp 12

R2(config-router)#no auto-summary R2(config-router)#network 192.168.12.0R2(config)#router ripR2(config-router)#no auto-summary R2(config-router)#version 2R2(config-router)#network 192.168.23.0R3(config)#router ripR3(config-router)#version 2R3(config-router)#no auto-summaryR3(config-router)#network 192.168.23.0R3(config-router)#network 3.3.3.0

Above are the router configurations I’ve used, nothing special…redistribution doesn’t happen automatically this is something we have to do ourselves. Let’s configure it:

R2(config)#router eigrp 12R2(config-router)#redistribute rip metric 1500 100 255 1 1500

I’m redistributing RIP into EIGRP and I have to specify the metrics. Pick whatever values you like. In you don’t specify the seed metric than the default one will be infinity and your redistributed routes don’t show up!

R2(config)#router eigrp 12R2(config-router)#default-metric 1500 100 255 1 1500

You can also configure the seed metric globally for EIGRP using the default-metric command.

R1#show ip route eigrp 3.0.0.0/24 is subnetted, 1 subnetsD EX 3.3.3.0 [170/1734656] via 192.168.12.2, 00:01:39, FastEthernet0/0D EX 192.168.23.0/24 [170/1734656] via 192.168.12.2, 00:03:49, FastEthernet0/0

This is what router R1’s routing table now looks like. You can see these networks show up as EIGRP external and the administrative distance is 170.

R2(config)#router ripR2(config-router)#redistribute eigrp 12 metric 10

To redistribute EIGRP into RIP we’ll have to specify the AS number for EIGRP (12) and the metric (hop count).

R3#show ip route ripR 192.168.12.0/24 [120/10] via 192.168.23.2, 00:00:06, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/10] via 192.168.23.2, 00:00:06, FastEthernet0/0

And here you see the RIP routes, that’s all there is to it.

How to configure Redistribution between OSPF and RIPIn a previous lesson I explained the basics of Redistribution. Now it’s time to actually configure some redistribution. In this lesson we’ll cover redistribution between OSPF and RIP. This is the topology that we will use:

Let’s start with the redistribution between OSPF and RIP.

First let me show you the router configurations:

R1(config)#router ospf 1R1(config-router)#network 1.1.1.0 0.0.0.255 area 0R1(config-router)#network 192.168.12.0 0.0.0.255 area 0R2(config)#router ospf 1R2(config-router)#network 192.168.12.0 0.0.0.255 area 0R2(config)#router ripR2(config-router)#version 2R2(config-router)#no auto-summary R2(config-router)#network 192.168.23.0R3(config)#router ripR3(config-router)#version 2R3(config-router)#network 3.3.3.0R3(config-router)#network 192.168.23.0

Nothing special here, just OSPF and RIP advertising their networks.

R1#show ip route


C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsC 1.1.1.0 is directly connected, Loopback0R2#show ip route


C 192.168.12.0/24 is directly connected, FastEthernet0/0 1.0.0.0/32 is subnetted, 1 subnetsO 1.1.1.1 [110/2] via 192.168.12.1, 00:11:05, FastEthernet0/0 3.0.0.0/24 is subnetted, 1 subnetsR 3.3.3.0 [120/1] via 192.168.23.3, 00:00:20, FastEthernet1/0C 192.168.23.0/24 is directly connected, FastEthernet1/0R3#show ip route


3.0.0.0/24 is subnetted, 1 subnetsC 3.3.3.0 is directly connected, Loopback0C 192.168.23.0/24 is directly connected, FastEthernet0/0

You can see router R2 has learned RIP and OSPF information. Time for some redistribution action!

R2(config)#router rip

R2(config-router)#redistribute ? bgp Border Gateway Protocol (BGP) connected Connected eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) isis ISO IS-IS iso-igrp IGRP for OSI networks metric Metric for redistributed routes mobile Mobile routes odr On Demand stub Routes ospf Open Shortest Path First (OSPF) rip Routing Information Protocol (RIP) route-map Route map reference static Static routes <cr>

First I’m going to redistribute OSPF into RIP. You can see I can choose a lot of different protocols when you use the redistribute command.

R2(config)#router ripR2(config-router)#redistribute ospf 1 metric 5

This is how I redistribute OSPF (process 1) into RIP. I’m setting the hop count to 5. Keep in mind the default seed metric for RIP is infinity. If I don’t specify a metric your redistribution will fail!

R2(config)#router ripR2(config-router)#default-metric 5

I also could have used the default-metric command to set a default hop count for everything I’m redistributing.

R3#show ip route rip R 192.168.12.0/24 [120/5] via 192.168.23.2, 00:00:00, FastEthernet0/0 1.0.0.0/32 is subnetted, 1 subnetsR 1.1.1.1 [120/5] via 192.168.23.2, 00:00:00, FastEthernet0/0

This is what the routing table of router R3 looks like. You can see the OSPF networks that are redistributed into RIP. You can also see the seed metric (hop count) of 5….excellent!

R2(config)#router ospf 1R2(config-router)#redistribute rip subnets

Let’s redistribute RIP into OSPF now. I can use the redistribute rip subnets command here. The keyword subnets is needed because otherwise OSPF will redistribute classful! I want it to redistribute classless so that’s why I’ve added the keyword subnets.

R1#show ip route ospf 3.0.0.0/24 is subnetted, 1 subnetsO E2 3.3.3.0 [110/20] via 192.168.12.2, 00:00:21, FastEthernet0/0O E2 192.168.23.0/24 [110/20] via 192.168.12.2, 00:00:21, FastEthernet0/0

Let’s look at router R1. You can see OSPF information in the routing table. They show up as external type 2 routes. The cost is 20 (which is the default). OSPF is a bit more sophisticated than RIP and makes a difference between internal and external routes.If routes are redistributed into OSPF as type 2 then every router in the OSPF domain will see the same cost to reach the external networks. If routes are redistributed into OSPF as type 1, then the cost to reach the external networks could vary from router to router.

Configurations R1 R2 R3

Want to take a look for yourself? Here you will find the configuration of each device.

I hope this example helps you to understand redistribution between OSPF and RIP. Make sure you understand the “basics” before you move on to more complex redistribution scenarios. If you have any questions feel free to ask!

How to configure Route TaggingWhen you configure multipoint redistribution it’s a good idea to use route tagging to prevent advertising something from routing protocol “A” into “B” and back into “A”. Let

me give you an example:

Above you see routing protocol A and B. At the bottom we find network 1.1.1.0 /24. Let’s say that R1 redistributes this network from routing protocol A into B. R2 will learn about this network from routing protocol B and will redistribute it back into Routing Protocol A. This is something you want to avoid and we can do it with route tagging…

here’s an example:

When R1 redistributes network 1.1.1.0 /24 into routing protocol B it should tag it. When R2 is going to redistribute routing information from routing protocol B into routing protocol A it will notice the tag and skip redistribution for network 1.1.1.0 /24.Of course the same thing applies to R2. I’m only showing you the example for R1:

R1#show ip route 1.1.1.0Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2 Last update from 192.168.12.2 on FastEthernet0/0, 00:00:04 ago Routing Descriptor Blocks: * 192.168.12.2, from 192.168.45.4, 00:00:04 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1

You can use show ip route to check if a route has been tagged or not. Nothing has been tagged so far. Let’s configure route tagging:

R1(config)#route-map TAG deny 10R1(config-route-map)#match tag 1R1(config-route-map)#exitR1(config)#route-map TAG permit 20R1(config-route-map)#set tag 1

You can tag routes using a route-map. I created a simple route-map called TAG with two sequence numbers:

Sequence number 10 says that when it matches tag number 1 that it should be denied. Sequence number 20 says that we need to set tag number 1. There’s no “match” statement so

EVERYTHING will match.

R1(config)#router ripR1(config-router)#redistribute ospf 1 metric 5 route-map TAGR1(config)#router ospf 1R1(config-router)#redistribute rip subnets route-map TAG

Now I need to make sure we use the route-map when redistributing. The example above is for redistributing into RIP and OSPF. At the end of your redistribution command you need to specify the route-map. Everything that is redistributed INTO RIP or OSPF will have a tag of 1. Once again I’m only showing R1 but you need to do this on R2 as well.

R2#show ip route 1.1.1.0Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 20 Tag 1, type extern 2, forward metric 3 Redistributing via rip Last update from 192.168.13.1 on FastEthernet0/0, 00:00:25 ago Routing Descriptor Blocks: * 192.168.13.1, from 192.168.45.4, 00:00:25 ago, via FastEthernet0/0 Route metric is 20, traffic share count is 1 Route tag 1

If you look at this network you can now see that it has been tagged. This is because of the second part of our route-map:

route-map TAG permit 20 set tag 1

Above you see the part of the route-map that did this tagging for us.

route-map TAG deny 10 match tag 1

And this is the part of the route-map that prevents it from redistributing it again.

In other words…if your router sees something that has been tagged it will not be redistributed, otherwise it will be redistributed and a tag will be set.

This is a very simple solution to make sure you don’t inject routing information back into the routing protocol where it originated from. You have to do this on each router when you use multipoint redistribution!

I hope this has been helpful to you!

Troubleshooting Metric RedistributionRedistribution is a difficult topic to master. The configuration is quite easy but if you are not careful you will end up with sub-optimal routing and/or routing loops.When it comes to redistribution issues, there are two possible problems that we can encounter:

Metric based Administrative Distance based

In this lesson we’ll take a look at metric based redistribution problems and how to fix them. To demonstrate this I will use the following topology:

In this topology we have 4 routers. All routers are running RIPv2 while R3 and R4 are also running OSPF on the link between them.

R1 is only used to advertise a network (1.1.1.0 /24) into RIP. This is what the routing configuration looks like right now (without redistribution):

R1#show run | section riprouter rip version 2 offset-list 0 out 5 network 1.0.0.0 network 192.168.12.0 no auto-summaryR2#show run | section riprouter rip version 2 network 192.168.12.0 network 192.168.23.0 network 192.168.24.0 no auto-summaryR3#show run | section riprouter rip version 2 network 192.168.23.0 no auto-summaryR4#show run | section riprouter rip version 2 network 192.168.24.0 no auto-summary

Each router runs RIP version 2, nothing special. Here’s the OSPF configuration of R3 and R4:

R3#show run | section ospfrouter ospf 1 log-adjacency-changes network 192.168.34.0 0.0.0.255 area 0R4#show run | section ospfrouter ospf 1 log-adjacency-changes network 192.168.34.0 0.0.0.255 area 0

Let’s take a look what the routing tables of R2, R3 and R4 look like now. Let’s look at the RIP routes first:

R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:09, FastEthernet1/0R3#show ip route ripR 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:27, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/7] via 192.168.23.2, 00:00:27, FastEthernet0/0R 192.168.24.0/24 [120/1] via 192.168.23.2, 00:00:27, FastEthernet0/0R4#show ip route ripR 192.168.12.0/24 [120/1] via 192.168.24.2, 00:00:02, FastEthernet0/0 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/7] via 192.168.24.2, 00:00:02, FastEthernet0/0R 192.168.23.0/24 [120/1] via 192.168.24.2, 00:00:02, FastEthernet0/0

R2 has learned about network 1.1.1.0 /24 from R1 with a hop count of 6. I used an offset-list on R1 to increase the hop count for this topology, I’ll show you why in a bit.

R3 and R4 also learn about this network and the links in between R1/R2, R2/R3 and R/4. Nothing special so far…

Since R3 and R4 only run OSPF on the directly connected link they don’t have any OSPF routes right now:

R3#show ip route ospfR4#show ip route ospf

So far so good. Now we will continue by configuring redistribution. I’ll do this step-by-step so you can see what will happen. First we will redistribute RIP into OSPF on R3 and R4:

R3 & R4#(config)#router ospf 1(config-router)#redistribute rip subnets

The command above redistribute everything from RIP into OSPF. Let’see what R3 and R4 now have in their routing tables:

R3#show ip route ospfO E2 192.168.24.0/24 [110/20] via 192.168.34.4, 00:01:02, FastEthernet0/1

R3 has now learned through OSPF to reach network 192.168.24.0 /24 with R4 as its next hop. Before we configured redistribution, it had a RIP route for this network with R2 as its next hop. The reason that the RIP route has been removed is because OSPF has a better

administrative distance (120 vs 110):

Is this an issue? For this particular topology right now it won’t cause any issues. R3 can reach this network through R2 or R4. Let’s take a look at R4 now:

R4#show ip route ospfO E2 192.168.12.0/24 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1 1.0.0.0/24 is subnetted, 1 subnetsO E2 1.1.1.0 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1O E2 192.168.23.0/24 [110/20] via 192.168.34.3, 00:01:14, FastEthernet0/1

The output of R4 is a bit more interesting. Take a close look at the first two entries:

192.168.12.0 /24 with R3 as its next hop. 1.1.1.0 /24 with R3 as its next hop.R4 used to have RIP routes for these two networks but they have been replaced with these OSPF entries. Is this a problem? It won’t cause any issues in this topology but this is what we call sub-optimal routing:

We have connectivity but since R4 prefers OSPF (AD 110) over RIP (AD 120) we will send all traffic destined for 192.168.12.0 /24 and 1.1.1.0 /24 through R3. It works, but it’s not optimal.

Why did R4 learn about these routes through R3 and not the other way around (R3 learning those two networks from R4)? R3 and R4 are both redistributing all RIP routes into OSPF so why is there a difference in the output of their routing tables?It depends on which router has converged first. In my example I started with the redistribution configuration on R3. In this case, R3 will redistribute the RIP routes into OSPF and advertises them to R4. R4 will remove its RIP routes for these networks and installs the OSPF routes.

Since R4 doesn’t have a RIP route for 192.168.12.0 /24 and 1.1.1.0 /24 in its routing table, they can’t be redistributed into OSPF and advertised to R3. If I would have configured R4 first (or reset the OSPF process on R3) then R3 would learn about the redistributed RIP routes through OSPF.

We will forget about this sub-optimal routing issue for now, it won’t cause any issues for this topology and the goal of this lesson is to explain you the redistribution metric problem. In my second post I will explain how to fix this issue. In case you are curious, the short answer is that you have to set the AD of the OSPF entries for 192.168.12.0 /24 and 1.1.1.0 /24 to a value higher than 120. This causes R3 and R4 to use the RIP routes instead of the OSPF routes.Let’s continue by redistributing OSPF into RIP, that’s where the real fun starts. We’ll do this on R3 and R4:

R3 & R4#(config)#router ripconfig-router)#redistribute ospf 1 metric 1

We redistribute everything from OSPF into RIP. Now take a look what happens with R2:

R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/1] via 192.168.24.4, 00:00:05, FastEthernet0/1R 192.168.34.0/24 [120/1] via 192.168.24.4, 00:00:05, FastEthernet0/1

[120/1] via 192.168.23.3, 00:00:01, FastEthernet0/0

Take a good look at the entry for 1.1.1.0 /24. R2 installed this route with R4 as its next hop…this will cause issues, check out this traceroute:

R2#traceroute 1.1.1.1

Type escape sequence to abort.Tracing the route to 1.1.1.1

1 192.168.24.4 1388 msec 620 msec 744 msec 2 192.168.34.3 2552 msec 2308 msec 1904 msec 3 192.168.23.2 56 msec 48 msec 48 msec 4 192.168.24.4 76 msec 76 msec 72 msec 5 192.168.34.3 112 msec 124 msec 100 msec 6 192.168.23.2 96 msec 100 msec 92 msec 7 192.168.24.4 124 msec 140 msec 124 msec 8 192.168.34.3 156 msec 168 msec 176 msec 9 192.168.23.2 152 msec 136 msec 156 msec 10 192.168.24.4 176 msec 184 msec 172 msec

That’s not looking good, we now have a routing loop! Traffic is sent like this:

So why exactly is this happening? This is the metric redistribution issue that this lesson is

named after. Let’s zoom in on R2:

R2 is receiving a routing update for network 1.1.1.0 /24 on two interfaces. The update from R1 has a hop count of 6 while the update from R3 has a hop count of 1. R2 selects the route with the lowest hop count so it installs the route towards R3.

RIP doesn’t see the difference between an “internal” and “redistributed” route so it just selects the one with the lowest metric. What about other protocols like OSPF or EIGRP? Are they also vulnerable to this “metric” problem?

OSPF doesn’t have this issue because it always prefers internal “O” and “O IA” routes over O “E1” and “E2” routes.

EIGRP doesn’t have this issue because it always prefers “internal” routes (AD 90) over “external” routes (AD 170). The only exception to this rule is when the original route is an EIGRP external route. In this case, both routes have an AD of 170.

Before we start looking at different solutions to fix this problem, let’s pause for a moment, take a deep breath and think about the “core” issue of the problem that we have here. The problem with the metric that R2 is facing happens because we redistributed the 1.1.1.0 /24

network from RIP into OSPF and then back into RIP:

Advertising a prefix from one routing protocol into another and then back into the first routing protocol is a bad idea. There’s no point feeding this information back into the routing protocol that originated the prefix.You should never redistribute prefixes like this:Routing Protocol X > Y > XThis is a very important redistribution rule, in fact it’s so important that I’ll add it extra large:

Redistribution Rule: Never advertise prefixes from routing protocol X into Y and then back into X.

If we would prevent R4 (and R3) from redistributing the 1.1.1.0 /24 network back into RIP then R2 would never learn this network with that low hop count and there would be no routing loop.

Keep this redistribution rule in mind while we look at the different solutions to fix this problem…

SolutionsThere are many different methods to solve the “metric” redistribution issue that you just witnessed. I’ll show you the different methods and their (dis)advantages. It’s important to

know some of the different methods if you are preparing for the CCIE R&S lab. Let’s look at the first method…

Redistribution Filtering

Instead of just redistributing everything from one routing protocol into another, we'll use some filters to select the prefixes we want to redistribute.We should only redistribute the prefixes that originated in the routing protocol. For example, when we look at OSPF the only network that originated in OSPF is 192.168.34.0 /24 (the link between R3 and R4). This is the only network that we should redistribute into RIP.

Let me show you how to configure a filter when you redistribute:

R3 & R4#(config)#ip access-list standard NATIVE_OSPF_ROUTES(config-std-nacl)#permit 192.168.34.0 0.0.0.255

(config)#route-map NATIVE_OSPF permit 10(config-route-map)#match ip address NATIVE_OSPF_ROUTES(config-route-map)#route-map NATIVE_OSPF deny 20

(config)#router rip(config-router)#redistribute ospf 1 metric 1 route-map NATIVE_OSPF

First we create an access-list that matches the network that we want to redistribute. Secondly we configure a route-map that matches this access-list and finally we attach the route-map to the redistribute command. This fixes our problem since R2 will never learn about network 1.1.1.0 /24 through R3 or R4. Take a look at its routing table:

R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnets

R 1.1.1.0 [120/6] via 192.168.12.1, 00:00:21, FastEthernet1/0

Above you can see that R2 now uses the original (and correct) route for network 1.1.1.0 /24. Great! We just solved our first redistribution problem.

Instead of using an access-list, you can also use a prefix-list. This might be useful if your CCIE lab has a requirement that tells you not to use access-lists or something. Let me change the route-map:

R3 & R4#(config)#ip prefix-list NATIVE_OSPF_ROUTES permit 192.168.34.0/24(config-route-map)#no match ip address NATIVE_OSPF_ROUTES(config-route-map)#match ip address prefix-list NATIVE_OSPF_ROUTES

The end result will be the same.

Sometimes it helps to use clear ip route * to speed up convergence. It's also useful to enable debug ip routing to see changes to the routing table on your console.

The solution I just showed you meets the "don't redistribute routing protocol X > Y > X" rule but it has one limitation...it's not a very scalable solution. When you advertise new prefixes into OSPF, you'll have to add them to your access-list or prefix-list.

We attached a route-map to the redistribution from OSPF into RIP but we didn't do this for redistribution for RIP into OSPF. Technically it doesn't matter much since OSPF guards itself against this redistribution metric problem...it will always prefer internal prefixes over external prefixes. Still, it would be a good idea to prevent prefixes going from OSPF > RIP > OSPF.

Let's take a look at another solution which is more scalable...

Redistribution Route Tagging

Instead of manually selecting the prefixes we want to redistribute we can also "tag" the prefixes. What this means is that whenever we redistribute a prefix, it will be tagged. Here's a illustration:

Above is an example for network 1.1.1.0 /24. When R3 redistributes this network into OSPF, it will add a tag to it. When R4 sees this tag, it won't redistribute it from OSPF to RIP.

This way a router will know if the prefix has already been redistributed or not. Let me show you how to do this, first let's get rid of the route-map we used in the previous example:

R3 & R4#(config)router rip(config-router)#no redistribute ospf 1 metric 1 route-map NATIVE_OSPF(config-router)#redistribute ospf 1 metric 1

I removed the route-map and added the old redistribution command again.

This time we'll create a route-map that tags all prefixes when they are redistributed from RIP into OSPF. Let's do this step-by-step:

R3 & R4#(config)#route-map RIP_TO_OSPF permit 10(config-route-map)#set tag 100

(config)#router ospf 1(config-router)#redistribute rip metric 1 subnets route-map RIP_TO_OSPF

First we create a route-map that permits everything and sets the tag to 100. You can pick whatever value you like. Secondly we apply this route-map to the redistribution of RIP prefixes into OSPF. Now take a look at the OSPF database of R3 and R4:

R3#show ip ospf database | begin Type-5 Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag1.1.1.0 192.168.34.4 6 0x80000001 0x0001BB 100192.168.12.0 192.168.34.3 107 0x80000004 0x00EE59 100192.168.23.0 192.168.34.3 107 0x80000004 0x0075C7 100192.168.24.0 192.168.34.4 59 0x80000004 0x0064D6 100R4#show ip ospf database | begin Type-5 Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag192.168.12.0 192.168.34.3 99 0x80000004 0x00EE59 100192.168.23.0 192.168.34.3 99 0x80000004 0x0075C7 100192.168.24.0 192.168.34.4 50 0x80000004 0x0064D6 100

You can see that the RIP prefixes have been redistributed into OSPF and are tagged with "100". Our next move is to tell R3 and R4 that when we redistribute from OSPF into RIP that we have to ignore the prefixes that are tagged with 100. Here's how to do it:

R3 & R4#(config)#route-map OSPF_TO_RIP deny 10(config-route-map)#match tag 100(config-route-map)#exit(config)#route-map OSPF_TO_RIP permit 20

(config-route-map)#router rip(config-router)#redistribute ospf 1 metric 1 route-map OSPF_TO_RIP

We create a new route-map that denies everything with tag 100 while everything else is permitted. This route-map is attached to the redistribute command under the RIP process. This meets our "don't redistribute from routing protocol X > Y back to X" rule. Take a look at R2:

R2#show ip route rip 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/6] via 192.168.12.1, 00:00:13, FastEthernet1/0

Since R2 never learns about the 1.1.1.0 /24 prefix from OSPF, it will prefer the original route from R1...way to go!

Now you understand route tagging, let me show you an even better solution. We can create a single route-map that can be used for redistribution in both directions. Here's what it looks like:

R3 & R4#(config)#route-map TAGGING deny 10(config-route-map)#match tag 1234(config-route-map)#exit(config)#route-map TAGGING permit 20(config-route-map)#set tag 1234

(config)#router rip(config-router)#redistribute ospf 1 metric 1 route-map TAGGING

(config)#router ospf 1(config-router)#redistribute rip subnets route-map TAGGING

This route-map won't redistribute a prefix if it has a tag of '1234'. If the prefix doesn't have a tag then we will permit it and set the tag to '1234'. The route-map has been attached to OSPF and RIP.

The logic behind this route-map is that when something has been tagged then it must have been redistributed already and we should ignore it. If there is no tag, we set one and redistribute the prefix. The end result is the same:


Instead of only looking at the routing table, enabling a debug is also a nice method to see in- and outgoing routing updates:

R2#debug ip ripRIP protocol debugging is on

RIP: received v2 update from 192.168.24.4 on FastEthernet0/1 192.168.34.0/24 via 0.0.0.0 in 1 hops

RIP: received v2 update from 192.168.23.3 on FastEthernet0/0 192.168.34.0/24 via 0.0.0.0 in 1 hops

This tells us that R3 and R4 are only redistributing 192.168.34.0 /24 towards R2.

Route tagging is the most convenient method to enforce the redistribution rule of "Never advertise prefixes from routing protocol X into Y and then back into X". If you advertise new prefixes in RIP or OSPF then they'll be automatically tagged.

We just used a route-map in combination with an access-list, prefix-list and route tagging. These are the most common methods but you can get pretty creative with the match options that a route-map offers. Some of the examples are matching on the "next hop IP address" or "match interface". To get an idea of the possibilities, take a look at this Cisco article.Let's take a look at some other options to solve our metric redistribution problem...

Redistribution Seed Metric

Forget about the route-maps for now, let's get back to the original scenario. The problem with R2 accepting the 1.1.1.0 /24 network from R4 (or R3) is that the hop count was "an offer it couldn't refuse". Take a look at this picture to refresh your memory:

To make R2 prefer the original information from R1 we could change the seed metric. This is kinda a dirty trick but it's a possibility:

R3 & R4#(config)#router rip(config-router)#redistribute ospf 1 metric 10

By setting the hop count for the redistributed routes into RIP to 10, R2 will prefer the information from R1. This solution doesn't meet our holy redistribution rule and it can be dangerous. When someone increases the hop count on R1 to 11 or higher, we'll have the same problem again.

Still, on a CCIE R&S lab you can expect anything so it's good to understand the different possibilities of fixing a problem. Let's take a look at the next solution which is similar...

Offset-List

In the previous solution we changed the seed metric. What if R3 and R4 are pre-configured routers and outside of our control? When this is the case, we can use an offset-list on R2 to increase the metric:

Here's what the configuration looks like:

R2(config)#ip access-list standard LOOPBACK_R1R2(config-std-nacl)#permit 1.1.1.0 0.0.0.255

First we create an access-list that matches the 1.1.1.0 /24 network. Our next move is to attach it to an offset-list:

R2(config)#router ripR2(config-router)#offset-list LOOPBACK_R1 in 10 FastEthernet0/1

The metric from R1 will now be better than whatever R3 or R4 are offering:


Just like changing the seed metric, this is a fix that could be used when R3 and R4 are outside of our control. Let's check out another solution...

Distribute-list Filtering

To prevent routes from entering the routing table, we can also use a distribute-list. When we get back to the original problem, this is what the routing table of R2 looks like:


Above you can see that R2 accepted the 1.1.1.0 /24 prefix from R3. We can use distribute-lists to block certain routing updates:

Here's how to configure this:

R2(config)#ip access-list standard BLOCK_LOOPBACK_R1R2(config-std-nacl)#deny 1.1.1.0 0.0.0.255R2(config-std-nacl)#permit any

I will use an access-list to filter the prefix but you can use some other options as well:

R2(config-router)#distribute-list ? <1-199> IP access list number <1300-2699> IP expanded access list number

WORD Access-list name gateway Filtering incoming updates based on gateway prefix Filter prefixes in routing updates

Let's attach the access-list to the distribute-list and to the two interfaces pointing to R3 and R4:

R2(config-router)#distribute-list BLOCK_LOOPBACK_R1 in FastEthernet 0/0R2(config-router)#distribute-list BLOCK_LOOPBACK_R1 in FastEthernet 0/1

R2 will now not accept the information from R3 or R4 and as a result, it will use the information from R1:


Problem solved! Just like the seed metric and offset-list solutions, this one doesn't meet our redistribution rule. However, changing the metric on R1 won't accept R2's decisions since it's not accepting 1.1.1.0 /24 from R3 and R4 at all.

I have one more solution for you, the next one is a bit different!

Administrative Distance

Back to the original problem, R2 has an incorrect route again from R3:


We can change the administrative distance for certain prefixes. Let's do this for network 1.1.1.0 /24:

R2(config)#ip access-list standard LOOPBACK_R1R2(config-std-nacl)#permit 1.1.1.0 0.0.0.255

R2(config)#router ripR2(config-router)#distance 255 192.168.23.3 0.0.0.0 LOOPBACK_R1R2(config-router)#distance 255 192.168.24.4 0.0.0.0 LOOPBACK_R1

When R2 receives RIP information about 1.1.1.0 /24 from R3 or R4 then it will set the administrative distance to 255. Setting it to a value of 121 or higher would do the job but setting it to 255 prevents R2 from installing it in its routing table at all.

Here's the end result:


Problem solved! Instead of changing the administrative distance on R2, we can also do this on R3 or R4. Let's get rid of the configuration we just did on R2:

R2(config)#router ripR2(config-router)#no distance 255 192.168.23.3 0.0.0.0 LOOPBACK_R1R2(config-router)#no distance 255 192.168.24.4 0.0.0.0 LOOPBACK_R1

Take a look at R3, this is currently the router that is responsible for redistributing 1.1.1.0 /24 into RIP:

R3#show ip route ospf 1.0.0.0/24 is subnetted, 1 subnetsO E2 1.1.1.0 [110/1] via 192.168.34.4, 00:36:18, FastEthernet0/1

Let's increase the administrative distance for 1.1.1.0 /24 on R3 and R4:

R3 & R4#(config)#ip access-list standard LOOPBACK_R1(config-std-nacl)# permit 1.1.1.0 0.0.0.255

(config)#router ospf 1(config-router)#distance 255 0.0.0.0 255.255.255.255 LOOPBACK_R1

R3 and R4 are now unable to install the 1.1.1.0 /24 OSPF route in their routing tables. They are forced to use the RIP information:

R3#show ip route | incl 1.1.1.0R 1.1.1.0 [120/7] via 192.168.23.2, 00:00:19, FastEthernet0/0R4#show ip route rip | incl 1.1.1.0R 1.1.1.0 [120/7] via 192.168.24.2, 00:00:26, FastEthernet0/0

Above you can see that R3 and R4 are now using the information from RIP. Since they don't have a OSPF entry for this network, they also can't redistribute it into RIP.

The solution above is also the solution to get rid of the sub-optimal routing problem. By changing the administrative distance, R3 and R4 are forced to use the original routing information instead of the redistributed routing information.

This ensures that R2 won't learn it:


Problem solved!

ConclusionRedistribution is a complex topic...keep the redistribution rule in mind that you should never redistribute routing information from routing protocol X into Y and then back into X. When you do face metric-related redistribution issues, you are now able to fix them using a variety of techniques.

In the next lesson we will look at another redistribution problem that is caused by the administrative distance. If you have any questions, feel free to leave a comment!

Troubleshooting AD RedistributionWhen it comes to redistribution, there are a lot of things that potentially could go wrong. Two possible issues are sub-optimal routing and routing loops. All redistribution problems boil down to two different issues: Metric related problems . Administrative distance related problems.If you haven’t seen my first lesson on metric related redistribution problems then I would recommend to start there first. Once you know how to fix metric issues, this lesson will be easier to understand.In this lesson we will take a look at redistribution problems that are caused by the administrative distance. I’ll also show you why this occurs and of course how to fix it!

This is the topology I will use:

Above we have 4 routers, let me explain this topology:

R1 runs RIP and is only used to inject a prefix into the topology (1.1.1.0 /24). R2 runs RIP, OSPF and EIGRP. We will perform redistribution on this router in a bit. R3 runs OSPF and EIGRP, it will also be configured for redistribution. R4 runs only EIGRP.Here’s what the configuration of the routing protocols look like:

R1#show running-config | section riprouter rip version 2 network 1.0.0.0 network 192.168.12.0 no auto-summaryR2#show running-config | section riprouter rip version 2 network 192.168.12.0 no auto-summary

R2#show running-config | section ospfrouter ospf 1 log-adjacency-changes network 192.168.23.0 0.0.0.255 area 0

R2#show running-config | section eigrprouter eigrp 1 network 192.168.24.0 no auto-summaryR3#show running-config | section ospfrouter ospf 1 log-adjacency-changes network 192.168.23.0 0.0.0.255 area 0

R3#show running-config | section eigrprouter eigrp 1 network 192.168.34.0 no auto-summaryR4#show running-config | section eigrprouter eigrp 1 network 192.168.24.0 network 192.168.34.0 no auto-summary

And here’s what the routing tables look like, we haven’t configured redistribution yet:

R2#show ip route

C 192.168.12.0/24 is directly connected, FastEthernet1/0 1.0.0.0/24 is subnetted, 1 subnetsR 1.1.1.0 [120/1] via 192.168.12.1, 00:00:28, FastEthernet1/0C 192.168.24.0/24 is directly connected, FastEthernet0/1C 192.168.23.0/24 is directly connected, FastEthernet0/0D 192.168.34.0/24 [90/307200] via 192.168.24.4, 00:00:33, FastEthernet0/1

R2 learns a prefix from R1 through RIP and it learns about the network in between R3 and R4 (192.168.34.0 /24). Let’s take a look at R3:

R3#show ip route

D 192.168.24.0/24 [90/307200] via 192.168.34.4, 00:01:23, FastEthernet0/1C 192.168.23.0/24 is directly connected, FastEthernet0/0C 192.168.34.0/24 is directly connected, FastEthernet0/1

R3 learns about the network (192.168.24.0 /24) in between R2 and R4 through EIGRP. Let’s check R4:

R4#show ip route

C 192.168.24.0/24 is directly connected, FastEthernet0/0C 192.168.34.0/24 is directly connected, FastEthernet0/1

R4 didn’t learn anything so far. It’s an internal EIGRP router and the only two interfaces that are advertised in EIGRP are directly connected for R4.

Redistribution ConfigurationTo achieve full connectivity, we have to configure redistribution. However, let’s say that we have some requirements…something you could encounter on a CCIE R&S lab exam:

Configure redistribution between RIP and EIGRP on R2 only. Configure redistribution between OSPF and EIGRP on R3 only.

When we configure redistribution like that, we should have full connectivity. Take a look at the diagram below:

Above you can see where we will perform redistribution. Let’s be brainless and configure redistribution without thinking too much about this topology:

R2(config)#router ripR2(config-router)#redistribute eigrp 1 metric 1

R2(config)#router eigrp 1R2(config-router)#redistribute rip metric 1000 100 255 1 1500

R2 is now redistributing between RIP and EIGRP. Let’s configure R3:

R3(config)#router eigrp 1R3(config-router)#redistribute ospf 1 metric 1500 100 255 1 1500

R3(config)#router ospf 1R3(config-router)#redistribute eigrp 1 subnets

Easy enough! Redistribution has been configured so we should have full connectivity right? We should check if everything is reachable…

Reachability Verification

When you configure redistribution and your goal is to have full connectivity then you should try pinging all IP addresses in the topology. A quick method to do this is to fetch all IP addresses using show ip aliases and then use a TCLSH script. Here’s how to do it:

R1#show ip aliasesAddress Type IP Address PortInterface 1.1.1.1Interface 192.168.12.1R2#show ip aliasesAddress Type IP Address PortInterface 192.168.12.2Interface 192.168.23.2Interface 192.168.24.2R3#show ip aliasesAddress Type IP Address PortInterface 192.168.23.3Interface 192.168.34.3R4#show ip aliasesAddress Type IP Address PortInterface 192.168.24.4Interface 192.168.34.4

This gives us a nice overview of all IP addresses. Copy / paste them in notepad and then turn it into a simple TCLSH script, then run it on all routers. To reduce the output, I removed all the succesful pings and only kept the failed pings:

R1(tcl)#foreach address {+>(tcl)#1.1.1.1+>(tcl)#192.168.12.1+>(tcl)#192.168.12.2+>(tcl)#192.168.23.2+>(tcl)#192.168.24.2+>(tcl)#192.168.23.3+>(tcl)#192.168.34.3+>(tcl)#192.168.24.4+>(tcl)#192.168.34.4+>(tcl)#} { ping $address repeat 3 }

Sending 3, 100-byte ICMP Echos to 192.168.23.2, timeout is 2 seconds:...Success rate is 0 percent (0/3)Type escape sequence to abort.Sending 3, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:...

Success rate is 0 percent (0/3)R1(tcl)#

R1 can ping everything with the exception of 192.168.23.2 and 192.168.23.3. That’s the link in between R2 and R3. Let’s make a mental note of this and continue with the other routers:


Type escape sequence to abort.Sending 3, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:...Success rate is 0 percent (0/3)

R2(tcl)#

R2 is able to reach everything with the exception of 1.1.1.1. Make a mental note of this and continue:


Type escape sequence to abort.Sending 3, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:...Success rate is 0 percent (0/3)R3(tcl)#

R3 has the same issue as R2. What about R4?


Type escape sequence to abort.Sending 3, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:...Success rate is 0 percent (0/3)R4(tcl)#

We see that R1 has some issues and that R2, R3 and R4 are unable to reach 1.1.1.1. Let’s focus on these last three routers first.

R2 is learning network 1.1.1.0 /24 directly from R1 through RIP, there’s nothing in between these two routers. Let’s take a quick look at the routing table of R2:

R2#show ip route

C 192.168.12.0/24 is directly connected, FastEthernet1/0C 192.168.24.0/24 is directly connected, FastEthernet0/1C 192.168.23.0/24 is directly connected, FastEthernet0/0D 192.168.34.0/24 [90/307200] via 192.168.24.4, 01:03:07, FastEthernet0/1

Depending on when you check the routing table, you might or might not see an entry for 1.1.1.0 /24. Above you can see that it’s gone…a few seconds later this is what I see:

R2#show ip route

C 192.168.12.0/24 is directly connected, FastEthernet1/0 1.0.0.0/24 is subnetted, 1 subnetsO E2 1.1.1.0 [110/20] via 192.168.23.3, 00:00:02, FastEthernet0/0

C 192.168.24.0/24 is directly connected, FastEthernet0/1C 192.168.23.0/24 is directly connected, FastEthernet0/0D 192.168.34.0/24 [90/307200] via 192.168.24.4, 01:03:45, FastEthernet0/1

Interesting, R2 now has an OSPF entry for network 1.1.1.0 /24. If you would check the routing tables of R3 and R4 you will see 1.1.1.0 /24 appearing and disappearing as well.

It is kinda annoying to check the routing tables of all these routers just to “hunt” for some routes that dissapear like a thief in the night, especially when we have a large topology. There are a couple of useful tools that we can use that help us.

The first one is route profiling. This tells us how often there are changes to the routing table. You have to enable it first before you can look at the results:

R2,R3 & R4#(config)#ip route profile

Let it run for a couple of minutes and you will see results:

R2#show ip route profileIP routing table change statistics:Frequency of changes in a 5 second sampling interval-------------------------------------------------------------Change/ Fwd-path Prefix Nexthop Pathcount Prefixinterval change add change change refresh-------------------------------------------------------------0 975 983 1165 983 11651 16 182 0 182 02 174 0 0 0 03 0 0 0 0 04 0 0 0 0 05 0 0 0 0 0

Route profiling works by checking the routing table with a 5 second interval. The changes to the routing table are categorized in:

Fwd-path change: the number of changes in the forwarding path. This value is an accumulation of prefix-add, next-hop change and pathcount.

Prefix add: new prefix has been added to the routing table. Nexthop change: the next hop of a prefix has changed. Pathcount change: the number of paths in the routing table has changed.

Prefix refresh: this is standard routing table maintenance, prefixes are refreshed every now and then. No changes to the routing table have been made.

The output of route profiling is not very easy to read. Let me explain it:

The column on the left (Change / interval) is the frequency. For example the value of 182 in row 1 means that in 182 intervals, one prefix has been added.

The value of 174 in row 2 means that we had 174 intervals where the forward path changed two times.

The value of 1165 in row 0 means that we had 1165 intervals where the next hop did not change.

If you see a lot of intervals in row 1 or higher then we know something is going on and that the routing table is unstable. Here’s what R3 and R4 look like:

R3#show ip route profileIP routing table change statistics:Frequency of changes in a 5 second sampling interval-------------------------------------------------------------Change/ Fwd-path Prefix Nexthop Pathcount Prefixinterval change add change change refresh-------------------------------------------------------------0 987 987 1170 1170 11701 183 183 0 0 02 0 0 0 0 03 0 0 0 0 04 0 0 0 0 05 0 0 0 0 0R4#show ip route profileIP routing table change statistics:Frequency of changes in a 5 second sampling interval-------------------------------------------------------------Change/ Fwd-path Prefix Nexthop Pathcount Prefixinterval change add change change refresh-------------------------------------------------------------0 837 837 1021 1021 10211 184 184 0 0 02 0 0 0 0 03 0 0 0 0 04 0 0 0 0 05 0 0 0 0 0

Here we see something similar to R2, there have been quite some intervals where one prefix has changed.

Now we know something is going on but we still don’t know what. Enabling a debug will help:

R2, R3 & R4#debug ip routingIP routing debugging is on

Now we can see in real-time what is happening to the routing table. Let’s take a look at R2:

R2#RT: add 1.1.1.0/24 via 192.168.12.1, rip metric [120/1]RT: NET-RED 1.1.1.0/24Periodic IP routing statistics collectionRT: closer admin distance for 1.1.1.0, flushing 1 routesRT: NET-RED 1.1.1.0/24RT: add 1.1.1.0/24 via 192.168.23.3, ospf metric [110/20]RT: NET-RED 1.1.1.0/24Periodic IP routing statistics collectionRT: del 1.1.1.0/24 via 192.168.23.3, ospf metric [110/20]RT: delete subnet route to 1.1.1.0/24RT: NET-RED 1.1.1.0/24RT: delete network route to 1.0.0.0RT: NET-RED 1.0.0.0/8

Take a close look at the output above, this debug gives us a lot of valuable information. Let me describe what is happening to R2:

R2 learns prefix 1.1.1.0 /24 from R1 through RIP and adds it to its routing table. R2 learns prefix 1.1.1.0 /24 from R3 through OSPF. R2 removes the RIP entry for 1.1.1.0 /24 and installs the OSPF entry. R2 deletes the OSPF entry for 1.1.1.0 /24 from the routing table.This is very interesting, I’ll describe in a minute why this is happening…let’s first take a look at R3 and R4:

R3#RT: add 1.1.1.0/24 via 192.168.34.4, eigrp metric [170/2636800]RT: NET-RED 1.1.1.0/24RT: delete route to 1.1.1.0 via 192.168.34.4, eigrp metric [170/2636800]RT: no routes to 1.1.1.0RT: NET-RED 1.1.1.0/24RT: delete subnet route to 1.1.1.0/24RT: NET-RED 1.1.1.0/24RT: delete network route to 1.0.0.0RT: NET-RED 1.0.0.0/8

R3 learns 1.1.1.0 /24 through EIGRP and then deletes this entry from its routing table…interesting, what about R4?

R4#RT: add 1.1.1.0/24 via 192.168.24.2, eigrp metric [170/2611200]RT: NET-RED 1.1.1.0/24RT: delete route to 1.1.1.0 via 192.168.24.2, eigrp metric [170/2611200]RT: no routes to 1.1.1.0RT: NET-RED 1.1.1.0/24RT: delete subnet route to 1.1.1.0/24RT: NET-RED 1.1.1.0/24RT: delete network route to 1.0.0.0RT: NET-RED 1.0.0.0/8

R4 has the same issue, it installs the 1.1.1.0 /24 prefix that it learned from R2 and then deletes it from the routing table. So what exactly is going on here? Let me explain this story step-by-step with some images.

AD Based Redistribution Problem

Let’s describe the problem step-by-step. In the beginning, R2 redistributes network 1.1.1.0 /24 that it has learned from R1 through RIP into EIGRP:

R4 learns the prefix and is now able to advertise it to R3 through EIGRP. R3 will redistribute the prefix into OSPF:

R2 now has a decision to make:

R2 has two sources for 1.1.1.0/24. The correct RIP route from R1 and the incorrect OSPF route from R3. It will select the route from R3 since the AD of OSPF is lower than RIP.

As a result, R2 will remove the RIP entry from its routing table and now it is no longer able to redistribute 1.1.1.0 /24 from RIP into EIGRP:

Since R2 doesn’t have a RIP entry for 1.1.1.0 /24, there’s nothing to redistribute into EIGRP. R4 and R3 will remove their EIGRP entry for 1.1.1.0 /24 from their routing tables and R3 is now unable to redistribute 1.1.1.0 /24 into OSPF:

R2 won’t learn about 1.1.1.0 /24 through OSPF anymore and after a short while, R2 will install the RIP entry for 1.1.1.0 /24 again its routing table and the whole problem repeats itself. This problem that I just described is an administrative distance based redistribution problem. R2 is installing incorrect routing information in its routing table because the administrative distance is lower.Before we start talking about solutions, let me get back to the issue with R1 that was unable to ping 192.168.23.2 and 192.168.23.3.

To understand why this doesn’t work, take a look at the routing table of R2:

R2#show ip route connectedC 192.168.12.0/24 is directly connected, FastEthernet1/0C 192.168.24.0/24 is directly connected, FastEthernet0/1C 192.168.23.0/24 is directly connected, FastEthernet0/0

On R2, network 192.168.23.0 /24 is directly connected and not advertised directly in RIP. It has been advertised in OSPF and R3 redistributes this network into EIGRP so that R4 can learn about it.

R2 however won’t install this in its routing table since it already has an entry (directly connected). Because of this, R1 won’t learn about this network. You could fix this by using a network command or redistribute connected under the RIP process on R2.

Back to our problem with network 1.1.1.0 /24…before we start looking at solutions, let’s think about the “core” issue of our problem.

In our particular scenario, R2 learned network 1.1.1.0 /24 from RIP which has an AD of 120, let’s call this the “internal route“.After redistribution, R2 learns about 1.1.1.0 /24 through OSPF. Let’s call this the “external route”.The problem is that R2 should never accept the external route, it should always prefer the internal route. This is a redistribution rule that you should follow:Redistribution Rule: Always prefer your “internal” routes over “external” routes.

If R2 would prefer it’s internal route from RIP instead of the external route from OSPF then we wouldn’t have any problems. Are there any other scenarios where something like this could occur?

RIP doesn’t have a clue about “internal” and “external” routes, it’s all the same so it’s vulnerable to selecting the wrong route.

OSPF uses the same AD for internal and external routes but it always gives preference to internal routes.

EIGRP uses a different AD for internal and external routes.Whenever your internal route has a higher AD than the external route, you have to be careful! Some examples: The internal route was learned through RIP (AD 120) and the external route is learned

through OSPF (AD 110). The internal route was learned through EIGRP external (AD 170) and the internal route

is learned through RIP (AD 120). The internal route was learned through BGP internal (AD 200) and the internal route is

learned through OSPF (AD 110).Now let’s take a look at some solutions!

SolutionsSince this redistribution problem is related to the administrative distance, our options are limited. Playing with metrics won't help since the AD is the decision maker here. To fix this problem, we have to change the AD

Decrease the AD of the internal route(s)

To comply with our redistribution rule of "preferring the internal route" we have to change the AD on R2. Let's lower the AD of the RIP route:

R2(config)#ip access-list standard R1_LOOPBACKR2(config-std-nacl)#permit 1.1.1.0 0.0.0.255

R2(config)#router ripR2(config-router)#distance 100 0.0.0.0 255.255.255.255 R1_LOOPBACK

This reduces the RIP route for 1.1.1.0 /24 to an AD of 100. Now check the routing table:

R2#show ip route | include 1.1.1.0R 1.1.1.0 [100/1] via 192.168.12.1, 00:00:07, FastEthernet1/0

R2 will now always prefer the internal route from R1. R3 and R4 are now also stable:

R3#show ip route | include 1.1.1.0D EX 1.1.1.0 [170/2636800] via 192.168.34.4, 00:01:09, FastEthernet0/1R4#show ip route | include 1.1.1.0D EX 1.1.1.0 [170/2611200] via 192.168.24.2, 00:01:19, FastEthernet0/0

This is looking good! If you left the debug enabled, you will only see something like this:

R2,R3 & R4#Periodic IP routing statistics collectionPeriodic IP routing statistics collectionPeriodic IP routing statistics collection

There are no changes in the routing tables anymore so this proves that the topology is stable. Problem solved!

After implementing your solution, it's always a good idea to use your TCLSH script again to verify that you have full reachability (if required).

Are there any other methods? Let's continue...

Increase the AD of the external route(s)

Instead of decreasing the AD of the internal RIP routes, we can also increase the AD of the OSPF external routes. The result will be the same.

Let's get rid of that RIP AD:

R2(config)#router ripR2(config-router)#no distance 100 0.0.0.0 255.255.255.255 R1_LOOPBACK

And now we make some changes to OSPF:

R2(config)#router ospf 1R2(config-router)#distance ospf inter-area 110 external 180

We mimic the behavior of EIGRP with this setting. OSPF will now set the AD of all external routes to an AD of 180. This makes it prefer the internal RIP route once again...problem solved!

Are there any other solutions that we can use? There's one more...

Redistribution into OSPF

R2 was able to learn network 1.1.1.0 /24 through OSPF because it didn't advertise this network itself into OSPF. If R2 would then it wouldn't learn 1.1.1.0 /24 from R3.

This solution will work but if this is a CCIE R&B lab you have to be careful not to break any of the requirements. Let me show you this solution anyway.

First let's get rid of the distance command:

R2(config)#router ospf 1R2(config-router)#no distance ospf external 180

Now we redistribute the RIP routes into OSPF:

R2(config)#router ospf 1R2(config-router)#redistribute rip subnets

R2 will now keep using the 1.1.1.0 /24 prefix from RIP. Also:

R3 will use the OSPF ( AD 110) entry for 1.1.1.0 /24 instead of the EIGRP external (AD 170) entry from R4.

R4 will use the EIGRP external entry (AD 170) for 1.1.1.0 /24. R2 and R3 both redistribute 1.1.1.0 /24 into EIGRP, the route that R4 installs depends on the seed metric.

Problem solved!

ConclusionRedistribution is a difficult topic but now you have seen the different problems that can occur. Before you configure redistribution, look at the topology and try to spot what possible issues you might encounter. This makes it a lot easier than just redistributing and solving problems later.

When you face these administrative distance based issues, remember the holy redistribution rule: "always prefer internal route over external routes". The best way to enforce this is by making changes to the administrative distance.

I hope this lesson has been helpful, if you have any questions feel free to leave a comment!

How to configure GRE Tunnel on Cisco IOS Router

Tunneling is a concept where we put ‘packets into packets’ so that they can be transported over certain networks. We also call this encapsulation.A good example is when you have two sites with IPv6 addresses on their LAN but they are only connected to the Internet with IPv4 addresses.Normally it would be impossible for the two IPv6 LANs to reach each other but by using tunneling the two routers will put IPv6 packets into IPv4 packets so that our IPv6 traffic can be routed on the Internet.

Another example is where we have an HQ and a branch site and you want to run a routing protocol like RIP, OSPF or EIGRP between them. We can tunnel these routing protocols so that the HQ and branch router can exchange routing information.

Basically when you configure a tunnel, it’s like you create a point-to-point connection between the two devices. GRE (Generic Routing Encapsulation) is a simple tunneling technique that can do this for us. Let me show you a topology that we will use to demonstrate GRE:

Above we have 3 routers connected to each other. On the left side we have the “HQ” router which is our headquarters. On the right side there is a “Branch” router that is supposed to be a branch office. Both routers are connected to the Internet, in the middle on top there is an ISP router. We can use this topology to simulate two routers that are connected to the Internet. The HQ and Branch router each have a loopback interface that represents the LAN.

Let me show you the basic configuration of these routers so that you can recreate it if you want:

HQ(config)#interface fastEthernet 0/0 HQ(config-if)#ip address 192.168.12.1 255.255.255.0HQ(config-if)#exitHQ(config)#interface loopback0HQ(config-if)#ip address 172.16.1.1 255.255.255.0HQ(config-if)#exitHQ(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2ISP(config)#interface fastEthernet 0/0ISP(config-if)#ip address 192.168.12.2 255.255.255.0ISP(config-if)#exitISP(config)#interface fastEthernet 1/0ISP(config-if)#ip address 192.168.23.2 255.255.255.0Branch(config)#interface fastEthernet 0/0Branch(config-if)#ip address 192.168.23.3 255.255.255.0Branch(config-if)#exitBranch(config)#interface loopback 0Branch(config-if)#ip address 172.16.3.3 255.255.255.0Branch(config-if)#exitBranch(config)#ip route 192.168.12.1 255.255.255.255 192.168.23.2

I created a static route on the HQ and Branch router so that they can reach each other through the ISP router. They will be unable to reach the networks on each others loopback interfaces however. Now let’s create a tunnel:

HQ(config)#interface tunnel 1 HQ(config-if)#tunnel source fastEthernet 0/0HQ(config-if)#tunnel destination 192.168.23.3HQ(config-if)#ip address 192.168.13.1 255.255.255.0Branch(config)#interface tunnel 1Branch(config-if)#tunnel source fastEthernet 0/0Branch(config-if)#tunnel destination 192.168.12.1Branch(config-if)#ip address 192.168.13.3 255.255.255.0

You can pick any number for the tunnel interface that you like. We need to specify a source and destination IP address to build the tunnel and we’ll use the 192.168.13.0 /24 subnet on the tunnel interface. Let’s verify that our tunnel is working:

HQ#show interfaces tunnel 1Tunnel1 is up, line protocol is up Hardware is Tunnel Internet address is 192.168.13.1/24 MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 192.168.12.1 (FastEthernet0/0), destination 192.168.23.3 Tunnel protocol/transport GRE/IPBranch#show interfaces tunnel 1Tunnel1 is up, line protocol is up Hardware is Tunnel Internet address is 192.168.13.3/24 MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 192.168.23.3 (FastEthernet0/0), destination 192.168.12.1 Tunnel protocol/transport GRE/IP

Above you can see that the tunnel interface is up/up on both routers. The default tunneling mode is GRE. Let’s see if both routers can reach each other:

Branch#ping 192.168.13.1


There we go…they can ping each other without any issues! So that wasn’t too bad right? Let’s see if we can enable a routing protocol so that we can advertise the loopback interfaces. I’ll use EIGRP for this:

HQ(config)#router eigrp 13 HQ(config-router)#no auto-summary HQ(config-router)#network 192.168.13.0HQ(config-router)#network 172.16.1.0Branch(config)#router eigrp 13

Branch(config-router)#no auto-summary Branch(config-router)#network 192.168.13.0Branch(config-router)#network 172.16.3.0

I’ll activate EIGRP on the tunnel and loopback interfaces. You will see that both routers establish an EIGRP neighbor adjacency through the tunnel interface. Let’s check the routing tables:

HQ#show ip route eigrp 172.16.0.0/24 is subnetted, 2 subnetsD 172.16.3.0 [90/297372416] via 192.168.13.3, 00:01:31, Tunnel1Branch#show ip route eigrp 172.16.0.0/24 is subnetted, 2 subnetsD 172.16.1.0 [90/297372416] via 192.168.13.1, 00:01:51, Tunnel1

As you can see the two routers learned about each others networks. They will use the tunnel interface to reach each other. Let's do a quick test:

HQ#ping 172.16.3.3 source loopback 0

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:Packet sent with a source address of 172.16.1.1 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms

A quick ping between the loopback interfaces proves that the two "LANs" can reach each other.

Be careful when you run a routing protocol on the tunnel interface as this can cause recursive routing issues. If you don't know what this is, take a look at my recursive routing GRE tunnel lesson.

In case you are curious, let me show you what encapsulated packets look like in wireshark:

Take a close look at the source and destination IP addresses. You can see the packet between 192.168.12.1 and 192.168.23.3 and inside you will find the IP packet between 172.16.1.1 and 172.16.3.3.

Note that GRE does tunneling for us but doesn't encrypt any traffic like a VPN does. IPSEC is one of the protocols that can encrypt the packets within our tunnel.

GRE Tunnel Recursive Routing Error

If you configured GRE tunneling before you might have encountered the following error:

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

What happened is that your router has learned the destination IP address for the tunnel interface through the tunnel itself. As a result it removed the previous entry for the tunnel destination IP address from the routing table. Now the tunnel destination is no longer reachable and it collapses.

Let me demonstrate this to you because it will make a lot more sense…this is the topology that we will use:

Above we have 3 routers and the idea is to have a GRE tunnel between R1 and R3. I will first configure the IP addresses on the interfaces and use RIP so that R1 and R3 can reach each other:

R1(config)#interface fastEthernet 0/0 R1(config-if)#ip address 192.168.12.1 255.255.255.0R1(config-if)#exitR1(config)#interface loopback0R1(config-if)#ip address 1.1.1.1 255.255.255.255R1(config-if)#exitISP(config)#interface fastEthernet 0/0R2(config-if)#ip address 192.168.12.2 255.255.255.0R2(config-if)#exitR2(config)#interface fastEthernet 1/0R2(config-if)#ip address 192.168.23.2 255.255.255.0Branch(config)#interface fastEthernet 0/0R3(config-if)#ip address 192.168.23.3 255.255.255.0R3(config-if)#exitR3(config)#interface loopback 0R3(config-if)#ip address 3.3.3.3 255.255.255.255R3(config-if)#exit

Now let’s configure RIP on all routers:

R1(config)#router ripR1(config-router)#version 2R1(config-router)#no auto-summary R1(config-router)#network 192.168.12.0R1(config-router)#network 1.0.0.0R2(config)#router ripR2(config-router)#version 2R2(config-router)#no auto-summary R2(config-router)#network 192.168.12.0R2(config-router)#network 192.168.23.0R3(config)#router ripR3(config-router)#version 2R3(config-router)#no auto-summary R3(config-router)#network 192.168.23.0R3(config-router)#network 3.0.0.0

The network commands above will ensure that R1 and R3 can reach each other. Now let’s create a tunnel interface between the loopback interfaces of R1 and R3:

R1(config)#interface tunnel 1R1(config-if)#tunnel source loopback0R1(config-if)#ip address 192.168.13.1 255.255.255.0R1(config-if)#tunnel destination 3.3.3.3R3(config)#interface tunnel 1R3(config-if)#tunnel source loopback0R3(config-if)#ip address 192.168.13.3 255.255.255.0R3(config-if)#tunnel destination 1.1.1.1

This will enable the tunnel between R1 and R3’s loopback interfaces. I configured network 192.168.13.0 /24 on the tunnel interface. Before we continue, let me show you the routing tables of R1 and R3:

R1#show ip route rip | include 3.3.3.3R 3.3.3.3 [120/2] via 192.168.12.2, 00:00:24, FastEthernet0/0R3#show ip route rip | include 1.1.1.1R 1.1.1.1 [120/2] via 192.168.23.2, 00:00:17, FastEthernet0/0

Take a good look at the output above. R1 and R3 each have a hop count of 2 to reach each others loopback interface. Now we will enable RIP on the tunnel interface:

R1(config)#router ripR1(config-router)#network 192.168.13.0R3(config)#router ripR3(config-router)#network 192.168.13.0

As soon as we enable RIP on the tunnel interface you’ll see this message on R1 and R3:

%TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

So what is going on here? Before I enabled RIP on the tunnel interface, R1 and R3 learned that they could reach each others loopback interface through R2 with a hop count of 2.

After activating RIP on the tunnel interface, R1 and R3 learn that they can reach each others loopback interface with a hop count of 1. As a result they will install this new information in the routing table and remove the old information. If you are quick you can catch it in the routing table just when the tunnel comes up. Here’s an example of R3:

R3#show ip route rip | include 1.1.1.1R 1.1.1.1 [120/1] via 192.168.13.1, 00:00:02, Tunnel1

Above you can see that R3 wants to reach 1.1.1.1 through the tunnel interface with a hop count of 1. Trying to reach the tunnel destination through the tunnel is a little problematic…it’s a classic chicken and egg problem.

How do we solve this? You need to make sure that the router doesn’t reach the tunnel destination through the tunnel itself. There are a number of options to do this: Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise

it or use route filtering. Make sure the administrative distance of the tunnel destination IP address through the

tunnel is higher (worse) than what you have in the routing table now. Make sure the metric to the tunnel destination IP address through the tunnel is worse

than what you have in the routing table now.I will use one of the techniques to solve the problem in our setup:

R1(config)#router ripR1(config-router)#offset-list 0 in 3 tunnel 1R3(config)#router ripR3(config-router)#offset-list 0 in 3 tunnel 1

An offset-list can be used to change the metric. In the example above I'm configuring RIP so that all networks that it advertises through the tunnel interface will have a hop count of 3.

Since a hop count of 3 through the tunnel is higher (worse) then a hop count of 2 through R2, our routers R1 and R3 will now use the FastEthernet links to reach the tunnel destination IP addresses.

In this example I used RIP but the same problem can happen with other routing protocols like OSPF or EIGRP.

I hope this example helped you to understand solve GRE recursive routing issues. If you have any more questions just leave a comment. If you liked it, please share it!

IP Unnumbered ExplainedIn this tutorial we will take a look at IP unnumbered and how to configure it. First of all…what is IP unnumbered and why do we need it?

On a router each interface requires a unique IP address so it can install an entry in the routing table and process IP packets. IP unnumbered allows you to process IP packets without configuring a unique IP address on an interface, this works by “borrowing” an IP address from another interface.

Why would you want this and not just configure an IP address on the interface? To answer that question we have to dive into the past.

Once upon a time we didn’t have VLSM (Variable Length Subnet Mask) and we used classful routing protocols like RIP version 1 and IGRP (the predecessor of EIGRP). This means that the smallest subnet you could use was a /24. When using public IP addresses this is a huge waste of IP space. Take a look at the picture below:

There are 3 routers connected with each other using point-to-point serial links. We have to use two /24 subnets while we only require 4 IP addresses in total…such a waste!

IP unnumbered was created to solve this problem so you didn’t have to waste entire subnets on point-to-point interfaces. It borrows an IP address from another interface so you don’t have to configure one on the point-to-point interface.

Nowadays we can use VLSM to create /30 subnets so we don’t have to waste many IP addresses. We can also use private range IP addresses (if possible in your network) so we don’t need ip unnumbered as much as in the past. Still it can be useful if you quickly want to setup a point-to-point link without worrying about IP addresses and finding a suitable subnet.

Does this make sense so far? Let’s check out the configuration of IP unnumbered. Here’s a

simple example with one router:

Here’s how to configure IP unnumbered:

R1(config)#interface FastEthernet 0/0R1(config-if)#ip address 192.168.1.1 255.255.255.0

R1(config)#interface Serial 0/0/0R1(config-if)#ip unnumbered FastEthernet 0/0

The serial interface will borrow the IP address of the FastEthernet interface. Both interfaces will use the same IP address as the same time and will function 100%. We can verify this by using the show ip interface brief command:

R1#show ip interface briefInterface IP-Address OK? Method Status ProtocolFastEthernet0/0 192.168.1.1 YES manual up up FastEthernet0/1 unassigned YES unset administratively down down Serial0/0/0 192.168.1.1 YES TFTP down up Serial0/1/0 unassigned YES unset administratively down down

Above you can see that both interfaces are using the same IP address. The serial 0/0/0 interface that is borrowing the IP address is called the “unnumbered interface”.

The interface that you are borrowing the IP address from should be up and running, if not you can’t borrow the IP address. For this reason it’s best to borrow an IP address from a

loopback interface. A loopback interface doesn’t go down unless you use the shutdown command or your router crashes…

Also you can’t use IP unnumbered on multi-access interfaces like a Ethernet interface, only on point-to-point interfaces. Here’s what happens when I configure an IP addres on my serial interface and try to borrow it from my FastEthernet interface:

R1(config-if)#default interface FastEthernet 0/0Interface FastEthernet0/0 set to default configuration

R1(config)#interface Serial 0/0/0 R1(config-if)#ip address 192.168.1.1 255.255.255.0

R1(config)#interface FastEthernet 0/0 R1(config-if)#ip unnumbered Serial 0/0/0Point-to-point (non-multi-access) interfaces only

You can see it fails since the FastEthernet interface is multi-access.

What about routing? are there any problems with IP unnumbered? Not really…let’s look at

an example here:

First we will configure this network where we have an IP address on each interface. I’ll do this so you can see what the routing table looks like normally. Here is the configuration:

R1(config)#interface FastEthernet 0/0R1(config-if)#ip address 192.168.1.1 255.255.255.0

R1(config)#interface Serial 0/0/0R1(config-if)#ip address 192.168.12.1 255.255.255.0R2(config)#interface FastEthernet 0/0R2(config-if)#ip address 192.168.2.2 255.255.255.0

R2(config)#interface Serial 0/0/0R2(config-if)#ip address 192.168.12.2 255.255.255.0

Each interface has an IP address, let’s enable a routing protocol:

R1(config)#router eigrp 12 R1(config-router)#no auto-summary R1(config-router)#network 192.168.12.0R1(config-router)#network 192.168.1.0R2(config)#router eigrp 12R2(config-router)#no auto-summaryR2(config-router)#network 192.168.12.0R2(config-router)#network 192.168.2.0

Now take a look at the routing tables:

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


D 192.168.2.0/24 [90/2172416] via 192.168.12.2, 00:00:42, Serial0/0/0R2#show ip route eigrp

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


D 192.168.1.0/24 [90/2172416] via 192.168.12.1, 00:01:04, Serial0/0/0

This is how it is supposed to be, R1 and R2 learn about each others subnet on the FastEthernet interfaces and they use the IP address of the other side of the point-to-point link as the next hop IP address. Now let's remove the IP addresses on the serial interfaces and use IP unnumbered to borrow the IP address from the FastEthernet interfaces:

Let's look at the configuration:

R1(config)#interface Serial 0/0/0R1(config-if)#ip unnumbered FastEthernet 0/0R2(config)#interface Serial 0/0/0R2(config-if)#ip unnumbered FastEthernet 0/0

Take a look at the routing table now:

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


D 192.168.2.0/24 [90/2172416] via 192.168.2.2, 00:01:34, Serial0/0/0R2#show ip route eigrp Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP + - replicated route, % - next hop override


D 192.168.1.0/24 [90/2172416] via 192.168.1.1, 00:02:09, Serial0/0/0

This is working fine, no problem at all. You can see each router installs an entry for the subnet on the FastEthernet interface of the other side. The next hop IP address is the borrowed IP address of the other side.

That's all I have for now, I hope this helps to understand IP unnumbered. If you have any questions, feel free to leave a comment!

MTU Troubleshooting on Cisco IOSMaximum Transmission Unit (MTU) is the largest size in bytes that a certain layer can forward. The MTU is different for each protocol and medium that we use. Ethernet for example has a MTU of 1500 bytes by default.

This means that a single Ethernet frame can carry up to 1500 bytes of data. On top of this data we add the Ethernet header. Typical header sizes are 14 bytes for Ethernet (add another 4 bytes if you use 802.1Q tagging).

The typical Ethernet header is 14 bytes, IP is 20 bytes and TCP is also 20 bytes. The maximum amount of payload that TCP can use is called the TCP MSS (Maximum Segment Size). This MSS value is the largest amount of data that a host can receive in a single TCP segment. This value is used to set a limit on the payload in order to prevent fragmentation and is sent in the SYN packet during the 3 way handshake. The MSS value isn’t synchronized between hosts, it can be different for each direction.So why is all of this important to know? Let’s imagine we have an IP packet that is sent on our LAN. The size of the of the Ethernet frame will be like this:

1460 bytes of payload for TCP. 20 bytes for the TCP header. 20 bytes for the IP header. 14 bytes for the Ethernet header.

1460 (PAYLOAD) + 20 (TCP) + 20 (IP) = 1500 bytes + 14 (ETHERNET) = 1514 bytes in total.

Sending 1514 bytes is no problem for Ethernet but some other mediums might have issues with large MTU values. Often problems arise when you add additional headers because of PPPoE, GRE Tunneling or IPSEC since this reduces the available bytes for our MTU. To demonstrate this problem (and how to solve it!) I will use a simple network with a reduced MTU. Here’s what it looks like:

The network above has two routers, a webserver (S1) behind R1 and a client (H1) behind R2. Here’s what the configuration looks like:

ConfigurationFirst we’ll configure some IP addresses:

R1(config)#interface fastEthernet 0/0R1(config-if)#ip address 192.168.12.1 255.255.255.0

R1(config)#interface fastEthernet 0/1 R1(config-if)#ip address 192.168.1.254 255.255.255.0R2(config)#interface fastEthernet 0/0R2(config-if)#ip address 192.168.12.2 255.255.255.0

R2(config)#interface fastEthernet 0/1R2(config-if)#ip address 192.168.2.254 255.255.255.0

I’ll add some static routes for connectivity:


Here’s what the default MTU values look like:

R2#show interfaces fastEthernet 0/0 | include MTU MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

R2#show ip interface fastEthernet 0/0 | include MTU MTU is 1500 bytes

The first MTU value is the interface MTU, it’s 1500 bytes by default for Ethernet. The second one is the IP MTU which is also 1500 bytes. Once you get above 1500 bytes your router will start fragmenting the IP packets.Is this limit of 1500 bytes really working? There’s an easy way to find out. Let’s do a ping with the DF-bit (Don’t Fragment) between the routers:

R2#pingProtocol [ip]: Target IP address: 192.168.12.1Repeat count [5]: 1Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: ySource address or interface: Type of service [0]:

Set DF bit in IP header? [no]: yValidate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: vLoose, Strict, Record, Timestamp, Verbose[V]: Sweep range of sizes [n]: ySweep min size [36]: 1495Sweep max size [18024]: 1505Sweep interval [1]: Type escape sequence to abort.Sending 11, [1495..1505]-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:Packet sent with the DF bit setReply to request 0 (1 ms) (size 1495)Reply to request 1 (4 ms) (size 1496)Reply to request 2 (1 ms) (size 1497)Reply to request 3 (4 ms) (size 1498)Reply to request 4 (1 ms) (size 1499)Reply to request 5 (4 ms) (size 1500)Request 6 timed out (size 1501)Request 7 timed out (size 1502)Request 8 timed out (size 1503)Request 9 timed out (size 1504)Request 10 timed out (size 1505)Success rate is 54 percent (6/11), round-trip min/avg/max = 1/2/4 ms

In the ping above you can see that the largest packet that I can send is 1500 bytes. The second packet with 1501 bytes can’t be sent because it is too large and we set the DF-bit.

Let’s look at an actual packet between the client and the webserver, see what these values look like in an actual frame:

Above you can see the TCP MSS which is 1460 bytes. What else can we see in Wireshark?

Above you see that the total length of the IP packet is 1500 bytes (1460 bytes for TCP MSS + 40 bytes for the TCP/IP header). Ethernet adds another 14 bytes which is how we get to 1514 bytes in total.

To simulate a network with a lower MTU I will reduce the MTU of the FastEthernet 0/0 interface of R2:

R2(config)#interface fastEthernet 0/0R2(config-if)#mtu 1400

By reducing the MTU to 1400 bytes, the largest TCP segment size will be only 1360 bytes (1400 – 40 = 1360). This is a scenario where users often complain that sending a ping is no problem but accessing a website or something else doesn’t work. Why? Let’s look at the example below:

Above you see a ping between the client and webserver. As you can see the total length is only 74 bytes…no problem to send this because our MTU allows 1400 bytes. Now we will try to connect to the webserver from the client using HTTP:

This is where things go wrong…as you can see above the total length of the IP Packet is 1500 bytes which is 100 bytes above our MTU of 1400 bytes. It’s impossible to communicate between the client and webserver now.

How do we fix this? There are two solutions for this:

Set the correct IP MTU value so the router knows when to fragment IP packets. Reduce the TCP MSS value for outgoing connections so there is less payload.Here’s how to configure the correct IP MTU value:

R2(config)#interface fastEthernet 0/0R2(config-if)#ip mtu 1400

This tells the router to fragment all outgoing IP packets when they exceed 1400 bytes. The second step is to tell the router to intercept all TCP SYN packets from hosts and change the MSS value. We do this on the interface that is facing our hosts:

R2(config)#interface fastEthernet 0/1R2(config-if)#ip tcp adjust-mss 1360

Setting the TCP MSS value to 1360 ensures that our total MTU will be 1400 bytes (1360 + 40). Does this work? Let's look at a Wireshark example between our host and webserver again:

Above you can see that the maximum segment size is now 1360 bytes. What about the total packet length? Look below...

With a TCP MSS of 1360 our IP packet is only 1400 bytes which is exactly our MTU of 1400 bytes. You will notice that all communication problems between the host and webserver are now solved.

The IP tcp adjust-mss command is to intercept TCP SYN packets from hosts and set the correct MSS value, if you want to change the MSS for TCP connections that are originated by the router you need to use another command:

R2(config)#ip tcp mss 1360

The ip tcp mss command changes the MSS for the router itself. We can do a debug to check if it's working or not:

R2#debug ip tcp transactions TCP special event debugging is on

Let's use telnet to connect to TCP port 80 to the webserver:

R2#telnet 192.168.1.1 80Trying 192.168.1.1, 80 ... Open

TCB495B8B94 createdTCB495B8B94 setting property TCP_VRFTABLEID (20) 496CF85C

TCB495B8B94 setting property TCP_TOS (11) 496CF7F8TCB495B8B94 setting property TCP_RTRANSTMO (31) 496CF728TCB495B8B94 setting property TCP_GIVEUP (34) 496CF72CTCP: Random local port generated 36352, network 1TCB495B8B94 bound to UNKNOWN.36352TCB495B8B94 setting property unknown (24) 496CF758Reserved port 36352 in Transport Port Agent for TCP IP type 1TCP: sending SYN, seq 3882550463, ack 0TCP0: Connection to 192.168.1.1:80, advertising MSS 1360TCP0: state was CLOSED -> SYNSENT [36352 -> 192.168.1.1(80)]TCP0: state was SYNSENT -> ESTAB [36352 -> 192.168.1.1(80)]TCP: tcb 495B8B94 connection to 192.168.1.1:80, peer MSS 1460, MSS is 1360

You can see that R2 is using a MSS value of 1360 now...problem solved.

Introduction to PPP on Cisco IOS RouterPPP is one of the WAN protocols that you can configure on Cisco IOS routers. We will take a look how PPP works and how to configure it. Do you still remember how the OSI model works?

PPP operates on the data link layer (layer 2) but as you can see the data link layer has been split into two pieces:

NCP: Network Control Protocol LCP: Link Control ProtocolLet’s start with LCP:

LCP takes care of setting up the link. If you enable authentication for PPP it will take care of authentication. Once the link has been setup we use NCP.

NCP will make sure you can run different protocols over our PPP link like IP, IPv6 but also CDP (Cisco Discovery Protocol) and older protocols like IPX or AppleTalk.

So in short if you enable PPP on both routers this is what happens:

1. LCP: Takes care of setting up the link.2. (Optional): Authentication.3. NCP: Makes sure we can send IP and other protocols across our PPP link.Let’s see what authentication is about:

I have two routers; the router on the left side is called R1. If you want to use authentication for PPP you have two options:

PAP (Password Authentication Protocol): This is plaintext! It will send the username and password over the PPP link and the router on the other side will check it.

CHAP (Challenge Authentication Protocol): Instead of sending the password in plaintext we are going to send a “challenge” which is a hash of the password. This is far more secure.

In the example above we are using PAP:

On the left side we have a router with hostname R1. On the right side we have a router without a hostname but it has the username R1 and password

VIDEO configured in a local database. PPP will start setting up the link by using LCP. Since authentication is enabled our router on the right side will authenticate R1:

o R1 will send its hostname and the password in plaintext.o The router on the right side will accept or deny the credentials.o If everything is ok PPP will work and we are authenticated.

PAP is very simple but sending a username and password in plaintext is not a very secure method. Let’s see how CHAP works:

Once you enable Chap authentication the router will send a challenge. Above you see R1 sending a challenge towards R2.

Instead of just sending a password in plaintext R2 will send a hash. This is far more secure.

If the hash is ok R1 will let R2 know everything is as it should be and our PPP link is working.

Keep in mind authentication is ONLY about checking the username and password, it doesn’t have anything to do with encryption. All traffic sent on this PPP connection is in cleartext, if you want encryption you need to use a VPN.

Let’s see what PPP looks like on some real routers. I'll use the two routers I just showed you:

I’m using two routers connected to each other with a serial link. Don't forget that for serial interfaces the DCE side has to configure a clock rate:

R1(config)#interface serial 0/0R1(config-if)#clock rate 64000

For this lab it doesn't matter what clock rate I use, as long as the link is working.

R2#show controllers serial 0/0Hardware is PowerQUICC MPC860DTE V.35 TX and RX clocks detectedIdb at 0x81081AC4, driver data structure at 0x 81084AC0

In the example above R2 is the DTE side and it has received the clock rate. Show controllers is excellent because it will show you which side is DTE or DCE.Let’s configure the IP addresses:

R1(config)#interface serial 0/0R1(config-if)#ip address 192.168.12.1 255.255.255.0R2(config)#interface serial 0/0R2(config-if)#ip address 192.168.12.2 255.255.255.0

Nothing special so far, just two serial interfaces in the same subnet.

We can verify the default encapsulation type for serial interfaces:

R1#show interfaces serial 0/0Serial0/0 is up, line protocol is up Hardware is M4T Internet address is 192.168.12.1/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, crc 16, loopback not setR2#show interfaces serial 0/0Serial0/0 is up, line protocol is up Hardware is M4T Internet address is 192.168.12.2/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, crc 16, loopback not set

Use the show interfaces command to check the encapsulation type. As you can see HDLC is the default so let's change it to PPP:

R1(config)#interface serial 0/0R1(config-if)#encapsulation pppR2(config)#interface serial 0/0 R2(config-if)#encapsulation ppp

Use the encapsulation ppp command to change the serial interface to PPP (remember that HDLC is the default). Let’s configure an IP address on the interfaces:

R1(config)#interface serial 0/0R1(config-if)#ip address 192.168.12.1 255.255.255.0R2(config)#interface serial 0/0R2(config-if)#ip address 192.168.12.2 255.255.255.0

Now before I type “no shutdown” I will enable a debug so you can see the LCP building the link:

R2#debug ppp negotiation PPP protocol negotiation debugging is on

The debug ppp negotiation command will show you how the PPP link is established. Let’s activate the interfaces:

R1(config)#interface serial 0/0R1(config-if)#no shutdownR2(config)#interface serial 0/0R2(config-if)#no shutdown

No shutdown will activate our interfaces, and this is what you will see if you enabled the debug:

R2#%LINK-3-UPDOWN: Interface Serial0/0, changed state to upSe0/0 PPP: Using default call directionSe0/0 PPP: Treating connection as a dedicated lineSe0/0 PPP: Session handle[9C000002] Session id[2]Se0/0 PPP: Phase is ESTABLISHING, Active OpenSe0/0 LCP: O CONFREQ [Closed] id 4 len 10Se0/0 LCP: MagicNumber 0x0045BF0E (0x05060045BF0E)Se0/0 LCP: I CONFREQ [REQsent] id 136 len 10Se0/0 LCP: MagicNumber 0x004598FC (0x0506004598FC)Se0/0 LCP: O CONFACK [REQsent] id 136 len 10Se0/0 LCP: MagicNumber 0x004598FC (0x0506004598FC)Se0/0 LCP: I CONFACK [ACKsent] id 4 len 10Se0/0 LCP: MagicNumber 0x0045BF0E (0x05060045BF0E)Se0/0 LCP: State is OpenSe0/0 PPP: Phase is FORWARDING, Attempting ForwardSe0/0 PPP: Phase is ESTABLISHING, Finish LCPSe0/0 PPP: Phase is UPSe0/0 IPCP: O CONFREQ [Closed] id 1 len 10Se0/0 IPCP: Address 192.168.12.2 (0x0306C0A80C02)Se0/0 CDPCP: O CONFREQ [Closed] id 1 len 4

Se0/0 PPP: Process pending ncp packetsSe0/0 CDPCP: I CONFR2#REQ [REQsent] id 1 len 4Se0/0 CDPCP: O CONFACK [REQsent] id 1 len 4Se0/0 IPCP: I CONFREQ [REQsent] id 1 len 10Se0/0 IPCP: Address 192.168.12.1 (0x0306C0A80C01)Se0/0 IPCP: O CONFACK [REQsent] id 1 len 10Se0/0 IPCP: Address 192.168.12.1 (0x0306C0A80C01)Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10Se0/0 IPCP: Address 192.168.12.2 (0x0306C0A80C02)Se0/0 IPCP: State is OpenSe0/0 CDPCP: I CONFACK [ACKsent] id 1 len 4Se0/0 CDPCP: State is OpenSe0/0 IPCP: Install route to 192.168.12.1R2#%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up

Above you first see first the “LCP” messages that are setting up the link. Once LCP is done you see “IPCP” and “CDPCP” messages. This is NCP making sure that we can send IP and CDP traffic over our PPP link. CDP (Cisco Discovery Protocol) is used to detect other Cisco devices on our network.

Let’s see if there is connectivity between the routers:

R1#ping 192.168.12.2


A quick ping proves that PPP is working.

Let’s disable debug before we continue:

R2#no debug all All possible debugging has been turned off

Let’s see if we can enable authentication for PPP, I’ll show you how to use CHAP:

R1(config)#username R2 password MYSECRETR2(config)#username R1 password MYSECRET

First we’ll configure the username and password. The username is the hostname of the router on the other side. Of course the password has to be the same.

R1(config)#interface serial 0/0R1(config-if)#ppp authentication chapR2(config)#interface serial 0/0R2(config-if)#ppp authentication chap

Use ppp authentication chap command to enable CHAP authentication. If I enable it on both routers then they will authenticate each other. It’s also possible to configure this only on one of the routers. Let me show you what I mean:

R1#debug ppp authentication PPP authentication debugging is on

You can enable debugging for PPP authentication, this way we can see what is going on:

R1(config)#interface serial 0/0R1(config-if)#shutdownR1(config-if)#no shutdown

A quick shutdown and no shutdown will make sure that our routers have to reconnect and reauthenticate.

R1#Se0/0 PPP: Using default call directionSe0/0 PPP: Treating connection as a dedicated lineSe0/0 PPP: Session handle[C2000009] Session id[33]Se0/0 PPP: Authorization required%LINK-3-UPDOWN: Interface Serial0/0, changed state to upSe0/0 CHAP: O CHALLENGE id 32 len 29 from "R1"Se0/0 CHAP: I CHALLENGE id 3 len 26 from "R2"Se0/0 CHAP: I RESPONSE id 32 len 26 from "R2"Se0/0 PPP: Sent CHAP LOGIN RequestSe0/0 CHAP: Using hostname from unknown sourceSe0/0 CHAP: Using password from AAASe0/0 CHAP: O RESPONSE id 3 len 29 from "R1"

Se0/0 PPP: Received LOGIN Response PASSSe0/0 PPP: Sent LCP AUTHOR RequestSe0/0 PPP: Sent IPCP AUTHOR RequestSe0/0 LCP: Received AAA AUTHOR Response PASSSe0/0 IPCP: Received AAA AUTHOR Response PASSSe0/0 CHAP: O SUCCESS id 32 len 4Se0/0 CHAP: I SUCCESS id 3 len 4Se0/0 PPP: Sent CDPCP AUTHOR RequestSe0/0 CDPCP: Received AAA AUTHOR Response PASS

Above you see an “O” that stands for outgoing and the “I” for incoming. Our router sends a challenge, receives a response and sends a success message. It also receives a challenge from R2, sends a response and receives a success message.

That’s all I wanted to share about PPP for now. I hope you enjoyed this lesson, feel free to ask any questions that you might have!

Cisco PPPoE Server Configuration ExamplePPPoE allows us to configure PPP over an Ethernet link, it’s not very difficult to configure but when you try to lookup the commands in the Cisco support section you’ll have to browse quite a bit to find the different commands. This tutorial shows you the minimum number of commands required to configure PPPoE. I’ll be using two routers

for this:

We only need two routers…a client and a server, let’s configure the server first.

ServerPPPoE requires a BBA (BroadBand Access) group which is where you can configure session limitations per client and such:

Server(config)#bba-group pppoe globalServer(config-bba-group)#virtual-template 1

I’m not going to configure any session limitations but I do have to refer to a virtual-template. This is where we configure the IP address and some other settings:

Server(config)#interface virtual-template 1Server(config-if)#ip address 192.168.12.2 255.255.255.0Server(config-if)#mtu 1492Server(config-if)#peer default ip address pool CLIENT

This is where we configure the IP address for the server and we also have to set the MTU here. Since PPPoE adds another header (8 bytes) we have to reduce the MTU size to 1492. Last but not least we can define what IP address the client will receive. I’m using a simple pool called “CLIENT” for this, here’s what it looks like:

Server(config)#ip local pool CLIENT 192.168.12.1

Whenever the client connects it will receive IP address 192.168.12.1. You can also use DHCP if you want some more options. Let’s activate the BBA group on the interface:

Server(config)#interface FastEthernet 0/0Server(config-if)#pppoe enable group global

That's all you have to do on the server. Let's look at the client.

ClientThe configuration on the client side is a bit different, it requires a dialer interface:

Client(config)#interface dialer 1Client(config-if)#mtu 1492Client(config-if)#encapsulation pppClient(config-if)#ip address negotiatedClient(config-if)#dialer persistentClient(config-if)#dialer pool 1

Just like the server we set the MTU to 1492 and the IP address is negotiated since we receive it from the server. The dialer persistent command ensures that our dialer always stays up. The dialer interface refers to a pool number., we'll need it for the next part:

Client(config)#interface FastEthernet 0/0Client(config-if)#pppoe-client dial-pool-number 1

On the FastEthernet interface we use the pppoe-client command to refer to the pool number. That's all there is to it, so let's find out if everything is working...

VerificationTo see what is going on we'll enable a debug on the client and server:

Client#debug ppp negotiationPPP protocol negotiation debugging is onServer#debug ppp negotiationPPP protocol negotiation debugging is on

To see the entire PPP session being established we will shut and no shut the dialer interface:

Client(config)#interface Dialer 1Client(config-if)#shutdownClient(config-if)#no shutdown

Here's the debug output of the client:

Client#%LINK-3-UPDOWN: Interface Dialer1, changed state to up%DIALER-6-BIND: Interface Vi1 bound to profile Di1Vi1 PPP: Phase is DOWN, SetupVi1 PPP: Using dialer call directionVi1 PPP: Treating connection as a calloutVi1 PPP: Session handle[3900000A] Session id[0]Vi1 PPP: Phase is ESTABLISHING, Active OpenVi1 PPP: No remote authentication for call-outVi1 LCP: O CONFREQ [Closed] id 1 len 14Vi1 LCP: MRU 1492 (0x010405D4)Vi1 LCP: MagicNumber 0x0228A020 (0x05060228A020)%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to upVi1 LCP: I CONFREQ [REQsent] id 1 len 14Vi1 LCP: MRU 1492 (0x010405D4)Vi1 LCP: MagicNumber 0x03289B2C (0x050603289B2C)Vi1 LCP: O CONFACK [REQsent] id 1 len 14Vi1 LCP: MRU 1492 (0x010405D4)Vi1 LCP: MagicNumber 0x03289B2C (0x050603289B2C)Vi1 LCP: I CONFACK [ACKsent] id 1 len 14Vi1 LCP: MRU 1492 (0x010405D4)Vi1 LCP: MagicNumber 0x0228A020 (0x05060228A020)Vi1 LCP: State is OpenVi1 PPP: Phase is FORWARDING, Attempting ForwardVi1 PPP: Phase is ESTABLISHING, Finish LCPVi1 PPP: Phase is UPVi1 IPCP: O CONFREQ [Closed] id 1 len 10Vi1 IPCP: Address 0.0.0.0 (0x030600000000)Vi1 CDPCP: O CONFREQ [Closed] id 1 len 4Vi1 PPP: Process pending ncp packetsVi1 IPCP: I CONFREQ [REQsent] id 1 len 10Vi1 IPCP: Address 192.168.12.2 (0x0306C0A80C02)Vi1 IPCP: O CONFACK [REQsent] id 1 len 10Vi1 IPCP: Address 192.168.12.2 (0x0306C0A80C02)Vi1 IPCP: I CONFNAK [ACKsent] id 1 len 10Vi1 IPCP: Address 192.168.12.1 (0x0306C0A80C01)Vi1 IPCP: O CONFREQ [ACKsent] id 2 len 10Vi1 IPCP: Address 192.168.12.1 (0x0306C0A80C01)Vi1 IPCP: I CONFACK [ACKsent] id 2 len 10Vi1 IPCP: Address 192.168.12.1 (0x0306C0A80C01)Vi1 IPCP: State is Open

Di1 IPCP: Install negotiated IP interface address 192.168.12.1Di1 IPCP: Install route to 192.168.12.2Vi1 IPCP: Add link info for cef entry 192.168.12.2%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

Great! The client has established a connection and received its IP address. What does the server look like?

Server#ppp3 PPP: Send Message[Dynamic Bind Response]ppp3 PPP: Using vpn set call directionppp3 PPP: Treating connection as a callinppp3 PPP: Session handle[E7000005] Session id[3]ppp3 PPP: Phase is ESTABLISHING, Passive Openppp3 LCP: State is Listenppp3 LCP: I CONFREQ [Listen] id 1 len 14ppp3 LCP: MRU 1492 (0x010405D4)ppp3 LCP: MagicNumber 0x0228A020 (0x05060228A020)ppp3 PPP: No remote authentication for call-inppp3 LCP: O CONFREQ [Listen] id 1 len 14ppp3 LCP: MRU 1492 (0x010405D4)ppp3 LCP: MagicNumber 0x03289B2C (0x050603289B2C)ppp3 LCP: O CONFACK [Listen] id 1 len 14ppp3 LCP: MRU 1492 (0x010405D4)ppp3 LCP: MagicNumber 0x0228A020 (0x05060228A020)ppp3 LCP: I CONFACK [ACKsent] id 1 len 14ppp3 LCP: MRU 1492 (0x010405D4)ppp3 LCP: MagicNumber 0x03289B2C (0x050603289B2C)ppp3 LCP: State is Openppp3 PPP: Phase is FORWARDING, Attempting Forwardppp3 PPP: Send Message[Connect Local]ppp3 PPP: Queue IPCP code[1] id[1]ppp3 PPP: Discarded CDPCP code[1] id[1]ppp3 PPP: Bind to [Virtual-Access1.1]Vi1.1 PPP: Send Message[Static Bind Response]Vi1.1 PPP: Phase is ESTABLISHING, Finish LCPVi1.1 PPP: Phase is UPVi1.1 IPCP: O CONFREQ [Closed] id 1 len 10Vi1.1 IPCP: Address 192.168.12.2 (0x0306C0A80C02)Vi1.1 PPP: Process pending ncp packetsVi1.1 IPCP: Redirect packet to Vi1.1Vi1.1 IPCP: I CONFREQ [REQsent] id 1 len 10Vi1.1 IPCP: Address 0.0.0.0 (0x030600000000)Vi1.1 IPCP: Pool returned 192.168.12.1Vi1.1 IPCP: O CONFNAK [REQsent] id 1 len 10

Vi1.1 IPCP: Address 192.168.12.1 (0x0306C0A80C01)Vi1.1 IPCP: I CONFACK [REQsent] id 1 len 10Vi1.1 IPCP: Address 192.168.12.2 (0x0306C0A80C02)Vi1.1 IPCP: I CONFREQ [ACKrcvd] id 2 len 10Vi1.1 IPCP: Address 192.168.12.1 (0x0306C0A80C01)Vi1.1 IPCP: O CONFACK [ACKrcvd] id 2 len 10Vi1.1 IPCP: Address 192.168.12.1 (0x0306C0A80C01)Vi1.1 IPCP: State is OpenVi1.1 IPCP: Install route to 192.168.12.1

You can see that server checks its pool and decides to give IP address 192.168.12.1 to the client. Let's do a quick check on the client just to be sure everything is working:

Client#ping 192.168.12.2


We have connectivity! Hopefully this example has been helpful to you!

Proxy ARP ExplainedMost networking students are familiar with ARP (Address Resolution Protocol) but Proxy ARP doesn’t always ring a bell. In this tutorial I will explain how proxy ARP works, we’ll use the following topology for this:

In the example above we have two subnets: 10.1.1.0 /24 and 10.2.2.0 /24. The router in the middle is connected to both subnets. On the bottom you see two hosts (H1 and H2) and on top we have a server (S1).

When you take a close look at the hosts you can see that H1 has a /24 subnet mask and H2 has a /8 subnet mask. When H1 tries to reach the server at 10.2.2.100 the following will happen:

1. H1 compares its IP address and subnet mask to the IP address of the server (10.2.2.100) and decides that the server is in another subnet.

2. H1 decides to send the packet for the server to its default gateway (10.1.1.254).3. H1 checks its ARP table to see if there is an entry for 10.1.1.254, if not it will send an

ARP request.4. The router will respond to the ARP request, sending its MAC address of its FastEthernet

0/0 interface.This is how ARP works normally, when H2 tries to send an IP packet towards the server something else will happen:

1. H2 compares its IP address and subnet mask to the IP address of the server (10.2.2.100) and decides that the server is in the same subnet.

2. H2 checks its ARP table to see if there is an entry for 10.2.2.100, if not it will send an ARP request.

The server however is not on the 10.1.1.0 /24 subnet and routers do not forward broadcast traffic so the ARP request never makes it to the server. All hope is not lost however….this is where proxy ARP comes to the rescue!

When proxy ARP is enabled on the router, this is what happens:

1. The router sees the ARP request from H2 on the 10.1.1.0 /24 subnet and sees that this is an ARP request for something in the 10.2.2.0 /24 subnet.

2. The router realizes that it knows how to reach the 10.2.2.0 /24 subnet and decides to respond to the ARP request in order to help H2.

3. The router sends an ARP reply to H2 with its MAC address on the FastEthernet 0/0 interface.

Are you following me so far? Let me show you what this looks like on a real router.

Configuration

I will use the following topology to demonstrate proxy ARP:

It’s the same as the picture as I just showed you but I am using the routers in my lab. By disabling “ip routing” I can turn the routers into ordinary host devices. Let’s start by disabling routing on R1, R2 and the server:

H1, H2 & S1(config)#no ip routing

Let’s configure the default gateway on those devices:

H1 & H2(config)#ip default-gateway 10.1.1.254S1(config)#ip default-gateway 10.2.2.254

Let’s configure all the IP addresses that we require:

H1(config)#interface fastEthernet 0/0H1(config-if)#ip address 10.1.1.1 255.255.255.0H2(config)#interface fastEthernet 0/0H2(config-if)#ip address 10.1.1.2 255.0.0.0S1(config)#interface FastEthernet 0/0S1(config-if)#ip address 10.2.2.100 255.255.255.0

Note that I used the /8 subnet mask on H2 here. Here’s the router:

R1(config)#interface FastEthernet 0/0R1(config-if)#ip address 10.1.1.254 255.255.255.0R1(config-if)#interface FastEthernet 0/1R1(config-if)#ip address 10.2.2.254 255.255.255.0

That’s all we have to configure…let’s verify our work!

VerificationTo test proxy ARP I will first send some traffic from H1 to the server so you can see what normal ARP looks like, and then we will send some traffic from H2 to the server.

Proxy ARP is enabled by default as you can see here:

R1#show ip interface FastEthernet 0/0 | include Proxy

Proxy ARP is enabled

To see in realtime what is going on, I will use the following debug on R1:

R1#debug arpARP packet debugging is on

Let’s send some pings from host A to the server:

H1#ping 10.2.2.100

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.2.2.100, timeout is 2 seconds:.!!!!Success rate is 80 percent (4/5), round-trip min/avg/max = 44/311/1068 ms

The ping is working, the first one failes because of some ARPs, you can see them in the debug below:

R1#IP ARP: rcvd req src 10.1.1.1 c204.07ec.0000, dst 10.1.1.254 FastEthernet0/0IP ARP: sent rep src 10.1.1.254 c206.13b8.0000, dst 10.1.1.1 c204.07ec.0000 FastEthernet0/0

R1 receives an ARP request from H1 who is looking for the IP address of its default gateway and replies with its MAC address.

R1#IP ARP: creating incomplete entry for IP address: 10.2.2.100 interface FastEthernet0/1IP ARP: sent req src 10.2.2.254 c206.13b8.0001, dst 10.2.2.100 0000.0000.0000 FastEthernet0/1IP ARP: rcvd rep src 10.2.2.100 c207.13b8.0000, dst 10.2.2.254 FastEthernet0/1

Before R1 can deliver the packet to the server it has to know the MAC address of the server, so R1 does an ARP request and receives a reply from the server.

R1#

IP ARP: rcvd req src 10.2.2.100 c207.13b8.0000, dst 10.2.2.254 FastEthernet0/1IP ARP: sent rep src 10.2.2.254 c206.13b8.0001, dst 10.2.2.100 c207.13b8.0000 FastEthernet0/1

R1 also receives an ARP request from the server who is looking for the MAC address of its default gateway, a reply is sent with the MAC address of FastEthernet 0/1. Here's what the ARP table of H1 looks like now:

H1#show ip arpProtocol Address Age (min) Hardware Addr Type InterfaceInternet 10.1.1.1 - c204.07ec.0000 ARPA FastEthernet0/0Internet 10.1.1.254 3 c206.13b8.0000 ARPA FastEthernet0/0

H1 has saved the MAC address of its default gateway in the ARP table. What you have seen so far is just regular ARP.

Now we'll see how proxy ARP works by looking at H2. To see the logic of H2 in action I will enable ARP debugging:

H2#debug arpARP packet debugging is on

Let's ping the server:

H2#ping 10.2.2.100


Our ping is working and here's the debug of H2:

H2#IP ARP: creating incomplete entry for IP address: 10.2.2.100 interface FastEthernet0/0

IP ARP: sent req src 10.1.1.2 c205.07ec.0000, dst 10.2.2.100 0000.0000.0000 FastEthernet0/0IP ARP: rcvd rep src 10.2.2.100 c206.13b8.0000, dst 10.1.1.2 FastEthernet0/0

H2 sends an ARP request, looking for 10.2.2.100 and receives an ARP reply. Here's what you will see on R1:

R1#IP ARP: rcvd req src 10.1.1.2 c205.07ec.0000, dst 10.2.2.100 FastEthernet0/0IP ARP: creating entry for IP address: 10.1.1.2, hw: c205.07ec.0000IP ARP: sent rep src 10.2.2.100 c206.13b8.0000, dst 10.1.1.2 c205.07ec.0000 FastEthernet0/0

R1 receives the ARP request, adds the MAC address / IP address of H2 to its own ARP table and sends an ARP reply to H2. This ARP reply contains its own MAC address and the IP address of the server. Let's see what the ARP table of H2 looks like now:

H2#show ip arpProtocol Address Age (min) Hardware Addr Type InterfaceInternet 10.1.1.2 - c205.07ec.0000 ARPA FastEthernet0/0Internet 10.2.2.100 0 c206.13b8.0000 ARPA FastEthernet0/0

You see the IP address of the server and the MAC address of R1, to verify this you can check the interface of R1 like this:

R1#show interface FastEthernet 0/0 | include address Hardware is Gt96k FE, address is c206.13b8.0000 (bia c206.13b8.0000) Internet address is 10.1.1.254/24

That's all there is to it! I hope this example has been useful to you. If you have any questions feel free to leave a comment.

Reliable Static Routing with IP SLA

IP SLA is a great tool on Cisco routers that allows us to generate traffic which can be used to check delay/latency, jitter but can also be combined with object tracking. This allows us to check the reachability of a certain IP address (by pinging) or a certain service by connecting to it (using TCP). If the IP address/service is unreachable we can apply a certain action. A simple example to demonstrate IP SLA is when you have a single router that is connected to two ISPs:

Above we have a router (R1) that is connected to two ISPs. We want to use ISP1 as the primary and ISP2 as the backup link. All traffic will be sent towards ISP1 but when it’s unreachable we’ll switch over to ISP2. You can achieve this by using two default routes:

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.13.3 2

By default a static route has an AD (Administrative Distance) of 1, that’s why I configured the second static route towards ISP2 to have an AD of 2. Having a static route with a higher administrative distance is also called a floating static route. When we look at the routing table of R1 this is what you’ll see:

R1#show ip route static

S* 0.0.0.0/0 [1/0] via 192.168.12.2

Above you will only see the route towards ISP1 because it has a lower AD. Now let’s shut the interface towards ISP1 to see what will happen with the routing table:

R1(config)#interface fa0/0R1(config-if)#shutdownR1(config-if)#exit

This is what you will find:

R1#show ip route static S* 0.0.0.0/0 [2/0] via 192.168.13.3

Now everything will be sent towards ISP2 which is great. This solution is quick and simple but it has some potential problems…a static route will always remain in the routing table unless the interface goes down. It’s possible that the link towards ISP1 is up and running but that the ISP1 router itself is unreachable or that ISP1 has problems on their network that prevents us from reaching the Internet through them. This is why we’ll use IP SLA to make our default route more reliable. First let’s unshut the interface:

R1(config)#interface fa0/0R1(config-if)#no shutdown

I will create an IP SLA instance that pings the IP address of the ISP1 router:

R1(config)#ip sla 1R1(config-ip-sla)#icmp-echo 192.168.12.2 R1(config-ip-sla-echo)#timeout 100R1(config-ip-sla-echo)#frequency 1R1(config-ip-sla-echo)#exitR1(config)#ip sla schedule 1 start-time now life forever

We will ping IP address 192.168.12.2 each second and when we don’t get a response within 100 Ms we will believe it’s unreachable. You might want to play with these values a bit on a production network. Let’s see if IP SLA works:

R1#show ip sla statistics

Round Trip Time (RTT) for Index 1Latest RTT: 4 milliseconds

Latest operation start time: *00:09:07.235 UTC Fri Mar 1 2002Latest operation return code: OKNumber of successes: 43Number of failures: 1Operation time to live: Forever

It seems to be working, right now it only takes 4 milliseconds to get a response. As long as it stays below 100 milliseconds we’ll be fine. Let’s configure the default route to use IP SLA:

R1(config)#no ip route 0.0.0.0 0.0.0.0 192.168.12.2R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2 track 1

First I’ll remove the old default route and replace it with one that says “track 1”. I can’t connect IP SLA directly with the static route, I have to do this with object tracking. This is how you combine object tracking with IP SLA:

R1(config)#track 1 rtr 1

The command above combines object tracking instance 1 with the IP SLA instance that I configured. Let's see if this will work...


Right now everything is working as it should, we use ISP1 for the default route. Curious what happens once ISP1 becomes unreachable?

ISP1(config)#interface fastEthernet 0/0ISP1(config-if)#shutdown

We'll shut the interface on ISP1 and this is what you will find on R1:

R1#%TRACKING-5-STATE: 1 rtr 1 state Up->Down

Object tracking will kick in because we are no longer able to ping the IP address of ISP1. This is what you'll see in the routing table:


We now send all traffic towards ISP2. What will happen once ISP1 is reachable again?

ISP1(config)#interface fastEthernet 0/0ISP1(config-if)#no shutdown

Bring back the interface to the land of the living and this is what you'll discover on R1:

R1#%TRACKING-5-STATE: 1 rtr 1 state Down->Up

Object tracking tells us that we can reach ISP1 again and the routing table will be updated:


There we go, ISP1 is being used again as the primary ISP.

Instead of pinging the ISP's router IP address it might be a better idea to ping something on the Internet or to configure IP SLA to connect to a device using TCP. Pinging the ISP proves that we can reach the ISP but doesn't necessarily mean that we can reach the Internet.

Introduction to OER (Optimized Edge Routing)At the moment I’m working my way through the CCIE R&S blueprint and one of the topics is OER (Optimized Edge Routing). At first this seemed like a boring topic to me but the more time I spent at it the more I like it. On IOS 12.4 you will find OER but on IOS 15 it is called PfR (Performance Routing). Basically what we need to learn for the CCIE R&S 4 lab exam is outdated but OER and PfR are very similar. Since my focus is the CCIE R&S exam i’ll refer to OER, just keep in mind that in production networks we will use PfR.

So what is OER? In short, OER adds intelligence to the network by looking at the current state of the network and injecting routing information to choose the most optimal path. It’s

pretty cool if you think about it. All our routing protocols basically select a path based on static information and they don’t care about the current state of the network. For example OSPF will prefer a gigabit link over a FastEthernet link, even if the Gigabit link is 100% congested and the FastEthernet link is doing absolutely nothing.OER can look at the current state of the interfaces and select the best exit path, it can do this by looking at the delay, response time (IP SLA), utilization of the link but also the MOS (Mean Opinion Score) so that it can select the best path for VoIP traffic. Optimized edge routing and Performance routing got me hooked because I believe this is what the future of networking will look like. To demonstrate why OER could be useful in your networks I want to show you a couple of scenarios:

Above you see a customer router that is connected to two ISPs. ISP A offers a 10 Mbit link and is used as the primary link. ISP B offers a 5 Mbit link and this one is used as the backup link. Our ISPS don’t want to run BGP with us so we can use a routing protocol or static routes for connectivity. The customer is using two static routes for connectivity:

0.0.0.0 /0 with the default administrative distance of 1 for ISP A. 0.0.0.0 /0 with an administrative distance of 5 for ISP B.The default route for ISP B is called a “floating static route” because it will only show up in the routing table if the default route to ISP A is removed from the routing table. This configuration will work but the downside is that we are only using the link to ISP A. In fact we have 15 Mbit (10 Mbit + 5 Mbit from both ISPs) but we can only use 10Mbit at the moment. What if you wanted to use both links? Maybe you are thinking about changing the default route so the administrative distance is equal so that we can do 50/50 load balancing.

This might sound like a good idea but technically it’s not possible. On Cisco routers nowadays we use CEF (Cisco Express Forwarding) and despite what most people believe it doesn’t do load balancing but load sharing. The difference is that load balancing means that the “load” is shared equally on both links…load sharing means we use both links but it’s not balanced. When we have two equal entries, CEF will load share based on the source and destination IP address of a flow. For example, let’s say we have two default routes with the same administrative distance in the topology above and we have the following sessions: A computer with source IP address 1.1.1.1 connecting to a webserver with destination

IP address 4.5.6.7, we’ll call this “flow 1” and It’s consuming about 500kb/sec. A server with source IP address 2.2.2.2 connecting to a remote backup server with

destination IP address 8.9.10.11, we’ll call this “flow 2” and it’s consuming about 4Mbit / sec.

CEF will put flow 1 on the link to ISP A and flow 2 on the link to ISP B. We did “load sharing” but it’s not balanced at all. The link to ISP A now has about 5% utilization (500 kb/sec out of 10Mbit) while the link to ISP B has about 80% utilization (4 Mbit out of 5Mbit).

CEF really doesn’t look at load balancing…it would be difficult to configure true load balancing in the scenario above right? Using OER this is no problem at all!

Let me show you another scenario:

Above we have the same network but we are using VoIP. The link to ISP A is 50 Mbit and the link towards ISP B is 2 Mbit. Since the link to ISP A has a higher bandwidth we are using this as the primary link. Unfortunately the link has a very high delay at the moment (500 ms) so it would be better to use the backup link to ISP B at this moment since it only has a delay of 20 ms. If you wanted to you could configure something like this using policy based routing in combination with IP SLA but it’s not a very good solution. OER can check the delay of our interfaces and automatically reroute VoIP traffic over another interface when it meets certain criteria.

Let’s make it even more complex…

What about the topology above? We have two routers and there are three links to different ISPs. We have a 50, 20 and 10 Mbit link for a total WAN bandwidth of 80 Mbit. Is there any way to load balance traffic on these links? It’s impossible because R1 and R2 have no idea about each others interfaces. They don’t know each others utilization, delay or

anything else. Now let’s talk a bit about OER and how it adds more intelligence to the

network.

Above we see a topology and on the left side is a router called "MC" (Master Controller). On the right side we our two routers are called "BR" (Border Router). The way it works is that the border routers will report information about their interfaces and traffic flows to the master controller. The master controller will make decisions for the network and instruct the border routers to change their routing. In the network above we have 3 exit paths...ISP A,B and C. It's possible that we use the link through ISP A for all our exit traffic but as soon as something happens that we switch over to ISP B or C.Perhaps the delay through ISP A is too high for VoIP traffic, if something like this happens the master controller can instruct the border router on top to switch over to ISP B but it's also possible to change the local preference of BGP and to send traffic towards ISP C. OER

has a number of methods to influence routing including static routes, route redistribution/tagging and changing the BGP local preference.

Whenever something happens to OER (perhaps the MC crashes) nothing bad will happen, we will switch back to "normal" routing. OER is not a replacement for routing protocols. You need to have all your routing in place before you can configure OER...it just adds more intelligence to the network.I hope this introduction has given you an impression of OER and the advantages that it can bring. In the next lesson I will show you how to configure a basic OER setup. If you have any questions feel free to ask!

Bidirectional Forwarding Detection (BFD)BFD (Bidirectional Forwarding Detection) is a super fast protocol that is able to detect link failures within milliseconds or even microseconds.. All (routing) protocols have some sort of mechanism to detect link failures. OSPF uses hello packets and a dead interval, EIGRP uses hello packets and a holddown timer etc.

Networks that use real-time traffic like VoIP require fast convergence times. Routing protocols like OSPF or EIGRP are able to quickly select another path once they lose a neighbor but it takes a while for them to realize that something is wrong.

We can tune timers for fast convergence, for example OSPF can be configured to use a dead interval of only one second. The problem however is that all of these protocols were never really designed for sub-second failover. Hello packets and such are processed by the control plane so there is quite some overhead. BFD was designed to be fast, its packets can be processed by some interface modules or line cards so there isn’t much overhead.

BFD runs independent from any other (routing) protocols. Once it’s up and running, you can configure protocols like OSPF, EIGRP, BGP, HSRP, MPLS LDP etc. to use BFD for link failure detection instead of their own mechanisms. When the link fails, BFD will inform the protocol. Here’s how you can visualize this:

R1 and R2 are configured to use BFD and will send control packets to each other. OSPF remains the same, it’s sending its OSPF packets. Once the link fails, this will happen:

When BFD doesn’t receive its control packets anymore it realizes we have a link failure and it will report this to OSPF. OSPF will then tear down the neighbor adjacency.

There are two operating modes to BFD, asynchronous mode and demand mode. The asynchronous mode is similar to the hello and holddown timers, BFD will keep sending hello packets (called BFD control packets) and when you don’t receive some of them, the session is teared down.The demand mode is different, once BFD has found a neighbor it won’t continuously send control packets but only uses a polling mechanism. Another method has to be used to check reachability, for example it could check the receive and transmit statistics of the interface. Right now Cisco (or any other vendor I know of) doesn’t support BFD demand mode.

Both modes also support something called echo mode. When a device sends BFD echo packets then the receiver will return them without processing them. When the sender doesn’t get the echo packets back, it knows something is wrong and will tear down the session.Anyway enough talk about BFD for now, let’s take a look at this in action!

ConfigurationTo see why BFD is great, we will look at a scenario with and without BFD. I’ll use OSPF but many other (routing) protocols can be used.

OSPF without BFD

This is the topology that we will use:

Above we have two routers that are connected to a switch and running OSPF. Here’s the configuration:

R1 & R2(config)#router ospf 1(config-router)#network 192.168.12.0 0.0.0.255 area 0

Nothing special, just regular OSPF. Suddenly the link fails:

Here’s what will happen:

R1#Jul 30 11:54:46.011: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to downJul 30 11:54:46.011: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.12.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

R1 will detect this link failure right away since it’s directly connected to SW1. It will immediately drop the neighbor adjacency. What about R2?

R2#Jul 30 11:55:14.667: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.12.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

R2 stops receiving OSPF hello packets from R1 so once the dead interval expires, it decides that R1 is unreachable and it will drop the neighbor adjacency. This took about 28 seconds.

Even if you tune the OSPF timers, it will still take about one second. Let’s see how BFD performs…OSPF with BFD

Let’s enable BFD on our two routers running OSPF. Here’s the topology again:

Let’s take a close look at the BFD command:

R1(config)#interface FastEthernet 0/0R1(config-if)#bfd ? echo Use echo adjunct as bfd detection mechanism interval Transmit interval between BFD packets

Above we can specify that we want to use echo packets and we can set an interval. BFD uses echo packets by default so we don't have to change this. Let's look at the interval:

R1(config)#interface FastEthernet 0/0R1(config-if)#bfd interval ? <50-999> Milliseconds

The BFD interval is to specify how often we will send BFD packets, this is similar to the hello packet that protocols like OSPF, EIGRP, HSRP, etc. use. Let's use the lowest value:

R1(config-if)#bfd interval 50 ? min_rx Minimum receive interval capability

The second value to configure is the minimum receive interval. This is how often we expect to receive a BFD packet from our neighbor. We will use the same value here:

R1(config-if)#bfd interval 50 min_rx 50 ? multiplier Multiplier value used to compute holddown

The last value to configure is for the holddown. This is similar to the dead interval in OSPF or the holddown time that other protocols use:

R1(config-if)#bfd interval 50 min_rx 50 multiplier 3

We'll set it to 3. Let's configure the same on R2:

R2(config)#interface FastEthernet 0/0R2(config-if)#bfd interval 50 min_rx 50 multiplier 3

BFD is now up and running but we still have to configure our protocols to actually use it. Here's how to do this for OSPF:

R1(config)#router ospf 1R1(config-router)#bfd all-interfaces

R2(config)#router ospf 1R2(config-router)#bfd all-interfaces

OSPF will now tear down the neighbor adjacency as soon as BFD is telling it that there is a link failure. This is everything we have to do, let's verify our work.

VerificationLet's start with some of the BFD commands:

R1#show bfd neighbors

NeighAddr LD/RD RH/RS State Int192.168.12.2 1/1 Up Up Fa0/0

Above you get a quick overview with all BFD neighbors. You can see that R2 is found on FastEthernet 0/0 and that it's up. Let's take a closer look:

R1#show bfd neighbors details

NeighAddr LD/RD RH/RS State Int192.168.12.2 1/1 Up Up Fa0/0Session state is UP and using echo function with 50 ms interval.OurAddr: 192.168.12.1 Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3Received MinRxInt: 1000000, Received Multiplier: 3Holddown (hits): 0(0), Hello (hits): 1000(617)Rx Count: 96, Rx Interval (ms) min/max/avg: 1/1000/868 last: 648 ms agoTx Count: 618, Tx Interval (ms) min/max/avg: 1/1000/872 last: 708 ms agoElapsed time watermarks: 0 0 (last: 0)Registered protocols: OSPFUptime: 00:01:23Last packet: Version: 1 - Diagnostic: 0 State bit: Up - Demand bit: 0 Poll bit: 0 - Final bit: 0 Multiplier: 3 - Length: 24 My Discr.: 1 - Your Discr.: 1 Min tx interval: 1000000 - Min rx interval: 1000000 Min Echo interval: 50000

Above you can see how often BFD has sent and received packets but also which protocols are using BFD. Now let's actually create a link failure to see how useful BFD is:

SW1(config)#interface FastEthernet 0/1SW1(config-if)#shutdown

Almost immediately you will see these messages on R1 and R2:

R1#Jul 30 13:11:33.507: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.12.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: BFD node downJul 30 13:11:34.339: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to downR2#Jul 30 13:11:29.055: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.12.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: BFD node down

Within a second, BFD reports to OSPF that there is a link failure and the neighbor adjacency has been dropped. Now that's pretty quick!

ConclusionYou have now seen how BFD can be used to speed up convergence because it is able to quickly detect link failures. It's easy to configure and much faster than the "old" method of detecting link failures that protocols like OSPF, EIGRP, BGP, HSRP, etc. use.

I hope you enjoyed this lesson, if you have any questions feel free to leave a comment!

OER (Optimized Edge Routing) Basic ConfigurationIn this lesson I want to show you a basic configuration of OER (Optimized Edge Routing). If you have no idea what OER is or why you want to use this, take a look at my introduction to OER first.OER is not a simple topic and the configuration can become quite complex because of all the policies. In this example i’m going to walk you through a simple scenario where

we configure an MC (Master Controller) and BR (Border Router). Let me show you the

topology:

There are quite some routers so let me explain this topology to you:

R1,R2 and R3 belong together, the serial links on R3 are the “edge” of our network. R3 will be configured as the master controller but also as a border router. You can

configure both on the same router. R3 has two serial links that we will use as “WAN” links. The serial 1/1 interface has a bandwidth

of 64 kbps and the serial 1/0 interface has a bandwidth of 1024 kbps. R1 and R2 will be used as “traffic generators”. R1 will have a TCP connection to the loopback0 interface of R6. R2 will send ICMP traffic to the loopback1 interface of R6. R4 and R5 are nothing special, they are only used as endpoint for the serial links. R6 is only used as an endpoint for our “traffic generators” R1 and R2.By default I will send all traffic over the slow 64 kbps link using a static route, we will use a floating static route to use the 1024 kbps link as a backup. The goal of this lab example is to configure OER to automatically switch traffic flows from the slow 64 kbps link to the 1024 kbps link. Sounds like fun right?

Let’s get to the configuration part!

To keep things simple I will use static routes for connectivity:


R1 and R2 will use a static route pointing to R3.

R3(config)#ip route 0.0.0.0 0.0.0.0 192.168.35.5R3(config)#ip route 0.0.0.0 0.0.0.0 192.168.34.4 5

R3 has two default routes. The first one points to R5 and this is the static route that we will find in the routing table. The second static route is our floating static route pointing to R4. It has an administrative distance of 5.

Something that you should remember about OER is that it requires a “parent route” in order to use a certain link. If I didn’t configure the static route pointing to R4 than OER will never be able to use the serial 1/0 interface!

R4(config)#ip route 192.168.123.0 255.255.255.0 192.168.34.3R4(config)#ip route 6.6.6.0 255.255.255.0 192.168.46.6R4(config)#ip route 66.66.66.0 255.255.255.0 192.168.46.6

R5(config)#ip route 192.168.123.0 255.255.255.0 192.168.35.3R5(config)#ip route 6.6.6.0 255.255.255.0 192.168.56.6R5(config)#ip route 66.66.66.0 255.255.255.0 192.168.56.6

On R4 and R5 we will configure static routes so they can reach the 192.168.123.0 /24 network and the loopback interfaces of R6.


On R6 we’ll configure two default routes pointing towards R4 and R5. I don’t care which path R6 will use…

Let’s check if R1 and R2 can reach R6:

R1#ping 6.6.6.6


R1#ping 66.66.66.66

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 66.66.66.66, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/32 msR2#ping 6.6.6.6


R2#ping 66.66.66.66

Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 66.66.66.66, timeout is 2 seconds:

!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/32 ms

R1 and R2 can reach R6 so my static routes are working. Let’s check the path that they are currently using:

R1#traceroute 6.6.6.6

Type escape sequence to abort.Tracing the route to 6.6.6.6

1 192.168.123.3 4 msec 4 msec 4 msec2 192.168.35.5 8 msec 8 msec 8 msec3 192.168.56.6 8 msec * 8 msec

We are using the path from R3 to R5, this is because of the default route that I configured on R3:

R3#show ip route staticS* 0.0.0.0/0 [1/0] via 192.168.35.5

So far so good, connectivity is working. Before I start with the configuration of OER I want to change the bandwidth of the serial interfaces on R3:

R3(config)#interface serial 1/1R3(config-if)#bandwidth 64R3(config-if)#exitR3(config)#interface serial 1/0R3(config-if)#bandwidth 1024R3(config-if)#exitR3#show interfaces serial 1/1 | include BWMTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,R3#show interfaces serial 1/0 | include BWMTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec,

R3 now thinks that serial 1/1 is 64kbit and serial 1/0 is 1024 kbit. Of course this doesn’t change the actual bandwidth but OER will believe that this is the bandwidth of the

interfaces. Now let’s take a look at OER!

When we configure OER we have to configure the master controller and the border router(s). OER needs to know what the internal and external interfaces are. R3 will be both a border router and the master controller. The FastEthernet 0/0 interface is internal and the two serial links are external. OER requires authentication and it has to be done with a key chain just like EIGRP. Here’s what the configuration looks like:

R3(config)#key chain OERR3(config-keychain)#key 1R3(config-keychain-key)#key-string NETWORKLESSONS

I’ll keep it simple, the key chain is called “OER” and the password will be “NETWORKLESSONS”. Now let’s configure the master controller role:

R3(config)#oer masterR3(config-oer-mc)#border 192.168.123.3 key-chain OERR3(config-oer-mc-br)#interface fastethernet 0/0 internalR3(config-oer-mc-br)#interface serial1/1 external

R3(config-oer-mc-br-if)#exit R3(config-oer-mc-br)#interface serial1/0 externalR3(config-oer-mc-br-if)#exitR3(config-oer-mc-br)#exitR3(config-oer-mc)#exit

First I use the oer master command to enable the MC role. Next step is to configure the border router and specify the key-chain. In my example I'm using IP address 192.168.123.3 but on a production network it's better to use loopback interfaces to establish the neighbor adjacency between the master controller and border router(s). OER uses a TCP connection in case you were wondering.I also configured the interfaces and specified whether they are internal or external, this is something you have to do for all border routers in the network! Now let's configure the border router role:

R3(config)#oer borderR3(config-oer-br)#local fastEthernet 0/0R3(config-oer-br)#master 192.168.123.3 key-chain OER

Use the oer border command to get into the border router configuration. The local command specifies the interface that will be used to source the TCP connection from. Last but not least we configure the master controller and the key chain. Now before we continue it's a good idea to check if the border router has successfully connected to the master controller:

R3#show oer borderOER BR 192.168.123.3 ACTIVE, MC 192.168.123.3 UP/DOWN: UP 00:01:24,Auth Failures: 0Conn Status: SUCCESS, PORT: 3949ExitsFa0/0 INTERNALSe1/0 EXTERNALSe1/1 EXTERNAL

Use show oer border to verify your configuration. We can see that it has successfully connected to the master controller and we can see that it uses TCP port 3949. We also see the internal and external interfaces.We can also take a look at the master controller part, here's how to do it:

R3#show oer masterOER state: ENABLED and ACTIVE Conn Status: SUCCESS, PORT: 3949

Number of Border routers: 1 Number of Exits: 2 Number of monitored prefixes: 0 (max 5000) Max prefixes: total 5000 learn 2500 Prefix count: total 0, learn 0, cfg 0

Border Status UP/DOWN AuthFail192.168.123.3 ACTIVE UP 00:03:31 0

Global Settings: max-range-utilization percent 20 mode route metric bgp local-pref 5000 mode route metric static tag 5000 trace probe delay 1000 no logging

Default Policy Settings: backoff 300 3000 300 delay relative 50 holddown 300 periodic 0 mode route observe mode monitor both mode select-exit good loss relative 10 unreachable relative 50 resolve delay priority 11 variance 20 resolve utilization priority 12 variance 20

Learn Settings: current state : DISABLED time remaining in current state : 0 seconds no throughput no delay no protocol monitor-period 5 periodic-interval 120 aggregation-type prefix-length 24 prefixes 100 expire after time 720

Use show oer master to see information from the MC's role. We see that the master controller is running, we have a border router and two exit paths for our network. It also shows us the default policy. Explaining the policy settings it outside the scope of this lesson as there's quite some stuff we can do. I will cover it later in another lesson.

Before I start traffic generation on R1 and R2 I will enable logging on the master controller. This wil output everything on the console, it's just like a debug and it will show us what OER is doing:

R3(config)#oer masterR3(config-oer-mc)#logging

Now let's generate some traffic from R1 and R2, here's what I will do:

R1 will connect to IP address 6.6.6.6 using TCP. R2 will send ICMP traffic to 66.66.66.66.

R6(config)#service tcp-small-serversR1#telnet 6.6.6.6 19Trying 6.6.6.6, 19 ... Open !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_àbcdefg!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_àbcdefgh"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_àbcdefghi#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_àbcdefghij$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_àbcdefghijk

I will enable TCP small servers on R6 and connect to TCP port 19 from R1. This will generate characters and it's a great way to have a working TCP connection.

R2#ping 66.66.66.66 repeat 999999999 size 1500

On R2 we will configure a simple ping with a size of 1500. Make sure you send enough pings...

OER will enable netflow on the border routers and we can take a look at the current flows:

R3#show ip cache flow IP packet size distribution (17715 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .012 .000 .576 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .000 .000 .000 .000 .410 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes 4 active, 4092 inactive, 7 added 589 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 secondsIP Sub Flow Cache, 21640 bytes 7 active, 1017 inactive, 11 added, 7 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added last clearing of statistics neverProtocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)-------- Flows /Sec /Flow /Pkt /Sec /Flow /FlowTCP-other 1 0.0 1 44 0.0 0.0 15.9ICMP 2 0.0 85 1500 0.0 1.1 15.1Total: 3 0.0 57 1491 0.0 0.7 15.3

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP PktsSe1/1 6.6.6.6 Fa0/0 192.168.123.1 06 0013 B154 10KFa0/0 192.168.123.1 Se1/1 6.6.6.6 06 B154 0013 226 Fa0/0 192.168.123.2 Se1/1 66.66.66.66 01 0000 0800 3610 Se1/1 66.66.66.66 Fa0/0 192.168.123.2 01 0000 0000 3610

Above you see my ICMP and TCP flow. You'll see it from both directions and you can see the number of packets/bytes etc. There is a useful command on the master controller that we can use to see the current load on our interfaces:

R3#show oer master border detail Border Status UP/DOWN AuthFail192.168.123.3 ACTIVE UP 00:19:32 0 Se1/0 EXTERNAL UP Se1/1 EXTERNAL UP Fa0/0 INTERNAL UP

External Capacity Max BW BW Used Tx Load Status Exit Id Interface (kbps) (kbps) (kbps) (%) --------- -------- ------ ------- ------- ------ ------ Se1/0 1024 768 0 0 UP 2 Se1/1 64 48 631 67 UP 1

Use the show oer master border detail command to see the current traffic load on the interfaces of your border routers. Above you can see the current traffic load on the serial 1/1 interface which is 631kbps. You can see the capacity of the links and the max BW. The maximum bandwidth that we can use is 75% of the interface. This serial 1/1 interface is heavily oversubscribed right now while our serial 1/0 interface is doing nothing. This is normal because our default route is pointing out the serial 1/1 interface. If you enabled logging for OER then you will also see messages like these in your console:

R3#%OER_MC-5-NOTICE: Range OOP BR 192.168.123.3, i/f Se1/1, percent 71%OER_MC-5-NOTICE: Load OOP BR 192.168.123.3, i/f Se1/1, load 865 policy 48%OER_MC-5-NOTICE: Exit 192.168.123.3 intf Se1/1 OOP, Tx BW 865, Rx BW 909, Tx Load 94, Rx Load 94

We haven't talked about policies but OOP means "Out of Policy". The default policy of OER is telling us that there's too much traffic on our serial 1/1 interface right now.OER is giving us all this great information but at the moment it's not taking any action. First we need to configure it to learn about the prefixes that have the highest throughput or delay. OER uses the information from netflow for this, here's how we can enable the learning of those prefixes:

R3(config)#oer master R3(config-oer-mc)#learn R3(config-oer-mc-learn)#throughputR3(config-oer-mc-learn)#delay

Throughput means it will learn prefixes with the highest outbound throughput, delay means prefixes with the highest RTT (Round Trip Time). As soon as you enable this you will see the following in your console:

R3(config-oer-mc)#%OER_MC-5-NOTICE: Prefix Learning STARTED

By default OER will learn prefixes for 5 minutes and then sleep for 120 minutes. This can be annoying in a lab so you might want to speed it up. If you miss the 5 minute "learning" period you'll have to wait 120 minutes (or reset OER). These timers can be tuned if you want. Once the learning period is over (5 minutes) you will see this in the console:

R3(config-oer-mc)#%OER_MC-5-NOTICE: Prefix Learning WRITING DATA

OER will have learned about the top prefixes but it will still not take any action.This is because the default mode is to observe but not take any action. Information from the border routers is sent to the master controller but that's it. You can verify the current OER mode here:

R3#show oer master | include mode route mode route metric bgp local-pref 5000 mode route metric static tag 5000 mode route observe

Now we will change the mode to control so that the master controller will send instructions to the border router! Here's how to do it:

R3(config)#oer masterR3(config-oer-mc)#mode route control

Use the mode route control to make OER send instructions back to the border routers. The master controller will now instruct our border router to change the routes, let's see if this is true:

R3#show oer master border detail Border Status UP/DOWN AuthFail192.168.123.3 ACTIVE UP 01:10:09 0 Se1/0 EXTERNAL UP Se1/1 EXTERNAL UP Fa0/0 INTERNAL UP

External Capacity Max BW BW Used Tx Load Status Exit Id Interface (kbps) (kbps) (kbps) (%) --------- -------- ------ ------- ------- ------ ------

Se1/0 1024 768 222 21 UP 2 Se1/1 64 48 603 38 UP 1

Awesome! As you can see it is now also using the serial1/0 interface. Let's take a look what OER did exactly:

R3#show oer border routes static

Flags: C - Controlled by oer, X - Path is excluded from control, E - The control is exact, N - The control is non-exact

Flags Network Parent Tag CE 6.6.6.0/24 0.0.0.0/0 5000 CE 66.66.66.0/24 0.0.0.0/0 5000

Use show oer border static to see what routes OER has changed. It has influence traffic towards 6.6.6.0 /24 and 66.66.66.0 /24. Let's take a look at the routing table:

R3#show ip route static 66.0.0.0/24 is subnetted, 1 subnetsS 66.66.66.0 [1/0] via 192.168.34.4 6.0.0.0/24 is subnetted, 1 subnetsS 6.6.6.0 [1/0] via 192.168.34.4S* 0.0.0.0/0 [1/0] via 192.168.35.5

Do you see the next hop IP address of the two static routes that I highlighted? Traffic for these two networks is now sent towards R4. OER has configured this for us!...pretty cool right?

This concludes our basic OER configuration tutorial. You have now learned how to configure a master controller, border controller, how to make OER learn about prefixes from netflow and how to take action upon it. In future lesson I will explain more about the different policies and how to use OER in combination with BGP. If you enjoyed this lesson please leave a comment and feel free to ask any questions!

OER (Optimized Edge Routing) Timers for Labs

One of the annoyances of working with OER (Optimized Edge Routing) in labs is that it is based on timers for different actions. This can be very annoying when you are doing labs since it means you will be staring for minutes (or hours) at your console screen waiting for OER to take any action.

We can however optimize the OER timers to make it learn and react faster, in this lesson I want to give you an overview of the timers we can change.

First of all you might want to consider changing the load interval of your external interfaces on the border routers. By default the load interval is calculated each 5 minutes which is an eternity when you are doing labs. We can change this to a minimum of 30 seconds like this:

BR(config)#interface serial 0/0BR(config-if)#load-interval 30

30 seconds is the lowest value we can use, configure it using the load-interval command.The next step is to take a look at the actual OER timers. For the learning process there are two important timers:

periodic-interval monitor-period

The learning process for OER has a periodic-interval and a monitor-period. The periodic-interval is a sleep timer that tells OER how often to start the learning process and how to long to sleep and retain the information that it has learned. By default this is 2 hours which is way too long for a lab. If you keep it at the default you might find yourself restarting the OER master cotroller more often than you wish for.The monitor-period defines how long we will learn the different traffic flows. By default this is 5 minutes but we can reduce it. Simply said…OER will learn for a period and then go back to sleep, wake up after a while to learn again and so on. This is how we can change these timers:

MC(config)#oer masterMC(config-oer-mc)#learnMC(config-oer-mc-learn)#periodic-interval 1MC(config-oer-mc-learn)#monitor-period 1

I will set both timers to 1 minute. This makes it suitable for a lab.

There are two more OER timers that you should adjust:

backoff holddownThe backoff timer tells OER that once a traffic flow is out of policy, the master controller will wait for a certain amount of time before it tries to find another exit path. This backoff timer tells the master conroller how long to wait and it increases each time the master controller is unable to find an optimal exit path. We use this backoff timer so the master controller gets more time to find an exit path after each time it is unsuccessful.

We have to configure a minimum and maximum time value and also a step value. By default the minimum timer is 300 seconds, maximum is 3000 seconds and the step value is 300 seconds. This means that the first time the master controller will have 300 seconds to find an exit path, if it is unsuccessful, the next time it will add the step time (300 seconds) so it will have 600 seconds. If it's still unsuccessful the next time it will take 900 seconds, 1200, 1500 and so on....up to a maximum of 3000 seconds.

The holddown timer tells OER how long a new exit path must be used after it went out of policy before we can look for a new best exit path. We do this to prevent flapping between different exit paths. By default this is 300 seconds and on some routers you can reduce it to 90 seconds.Here is how to change the backoff and holddown timer:

MC(config)#oer masterMC(config-oer-mc)#holddown 90MC(config-oer-mc)#backoff 90 180 90

This will change the holddown timer to 90 seconds and the min and max backoff timer to 90 seconds.

OER Variance to solve Policy ConflictsWhen you configure a policy for OER you can choose what metrics are most important to you (packet loss, delay, jitter, etc.). For example you can configure a policy that will choose an exit path based on the following criteria:

1. Lowest Delay2. Lowest Jitter3. Lowest Packet LossNow imagine we have two exit paths with the following metrics:

1. Exit A: Delay is 80ms, jitter is 5ms and packet loss is 2000ppm.2. Exit B: Delay is 90ms, jitter is 3ms and packet loss is 1500ppm.If we select exit A based on the lowest delay only then we don’t make the best choice since the jitter and packet loss of exit A are worse than exit B. By using the variance we can ensure that other exit paths fall within the “acceptable” criteria for a certain metric. This allows us to choose an exit path based on more than one metric.Now let’s say I configure a variance of 15% for delay. Exit path A has a delay of 80 ms. All exit paths that fall within 80 ms + 15% will be considered equal when it comes to delay. 80ms + 15% = 92 ms. The delay for exit B (90 ms) is lower than 92 ms so exit A and B are seen as “equal” when it comes to delay. This means we will have to look at the second metric (jitter).

Does this make sense? Let’s take a look at an actual policy with 3 exit paths:

Exit A: Delay 100 ms, jitter 5ms, packet loss 2000ppm. Exit B: Delay 150 ms, jitter 6ms, packet loss 1900ppm. Exit C: Delay 110 ms, jitter 3ms, packet loss 1900ppm.

MC#show run | sec oer-mapoer-map VARIANCE 10 match traffic-class prefix-list MYPREFIXES set resolve delay priority 1 variance 20 set resolve loss priority 2 variance 10 set resolve jitter priority 3 variance 15

Let me describe the policy above:

Priority 1 is delay but we have a variance of 20%. Priority 2 is loss with a variance of 10%. Priority 3 is jitter with a variance of 15%.Now which exit path are we going to use? Let me walk you through the process:

1. First we take a look at the lowest delay, that is exit A. The variance however is 20%. 100 ms + 20% = 120 ms.

2. Exit C is still in the race because 110 ms is lower than 120 ms. Exit B has a too high delay so it will not be used.

3. The second priority is packet loss so we’ll compare exit A and B. Exit C has a packet loss of 1900 ppm (packet per million). There is a variance of 10% however. 1900 ppm + 10% = 2090 ppm. Exit A has a packet loss of 2000 which is lower than 2090 ppm so exit A is still in the race…

4. We’ll have to compare the last metric which is jitter. Exit C has 3 ms jitter and exit A has 5 ms jitter. As a result we will select exit C as the most optimal exit path.

That’s how OER will select the most optimal path when using variance. I hope this has been helpful to you! If you have any questions just leave a comment.

OER (Optimize Edge Routing) PhasesIf you are new to OER I suggest to stop now and read my Introduction to OER first. This will give you an idea what OER is and why you might want to use it. Reading about the different OER phases will be very confusing if you don’t know the basics. After reading the introduction it’s best to start with a basic configuration first so you’ll see how it works. Having said that, let me show you the different phases: OER Profile Phase OER Measure Phase OER Apply Policy Phase OER Control Phase OER Verify PhaseThese 5 phases always loop around. OER will start with the profile phase and then moves on to the measure, apply policy, control and verify phase. After the verify phase it will go back to the profile phase and this cycle will keep on going. Now let’s take a closer look at the different phases:

OER Profile Phase

Depending on the size of your network you might have hundreds or thousands of routes in the RIB (Routing Information Base). Optimize edge routing means that we will prefer some traffic over other traffic so we have to select a number of routes from the RIB that we want to optimize. There are a couple of ways how we can do this:

We can automatically learn traffic flows that experience performance issues. It’s also possible to manually configure different traffic classes.So what is a “traffic class” exactly? It can be something simple like a prefix but it’s also possible to use a prefix in combination with a port number. Border routers will learn about traffic classes and report this to the master controller. These traffic classes are then stored in a special table called the Monitored Traffic Classes (MTC) table. This MTC has a limited capacity so by default OER will perform prefix aggregation. It will aggregate (summarize) all prefixes to a /24 by default. The MTC will store 100 prefixes but this is something we can change if we want to.Automatically learning of traffic classes is done by using the top talkers feature of NetFlow. You don’t have to configure NetFlow yourself, it is done for you automatically when you enable OER.OER doesn’t check for traffic classes non-stop but it works with a schedule:

OER will learn in the monitor period which is 5 minutes by default. Once this period is over it will go into “sleep mode” (120 minutes) and it will save the information on the prefixes that it has learned. These timers might be ok for production networks but you might want to speed it up for your labs.

OER Measure PhaseOnce we know what traffic classes we want to optimize (either by learning or configuring them ourselves) OER will measure the performance of each traffic class. There are two methods how we can do this:

Passive monitoring Active monitoring

Passive monitoring uses Netflow and interface counters on the border routers. OER will measure the following performance metrics using NetFlow: Delay: The average delay of TCP flows for a prefix. It will keep track of TCP segments

and the returning TCP ACK to calculate round-trip response time (RTT). Packet Loss: By keeping track of TCP sequence numbers OER can measure packet

loss. Reachability: OER will keep track of TCP SYNs that have been sent without receiving a

TCP ACK response. Throughput: The total number of bytes and packets for each traffic class in a certain

amount of time. This is one of the metrics that can be used for non-TCP traffic.Active monitoring uses IP SLA to emulate the traffic class and discover performance metrics. Our border routers will report their information to the master controller, the master controller will store the performance metrics together with the traffic classes in the MTC. OER can collect the following performance metrics thanks to IP SLA: Delay (same as above). Reachability (same as above). Jitter: A variation in delay causes jitter. OER will send multiple packets to the

destination and measure the delay between them. MOS: The Mean Opinion Score is used to represent voice quality on a scale from 1 to 5.

1 = terrible voice quality, 5 = best voice qualityFor each traffic class or interface that OER monitors it will check the current state and it does this by using different states: Default: traffic classes in the default state are not controller by OER. When a traffic

class is added to the MTC it will be in the default state. You will see traffic classes go into and out the default state depending on measurement results and the policy that you have configured.

Choose Exit: This is where OER compares performance metrics against the configured policy for the traffic class. OER will prefer to keep the current “exit path” for a certain traffic class but when it exceeds its current policy the master controller will start looking for another exit path.

Holddown: A traffic class will be in the holddown state when the master controller tells the border router to use active probes (IP SLA) to monitor the traffic class. Performance metrics are collected until the holddown timer expires.

In-Policy: After comparing the performance metrics against the policy and an exit path has been selected, the traffic class will be in-policy. This means the traffic class doesn’t exceed our policy…the master controller will keep monitoring the traffic class but no action is taken unless the periodic timer expires or when the traffic class performance metrics exceeds the policy.

Out-of-Policy (OOP): When there are no exit paths that conform to the policy, the traffic class will go out-of-policy. The backoff timer controls whether a traffic class can leave this state or not and every time a traffic class goes to the out-of-policy state this timer will increase. The backoff timer will reset when the traffic class goes to the in-policy state. When all exit paths are out-of-policy the master controller can select the best exit path available.

OER Apply Policy Phase

On the master controller we will configure a policy with certain thresholds for our traffic classes to define “acceptable performance”. OER will compare the performance metrics with the policy that we created. When the performance metrics exceed the threshold in our policy the traffic class will go OOP (Out of Policy). OER will keep comparing these results to see if there are changes in traffic flows. There are two types of policies for OER:

Traffic class policies Link policiesTraffic class policies are configured for prefixes or applications. Link policies are used for exit or entrance links at the edge of our network. For example we can configure OER that traffic towards destination 4.4.4.0/24 should never have a higher delay than 150 ms. As soon as the delay is higher than 150 ms, OER will look for a better exit path so that we conform to the policy.

OER Control PhaseThe control phase is where the action happens. When OER has decided that some traffic classes do not confirm to the policy it will change routing on the border routers. It can do this by injecting static routes, BGP routes, changing the BGP local preference, changing route metrics and/or using policy based routing. As a result some traffic classes will have a different exit path. OER will initiate a route change when any of the following occurs: Traffic out-of-policy: when the performance metrics exceed the configured policy. Exit link out of policy: when the link (interface) exceeds link utilization or loses

connectivity. Periodic timer expires: when OER is configured for "best mode" the master controller

will start looking for the best exit path for the traffic class.When a traffic class is defined only by a prefix then OER can use static route or BGP route injection. These changes are network-wide since it will affect all routers in the network. Before injecting routes, OER will verify if you already have this route in your BGP table or configured as a static route...if not, it is impossible to inject the route. OER requires a parent route in order to inject routing information. This makes sense because OER is not a routing protocol...if it would just send traffic in a certain direction you might end up blackholing traffic or creating routing loops. Make sure you have configured a floating static route or have a valid entry in the BGP table.OER is not a routing protocol...make sure you have a valid parent route if you want to send traffic another way.

Traffic classes that have a prefix AND a port number can not be influenced by using route injection When this occurs the changes are not network-wide but device-specific. In this case OER will use policy based routing to influence routing.

When you use PBR to influence routing, the border routes have to be one hop away...physically or otherwise by using a GRE tunnel.

OER Verify PhaseAfter making changes and sending traffic in different directions, OER will verify that the traffic is optimized and using a different exit interface. OER will collect the resulting statistics to verify that the changes bring the traffic classes "in policy". The master controller will verify this by watching netflow information from the interface of the new exit path and ignoring netflow information from the old interface.