BGP LAB #3: Sessions, Next-hop-self and Local Preference

Topology:

Objectives:

1. Research the concepts for “next-hop-self” and “Local-Preference” attributes and implement these in order for the IBGP Peers to correctly exchange routing information and provide redundancy.
2. Ensure that the *preferred* link is used for sending and receiving data and that the *backup* link is only used in the event that the *preferred* one has failed.

Initial Configuration:

We will start by setting up IBGP between R2 and R3.
I will also configure IBGP on these two routers to use their loopback addresses to communicate instead of the physical ones. This can be done with the “update-source” keyword in the neighbour statement.

It’s good practice to use a loopback interface in this kind of configuration because a loopback can never go down on its own, unlike a physical interface.

R2(config)#router bgp 64512
R2(config-router)#neighbor 172.16.32.1 remote-as 64512
R2(config-router)#neighbor 172.16.32.1 update-source loopback 0

R3(config)#router bgp 64512
R3(config-router)#neighbor 172.16.64.1 remote-as 64512
R3(config-router)#neighbor 172.16.64.1 update-source loopback 0

I noticed that my neighbourships are not forming yet because I misconfigured EIGRP earlier.
The networks that the loopback interfaces are in are not being advertised so IBGP has no way to communicate between the two routers.

Note that BGP is a Transport Layer Protocol which sets up its sessions through TCP Port 179.

Here’s the correct EIGRP config which should be added to the overview above.

R3(config)#router eigrp 10
R3(config-router)#network 172.16.32.0 0.0.0.255

R2(config)#router eigrp 10
R2(config-router)#network 172.16.64.0 0.0.0.255

And now my neighbours wake up.

R2#
*Mar 1 00:59:58.755: %BGP-5-ADJCHANGE: neighbor 172.16.32.1 Up

R3#
*Mar 1 00:59:55.727: %BGP-5-ADJCHANGE: neighbor 172.16.64.1 Up

Looking at the output of “show ip bgp neighbours” we can see this neighbourship is being recognized as an internal link.

Now I will configure EBGP to run between the ISP router and R2/3. We will not be using the update-source keyword because there’s only one available WAN link between the ISP and both routers.

On the ISP Router;

ISP(config)#router bgp 200
ISP(config-router)#neighbor 192.168.1.6 remote-as 64512
ISP(config-router)#neighbor 192.168.1.2 remote-as 64512
ISP(config-router)#network 192.168.100.0

On R2;

R2(config)#ip route 172.16.0.0 255.255.0.0 null 0
R2(config)#router bgp 64512
R2(config-router)#neighbor 192.168.1.5 remote-as 200
R2(config-router)#network 172.16.0.0

A few notes on the above configuration of R2;

A static “null” or “black hole” route has been configured for the 172.16.0.0/16 network. This will cause all traffic not matched by the more specific routes to be dropped by this router. (As you know, more specific routes are always preferred over less specific ones) We can see this by looking at R2’s routing table.

Lets look at the output from “show ip bgp neighbors” on R2 to verify that the neighbourship is correctly up and running. This is giving me alot of output so I will only copy/paste the most interesting part for this section.

R2#sh ip bgp neighbors 192.168.1.5
BGP neighbor is 192.168.1.5, remote AS 200, external link
BGP version 4, remote router ID 192.168.100.1
BGP state = Established, up for 00:11:25

We can see that for our new neighbor, the neighbourship is Established and is recognized as an External Link. Good.

I’ll configure the same for R3 now.

R3#conf t
R3(config)#ip route 172.16.0.0 255.255.0.0 null 0
R3(config)#router bgp 64512
R3(config-router)#neighbor 192.168.1.1 remote-as 200
R3(config-router)#network 172.16.0.0

Another useful command to verify if the neighborships are up and running correctly is “show ip bgp summary”

This is the output of the above command as seen on R3:

In this output we can see some useful information such as an overview of our neighbors and the router identifier along with its local AS number.

We will now run a test to see which path our traffic is currently taking. To make sure everything is up to date, I will clear the BGP process on the ISP router with the command “Clear ip bgp *” I do not advise you do this on a production router. There are less impacting ways to refresh your BGP setup which we will go into later on.

ISP#clear ip bgp *
ISP#
*Mar 1 00:20:57.055: %BGP-5-ADJCHANGE: neighbor 192.168.1.2 Down User reset
*Mar 1 00:20:57.059: %BGP-5-ADJCHANGE: neighbor 192.168.1.6 Down User reset
ISP#
*Mar 1 00:21:19.143: %BGP-5-ADJCHANGE: neighbor 192.168.1.2 Up
*Mar 1 00:21:19.155: %BGP-5-ADJCHANGE: neighbor 192.168.1.6 Up

You can see that both our neighbors go down because of a “User reset” and come back up again a bit later.

What I like about this is that there is no confirmation dialog for this potentially very destructive command, yet if you try to clear counters or the logging buffer, you are required to confirm.

But then again, you could make the argument that you are supposed to know what you are doing when working on a production router.

Let’s start pinging from the ISP router and see what kind of results we get:

ISP#ping 172.16.64.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.64.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
ISP#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
ISP#ping 172.16.32.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.32.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/16 ms
ISP#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 = 1/5/16 ms
ISP#

It seems our pings towards the ip addresses of R2 are failing. Let’s find out why.

I run the command “show ip bgp” on the ISP router. Here is the output:

Here we can see that, for the 172.16.0.0 network, there are two paths. The ISP router has chosen 192.168.1.2 as preferred path as indicated by the ‘>’.

As from the official Cisco Documentation:

BGP operates differently than all other protocols. Unlike other routing protocols that use complex algorithms involving factors such as bandwidth, delay, reliability, and load to formulate a metric, BGP is policy-based. BGP determines the best path based on variables, such as AS path, weight, local preference, MED, and so on. If all things are equal, BGP prefers the route leading to the BGP speaker with the lowest BGP router ID.

So R3 with BGP router ID 172.16.32.1 was preferred to the higher BGP router ID of R2 which is 172.16.64.1.

This is why we can reach the 32 subnet and not the .64 one.

What we need to do to solve this, is advertise the links between the ISP and the two routers, which I’ll do now:

ISP#conf t
ISP(config)#router bgp 200
ISP(config-router)#network 192.168.1.0 mask 255.255.255.252
ISP(config-router)#network 192.168.4.0 mask 255.255.255.252

I am now able to reach both networks from the ISP router:

ISP#ping 172.16.64.1

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

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

I will now configure the “next-hop-self” neighbor keyword on both R2 and R3 so they advertise themselves as the next hop for foreign routes.

This is the current ip bgp table on R2 and R3

Now to enter the aforementioned commands.

R2#conf t
R2(config)#router bgp 64512
R2(config-router)#neighbor 172.16.32.1 next-hop-?
next-hop-self next-hop-unchanged

R2(config-router)#neighbor 172.16.32.1 next-hop-self

R3#conf t
R3(config)#router bgp 64512
R3(config-router)#neighbor 172.16.64.1 next-hop-self

And let’s take another look at our ip bgp tables to see what has changed.

This is looking nice and clean.
Do note the ‘r‘ symbol in front of the route for network 192.168.1.0/30. This indicates a RIB Failure.

In most cases this will mean that BGP can not inject the route, because a more specific or preferred route already exists.

If you check the routing table on R3, you will see that the network is Directly Connected, which is indeed more preferred.
The same goes for the alternate path through 172.16.64.1, which is learned through EIGRP, thus more preferred.

At this point, everything is looking good, with the exception of default routes and the outbound and inbound traffic flow.

Our objective states that we must use the link between R2 and ISP as the preferred link.

To achieve this I will be using Local Preference to manipulate our routing decisions.

This can be done by using Route-maps and the “local-preference” sub-command.

We will create a Route-Map and use it to set the local-preference.  Then we will enter a neighbor statement to refer to the routemap.

Vamos!

R2#conf t
R2(config)#route-map PREFERREDLINE_IN permit
R2(config-route-map)#set local-preference 150
R2(config-route-map)#exit
R2(config)#router bgp 64512
R2(config-router)#neighbor 192.168.1.5 route-map PREFERREDLINE_IN in

R3#conf t
R3(config)#route-map BACKUPLINE_IN permit
R3(config-route-map)#set local-preference 125
R3(config-route-map)#exit
R3(config)#router bgp 64512
R3(config-router)#neighbor 192.168.1.1 route-map BACKUPLINE_IN in

Now, after clearing the BGP process, let’s take another look at the ip bgp table.

Everything is now being sent over our preferred link as intended.

Let’s do a recorded ping test on R3 to 192.168.100.1 with as source its loopback interface.

Reply to request 0 (28 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(172.16.1.2)
(192.168.1.6)
(192.168.100.1)
(192.168.1.5)
(172.16.1.1)
(172.16.32.1) <*>

Looks like we’re taking the path R3 – R2 -> ISP -> R2 -> R3.

If we take down the preferred link, traffic will flow over the backup link as intended.

R2(config)#int se 0/1
R2(config-if)#shut
R2(config-if)#
R2#
R2#
*Mar 1 02:36:26.939: %BGP-5-ADJCHANGE: neighbor 192.168.1.5 Down Interface flap

Reply to request 1 (12 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(172.16.1.1)
(192.168.1.2)
(192.168.100.1)
(192.168.1.1)
(172.16.1.2)
(172.16.64.1) <*>

And there we go, objective completed.

Advertisement

BGP LAB #2: Removing Private Autonomous System Numbers

In the topology below you can see that R3’s BGP process is running in AS 65000. AS Numbers 64511 through 65535 are private and should not be leaked into a BGP table because they are not unique.

Private AS numbers are usually assigned to a company that only has a single ISP with one or multiple connections. This is called a single-homed connection.

In this update I will look into which methods are available to make sure the private AS numbers are removed from the PATH list before the routers are propagated to a BGP peer.

Topology

R3 represents our client-side office, with R2 being its ISP. R1, in turn, represents a network somewhere else on the internet.

Initial Configuration

R1
==

R1#sh run int se 0/0
Building configuration…

Current configuration : 84 bytes
!
interface Serial0/0
ip address 10.0.0.1 255.255.255.252
clock rate 2000000
end

R1#sh run int lo 1
Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 1.1.1.1 255.255.255.0
end

R1#sh run | sec bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
neighbor 10.0.0.2 remote-as 200
no auto-summary

R2
==

R2#sh run int se 0/0
Building configuration…

Current configuration : 84 bytes
!
interface Serial0/0
ip address 10.0.0.2 255.255.255.252
clock rate 2000000
end

R2#sh run int se 0/1
Building configuration…

Current configuration : 84 bytes
!
interface Serial0/1
ip address 20.0.0.2 255.255.255.252
clock rate 2000000
end

R2#sh run int lo 1
Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 2.2.2.2 255.255.255.0
end

R2#sh run | sec bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 2.2.2.0 mask 255.255.255.0
neighbor 10.0.0.1 remote-as 100
neighbor 20.0.0.1 remote-as 65000
no auto-summary

R3
==

R3#sh run int se 0/1
Building configuration…

Current configuration : 84 bytes
!
interface Serial0/1
ip address 20.0.0.1 255.255.255.252
clock rate 2000000
end

R3#sh run int lo 1
Building configuration…

Current configuration : 61 bytes
!
interface Loopback1
ip address 3.3.3.3 255.255.255.0
end

R3#sh run | sec bgp
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 20.0.0.2 remote-as 200
no auto-summary

Looking at the paths on R1, we can see that AS 65000 is included. This means that our private AS information is being leaked into the internet which could have some bad results!

By doing some research, you can find that Cisco has added a feature to their routers which will allow you to remove the private AS numbers from any advertisements.

This is done by adding the keyword “remove-private-as” to your BGP neighbour statement towards the router that should NOT receive the private AS.

Let’s go on our ISP router, R2, and configure this to see the results.

R2(config)#router bgp 200
R2(config-router)#neighbor 10.0.0.1 remove-private-as

Let’s take another look at the paths on R1 after running “Clear IP BGP *” on R2.

We can now see that the private AS is no longer showing up.

What happened is that R2 removed the private AS number and replaced it with its own. You can see that for R3’s loopback interface, the only known path is AS 200.

Then at R2, we can still see the required path information and are still able to ping R3 from R1.

So that is it. We have successfully stopped the private AS number from leaking into the ‘internet’.

References:
BGP Best path selection.
Removing private AS.

Last Hop, Second Packet : The Mystery

The Back-story
============

Often I’ve noticed that when doing a trace-route from one Cisco router to another, the last hop will always show one lost packet. Like so;

Router1#traceroute 34.0.0.4

Type escape sequence to abort.
Tracing the route to 34.0.0.4

1 12.0.0.2 4 msec 4 msec 4 msec
2 23.0.0.3 20 msec 16 msec 16 msec
3 34.0.0.4 16 msec * 16 msec

Now at first sight, it seems there would be something wrong at the final hop, as each time you do this trace, you will see the second packet being dropped.

So, thinking it was a bug or something, I opened a TAC Case at Cisco asking if this was a known issue.

Their first reply was asking whether I already tried debugging the traces to find the root cause of these drops, nothing about whether or not they are aware of this issue.

Which is weird, because even in their on-line documentation you can see the same behavior, Which I also pointed out to the technician handling the case.

There was no reaction on my comment…

The Objective
===========

It’s my intention to investigate exactly how and why we’re seeing this behavior and probably learn some more about the inner workings of a trace-route.

I will log everything in this update as I go through my investigation, this should give you a nice overview of my troubleshooting process and train of thought.

Hopefully there won’t be any derailment!

The Scene
========= 

I have set up the a simple topology in GNS3 to test this.
Each router has EIGRP running in order to advertise the networks and everything responds to ping tests as it should.

R1 Lo 1 will be our starting point, R4 Lo 1 our destination.

Let’s verify we indeed have the same issue on this network as I described above. I will do a trace-route from R1 to R4’s loopback address.

R1#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 10.1.1.2 68 msec 48 msec 0 msec
2 10.2.2.3 92 msec 52 msec 88 msec
3 10.3.3.4 244 msec * 140 msec
R1#

As I expected, the second packet on the last hop failed. Yet, an extensive ping test shows no issues. The response times are a bit high but this is due to the heavy load GNS has on my computer.

To even begin with the investigation, we must first understand how a trace-route actually works.

The Facts
========

What IS a trace-route anyway?

A Trace-route is often used as a troubleshooting tool to find out which path a packet takes when travelling to its destination. When a remote device becomes unreachable, for example, trace-route can be used as one of the tools to find out where the problem may lay.

How does it work?

When you start a default trace-route, three UDP packets are sent to the specified destination with an invalid port address. Each packet with a Time-To-Live value of ‘one’.

The TTL value of ‘one’ causes the packet to timeout as soon as it reaches the first hop in its path, this hop (or router) then replies with an ICMP Type 11 message, meaning “Time Exceeded”

Another 3 UDP packets are then sent, but this time with a TTL value of ‘two’. which will cause the second hop to respond with ICMP Type 11 messages. After this it will send another 3 packets with a TTL value of 3, and so on ..

Documenting the source and response times of these Type 11 messages is how a trace-route is able to show you information about every hop between your source and destination.

Once your UDP packets arrive at its final destination, that target device will respond with a Type 3, code 3 message (Port Unreachable). Once the source device receives this message, it will know the trace-route process has arrived at its destination.

This process does not sound that complicated, so why are we seeing that one dropped packet ..

The Investigation
===============

Let’s roll.

I will start out by enabling debugging on R1 and checking what kind of output I get when doing the trace-route.

I will also create an access-list to identify the trace-route traffic between R1 and R4 so my debug output is filtered a bit and I do not get too much information about irrelevant traffic.

R1(config)#access-list 100 permit icmp any any
R1#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100

And to keep things nice and neat, I will turn off console logging and enable buffer logging for debug type messages. This will keep my CLI from getting cluttered with debug output.

R1(config)#no logging console
R1(config)#logging buffered 7

I run another trace-route;

R1#traceroute 4.4.4.4 source 1.1.1.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 10.1.1.2 56 msec 72 msec 44 msec
2 10.2.2.3 100 msec 96 msec 132 msec
3 10.3.3.4 188 msec * 160 msec
R1#

And let’s see what is in the log now;

R1#show logging | begin Log Buffer
Log Buffer (4096 bytes):

*Mar 1 03:45:40.183: IP: tableid=0, s=10.1.1.2 (FastEthernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar 1 03:45:40.183: IP: s=10.1.1.2 (FastEthernet0/0), d=1.1.1.1, len 56, rcvd 4
*Mar 1 03:45:40.183: ICMP type=11, code=0
*Mar 1 03:45:40.259: IP: tableid=0, s=10.1.1.2 (FastEthernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar 1 03:45:40.259: IP: s=10.1.1.2 (FastEthernet0/0), d=1.1.1.1, len 56, rcvd 4
*Mar 1 03:45:40.259: ICMP type=11, code=0
*Mar 1 03:45:40.303: IP: tableid=0, s=10.1.1.2 (FastEthernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar 1 03:45:40.303: IP: s=10.1.1.2 (FastEthernet0/0), d=1.1.1.1, len 56, rcvd 4
*Mar 1 03:45:40.303: ICMP type=11, code=0
*Mar 1 03:45:40.399: IP: tableid=0, s=10.2.2.3 (FastEthernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar 1 03:45:40.399: IP: s=10.2.2.3 (FastEthernet0/0), d=1.1.1.1, len 56, rcvd 4
*Mar 1 03:45:40.403: ICMP type=11, code=0
*Mar 1 03:45:40.495: IP: tableid=0, s=10.2.2.3 (FastEthernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar 1 03:45:40.495: IP: s=10.2.2.3 (FastEthernet0/0), d=1.1.1.1, len 56, rcvd 4
*Mar 1 03:45:40.499: ICMP type=11, code=0
*Mar 1 03:45:40.631: IP: tableid=0, s=10.2.2.3 (FastEthernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar 1 03:45:40.631: IP: s=10.2.2.3 (FastEthernet0/0), d=1.1.1.1, len 56, rcvd 4
*Mar 1 03:45:40.631: ICMP type=11, code=0
*Mar 1 03:45:40.819: IP: tableid=0, s=10.3.3.4 (FastEthernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar 1 03:45:40.819: IP: s=10.3.3.4 (FastEthernet0/0), d=1.1.1.1, len 56, rcvd 4
*Mar 1 03:45:40.819: ICMP type=3, code=3
*Mar 1 03:45:43.975: IP: tableid=0, s=10.3.3.4 (FastEthernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar 1 03:45:43.975: IP: s=10.3.3.4 (FastEthernet0/0), d=1.1.1.1, len 56, rcvd 4
*Mar 1 03:45:43.975: ICMP type=3, code=3

Looking at the output above, we can see that for each hop in the path, we receive three type 11 code 0 messages. For the destination 10.3.3.4, we receive only two type 3 code 3 messages, the third response is completely missing.

I add UDP traffic to my access-list and check the debug output again for the last hop.

Extended IP access list 100
10 permit icmp any any
20 permit udp any any

Looks like we have sent the following three datagrams;

IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via FIB
IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 28, sending
UDP src=49340, dst=33440

IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via FIB
IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 28, sending
UDP src=49341, dst=33441

IP: tableid=0, s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), routed via FIB
IP: s=1.1.1.1 (local), d=4.4.4.4 (FastEthernet0/0), len 28, sending
UDP src=49342, dst=33442

These look fine, so the problem can not be here at the source. Let’s investigate further.

I want to see what kind of debug output we can on our destination, R4, so I add the following config;

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#access-list 100 permit icmp any any
R4(config)#access-list 100 permit udp any any

R4#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100

I run the trace again from R1 and an see the following debug output on R4;

When I go over this I can see that all three UDP packets arrive, each with one higher destination and source port number.

Yet, the ICMP Type 3 code 3 message is.. *cue dramatic music, move camera to close-up*

Never sent out…

So, it seems we have identified the perpetrator. It is R4.

The Motive
=========

Now I have identified exactly where this is going wrong, I will try to discover why.

The first thing I notice is that the Type 11 messages seem to go out fine, but somehow there is a problem with outgoing Type 3 messages.

This gets me thinking, are these messages limited somehow by default? Is there rate limiting like you have for some other kinds of services. (DHCP Snooping comes to mind)

It seems kind of silly, three outgoing type 3 message is the default for any device that is the destination of a trace-route.

Yet …

R4(config)#ip icmp ?
rate-limit rate limit ICMP messages generated
redirect Redirect type

No, could they really.. ?

Let’s try configuring a higher amount. I’m unsure what the default setting is here.

R4(config)#ip icmp rate-limit ?
unreachable ICMP type 3, Destination Unreachable

R4(config)#ip icmp rate-limit unreachable ?
<1-4294967295> Once per milliseconds
DF code 4, fragmentation needed and DF set

R4(config)#ip icmp rate-limit unreachable 50

And now let’s try the trace-route again on R1 *fingers crossed*

R1#traceroute 4.4.4.4 source 1.1.1.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 10.1.1.2 60 msec 124 msec 76 msec
2 10.2.2.3 124 msec 140 msec 92 msec
3 10.3.3.4 216 msec 196 msec 256 msec
R1#

Amazing.

The Conclusion
=============

It seems this Cisco Router (and who knows which others) have a default ICMP rate-limit that is too low and this might cause issues when troubleshooting by using Trace-Route.

On the router I’m testing this, the following IOS is running;

R4#sh ver
Cisco IOS Software, 2600 Software (C2691-ADVENTERPRISEK9-M), Version 12.4(15)T14, RELEASE SOFTWARE (fc2)

Which is the most recent T release I could find, You would think this would be solved in more recent releases.

I checked some show commands and found the command “Show ip icmp rate-limit” which is exactly what we need in this case.

The current output is;

A rate limit of 50, just like I configured earlier. Now I will remove that configuration and will check again to find out the default value.

R4(config)#no ip icmp rate-limit unreachable

And another “Show ip icmp rate-limit” shows..

What, it does not show anything? Okay, I’m used to Cisco devices showing nothing in the actual configuration if set to its default values, but this is some output that would actually be nice to see.

In the previous screenshot, I can see a rate-limit of 20 for “All other unreachables” but this still does not tell me anything. 20 per milli-second would still be plenty of our tests.

Another fun thing I just noticed, I went back to R1 and did the traceroute again after removing the configuration on R4 like you can see before.

The traceroute is still working perfectly, there is no lost packet on the last hop.

So it seems that even when removing the rate-limit on R4, something was left in its configuration.

Let’s try rebooting R4;

R4#wr
Building configuration…
[OK]
R4#reload
Proceed with reload? [confirm]

And ..

It crashed. The router crashed on boot.

Now, this might be because I’m using GNS3, so I’m very curious to see what effect this could have on a production router !

After I try again a few times, the router boots but the startup config is now lost. Not entirely sure if this is related but it’s all very suspicious!

I think now is a good time to stop my investigation and ask you, the reader, to comment on this update with any experience, insight or questions you might have about this.

This was very interesting to try out and I can not wait to get to troubleshoot more complex stuff .

References:
ICMP Types.

BGP LAB #1: Default Routing, Route Filtering and Floating Static Routes

In this LAB I will configure basic BGP with default routing and also touch on subjects such as verification, route filters and floating static routes.

Topology:

Initial Configuration:

HQ_Office
=========
interface Loopback0
ip address 192.168.0.1 255.255.255.0

interface Loopback1
ip address 192.168.1.1 255.255.255.0

interface Serial1/1
ip address 10.0.0.2 255.255.255.252
serial restart-delay 0

interface Serial1/2
ip address 172.16.0.2 255.255.255.252
serial restart-delay 0

ISP_1
=====
interface Loopback0
ip address 10.1.1.1 255.255.255.0

interface Serial1/1
ip address 10.0.0.1 255.255.255.252
serial restart-delay 0

ISP_2
=====
interface Loopback0
ip address 172.16.1.1 255.255.255.0

interface Serial1/2
ip address 172.16.0.1 255.255.255.252
serial restart-delay 0

First up is the configuration of the BGP router process with an AS number (Autonomous System) and its neighbours. In BGP neighbours are statically assigned with a reference to the remote AS.
The two ISP routers will become neighbours of the HQ router, but not of eachother.

HQ_Office(config)#router bgp 100
HQ_Office(config-router)#neighbor 10.1.1.1 remote-as 200
HQ_Office(config-router)#neighbor 172.16.0.1 remote-as 300

You can see the syntax is “neighbour remote-interface-IP remote-as remote-as-number“

Like other router protocols, you must also chose which networks to advertise. I will only add the loopback interfaces to these “network” commands, because we already have static neighbourships on the others.

HQ_Office(config-router)#network 192.168.0.1
HQ_Office(config-router)#network 192.168.1.1

Debug BGP All has been turned on on the HQ router so we can see what kind of output we get once the neighbourships are configured. After enabling the debugging, I can already see peering attempts go out. They fail however, because the other side is not yet configured.

*Mar 1 01:07:24.975: BGP: 172.16.0.1 open active, local address 172.16.0.2
*Mar 1 01:07:25.007: BGP: 172.16.0.1 open failed: Connection refused by remote host, open active delayed 27179ms (35000ms max, 28% jitter)

I will now configure the same for routers ISP_1 and 2.

The neighbour statement on ISP_1

ISP_1(config)#router bgp 200
ISP_1(config-router)#neighbor 10.0.0.2 remote-as 100

And now I’m seeing the following output on the HQ Router. It looks like our neighbourship has formed with 10.0.0.1.

*Mar  1 01:09:54.859: BGP: 10.0.0.1 went from Idle to Active
*Mar 1 01:10:17.459: BGP: 10.0.0.1 passive open to 10.0.0.2
*Mar 1 01:10:17.459: BGP: 10.0.0.1 went from Active to Idle
*Mar 1 01:10:17.459: BGP: 10.0.0.1 went from Idle to Connect

After these messages, it starts exchanging its BGP information, something I do not know that much about yet ..

*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcv message type 1, length (excl. header) 26
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar 1 01:10:17.467: BGP: 10.0.0.1 went from Connect to OpenSent
*Mar 1 01:10:17.467: BGP: 10.0.0.1 sending OPEN, version 4, my as: 100, holdtime 180 seconds
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcv OPEN w/ OPTION parameter len: 16
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has CAPABILITY code: 1, length 4
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has CAPABILITY code: 128, length 0
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 1 01:10:17.467: BGP: 10.0.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has CAPABILITY code: 2, length 0
*Mar 1 01:10:17.467: BGP: 10.0.0.1 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 10.0.0.1 rcvd OPEN w/ remote AS 200
*Mar 1 01:10:17.467: BGP: 10.0.0.1 went from OpenSent to OpenConfirm
*Mar 1 01:10:17.467: BGP: 10.0.0.1 send message type 1, length (incl. header) 45
*Mar 1 01:10:17.495: BGP: 10.0.0.1 went from OpenConfirm to Established
*Mar 1 01:10:17.495: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up

But, you can see, at the end of all this, it says that the neighbour is up. Let’s also configure out network statement on ISP_1 now.

ISP_1(config-router)#network 10.1.1.0 mask 255.255.255.0

Okay, so far the HQ and ISP_1 router are configured, let’s take a look at how the output of our “show bgp neighbours” is like at the moment.

HQ_Office#sh bgp nei
BGP neighbor is 10.0.0.1, remote AS 200, external link
BGP version 4, remote router ID 10.1.1.1
BGP state = Established, up for 00:06:03
Last read 00:00:03, last write 00:00:03, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 1 1
Keepalives: 9 9
Route Refresh: 0 0
Total: 11 11
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast
BGP table version 2, neighbor version 2/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 1 1 (Consumes 52 bytes)
Prefixes Total: 1 1
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 1
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
Total: 0 0
Number of NLRIs in the update sent: max 1, min 1

Connections established 1; dropped 0
Last reset never
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.0.0.2, Local port: 179
Foreign host: 10.0.0.1, Foreign port: 46649
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x45F068):
Timer Starts Wakeups Next
Retrans 10 0 0x0
TimeWait 0 0 0x0
AckHold 10 1 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0

iss: 3073044154 snduna: 3073044418 sndnxt: 3073044418 sndwnd: 16121
irs: 18814913 rcvnxt: 18815182 rcvwnd: 16116 delrcvwnd: 268

SRTT: 221 ms, RTTO: 832 ms, RTV: 611 ms, KRTT: 0 ms
minRTT: 20 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 20 (out of order: 0), with data: 11, total data bytes: 268
Sent: 13 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 11, total data bytes: 263
Packets received in fast path: 0, fast processed: 0, slow path: 0
Packets send in fast path: 0
fast lock acquisition failures: 0, slow path: 0

BGP neighbor is 172.16.0.1, remote AS 300, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Active
Last read 00:15:07, last write 00:15:07, hold time is 180, keepalive interval is 60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast
BGP table version 2, neighbor version 0/0
Output queue size: 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 1 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0

Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0

Connections established 0; dropped 0
Last reset never
No active TCP connection

Wow, that is alot more output than the equivalent commands of, for example, EIGRP. When glancing over it, you should notice that for the neighbour  10.0.0.1, the relationship is Established, but for the other neighbour, 172.16.0.1, the state is Active. Active sounds good, but it actually means that is is Actively Searching for its neighbour.

This is all very exciting so let’s move on and configure BGP on ISP_2.

ISP_2(config)#router bgp 300
ISP_2(config-router)#neighbor 172.16.0.2 remote-as 100
ISP_2(config-router)#network 172.16.1.0 mask 255.255.255.0

And now I”m seeing similar output on the HQ router for this neighbourship.

*Mar 1 01:24:53.543: BGP: 172.16.0.1 open active, local address 172.16.0.2
*Mar 1 01:24:53.579: BGP: 172.16.0.1 went from Active to OpenSent
*Mar 1 01:24:53.579: BGP: 172.16.0.1 sending OPEN, version 4, my as: 100, holdtime 180 seconds
*Mar 1 01:24:53.591: BGP: 172.16.0.1 send message type 1, length (incl. header) 45
*Mar 1 01:24:53.623: BGP: 172.16.0.1 rcv message type 1, length (excl. header) 26
*Mar 1 01:24:53.627: BGP: 172.16.0.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar 1 01:24:53.631: BGP: 172.16.0.1 rcv OPEN w/ OPTION parameter len: 16
*Mar 1 01:24:53.631: BGP: 172.16.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has CAPABILITY code: 1, length 4
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar 1 01:24:53.635: BGP: 172.16.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has CAPABILITY code: 128, length 0
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar 1 01:24:53.635: BGP: 172.16.0.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has CAPABILITY code: 2, length 0
*Mar 1 01:24:53.635: BGP: 172.16.0.1 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 172.16.0.1 rcvd OPEN w/ remote AS 300
*Mar 1 01:24:53.635: BGP: 172.16.0.1 went from OpenSent to OpenConfirm
*Mar 1 01:24:53.635: BGP: 172.16.0.1 went from OpenConfirm to Established
*Mar 1 01:24:53.635: %BGP-5-ADJCHANGE: neighbor 172.16.0.1 Up

It looks like the process goes something like Idle -> Active -> OpenSent (Sends ‘Open’) -> (Receive ‘Open‘) -> OpenConfirm -> Established. And it looks like the ‘Open’ message carries alot of information about the neighbouring router’s BGP configuration. I will have to get deeper into this, later on.

The basic BGP configuration for all three routers is now done, Let’s check out the HQ router’s routing table with the command “show ip route“.

HQ_Office#sh 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

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.0/30 is directly connected, Serial1/2
B 172.16.1.0/24 [20/0] via 172.16.0.1, 00:03:54
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.1.1.0/24 [20/0] via 10.0.0.1, 00:13:25
C 10.0.0.0/30 is directly connected, Serial1/1
C 192.168.0.0/24 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, Loopback1

It looks like we have ‘B’ routes for the ISP router’s loopback interfaces as intended. Further verification can be done with the command “show bgp“.

We have a BGP Table Version of 3 and we can see the networks and through which next hop they are reachable.
Now let’s make a change and see if anything happens to the  Table Version counter.

I will shutdown the loopback interface on ISP_1.

ISP_1(config)#int lo 0
ISP_1(config-if)#shut

*Mar 1 01:34:21.747: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Mar 1 01:34:22.747: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down

And another “show bgp” on the HQ router:

There you go, the shutdown interface’s network has disappeared and the Table Version‘s counter has gone up by one. I’ll bring ISP_1’s loopback interface back up.

ISP_1(config-if)#no shut
ISP_1(config-if)#
*Mar 1 01:37:21.151: %LINK-3-UPDOWN: Interface Loopback0, changed state to up
*Mar 1 01:37:22.151: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
ISP_1(config-if)#

If we now take a look at ISP_2’s routing table, we can see the following;

There seems to be a route that belongs to the ISP_1 network, what is it doing on the ISP_2 router? I guess our HQ router advertised a route belonging to a different ISP and because we have taken no steps to prevent this kind of behavior, the ISP_2 router has gone ahead and added this route to its routing table!

The solution that we will implement is Route Filtering.

On the HQ router, we will configure an access-list that will allow the routes for 192.168.0.0 and 192.168.1.0 to be advertised. As there is an implicit deny at the end of every access-list, the other routes’ advertisements will be blocked.

HQ_Office(config)#access-list 1 permit 192.168.0.0 0.0.1.255

I will now apply this access list in our BGP router process’ neighbour statements with the “distribute-list” keyword.

HQ_Office(config)#router bgp 100

HQ_Office(config-router)#neighbor 10.0.0.1 distribute-list ?
<1-199> IP access list number
<1300-2699> IP access list number (expanded range)
WORD IP Access-list name

HQ_Office(config-router)#neighbor 10.0.0.1 distribute-list 1 ?
in Filter incoming updates
out Filter outgoing updates

HQ_Office(config-router)#neighbor 10.0.0.1 distribute-list 1 out
HQ_Office(config-router)#neighbor 172.16.0.1 distribute-list 1 out

The access-list 1 has been used to filter Outgoing Updates.

Before we can see any changes, we must first clear the BGP process on the HQ router with the command “Clear ip BGP *”

HQ_Office#clear ip bgp *

For reference, here is the output from the “debug ip bgp all” after clearing the bgp process.

Let’s see if our route filter has worked, “Show ip route” on ISP_2 go!

Yes sir, the loopback networks from the other ISP are no longer showing up as intended!

Now, the HQ router is the border router for its network and has a connection with two different ISPs. We will implement floating static routes that will use ISP_1 as the primary provider and ISP_2 as the backup.

This can be done by specifying a lower metric route for ISP_1 on the HQ router and a higher one for ISP_2 with the command “ip route“.

HQ_Office(config)#ip route 0.0.0.0 0.0.0.0 10.0.0.1 210
HQ_Office(config)#ip route 0.0.0.0 0.0.0.0 172.16.0.1 220

With this configured, this is how our routing table looks on the HQ router:

You can see that there now is a gateway of last resort pointing to 10.0.0.1 with a distance metric of 210. If this route fails, it will be replaced by the one to 172.16.0.1 with a distance metric of 220.

I will shut down ISP_1’s interface;

ISP_1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ISP_1(config)#int se 1/1
ISP_1(config-if)#shut
ISP_1(config-if)#
*Mar 1 02:24:16.271: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Down Interface flap
ISP_1(config-if)#
*Mar 1 02:24:18.243: %LINK-5-CHANGED: Interface Serial1/1, changed state to administratively down
*Mar 1 02:24:19.243: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1, changed state to down
ISP_1(config-if)#

And the HQ router is now showing ..

A default route to 172.16.0.1 as intended! So that is working aswell.

You can also configure these primary and backup default routes by configuring an “ip default-network ip-address” on the HQ router and then have a static route pointing to the backup path, which is ISP_2.

References:
Official Cisco LAB Guide
Border Gateway Protocol
Configuring BGP

IP SLA LAB #1: Multiple routes

In this lab I will explore using IP SLA probes to decide which route to take towards a remote server.

Topology:

Initial Configuration:

All routers will be neighbors through EIGRP AS 10. I have chosen for this configuration because we are focusing on IP SLA in this lab, not routing protocols. Each router has been set up with the interface IP addresses you can see in the topology. The Client and Server objects are actually routers with a different symbol. They too participate in EIGRP.

I have used the same  Tcl scripting as in my previous updates, to test inter-connectivity of my base configuration; Everything is working and can communicate with each other.

CLIENT(tcl)#foreach address {
+>10.1.1.50
+>10.1.2.3
+>10.1.2.1
+>10.1.3.4
+>10.1.3.2
+>1.1.1.1
+>1.1.1.3
+>2.2.2.2
+>2.2.2.3
+>192.168.1.50
+>192.168.1.1
+>} { ping $address re 2
+>}

So my objective is;

1. Configure IP SLA to test connectivity over the two ISP networks. If ISP 1 fails, communication should fail-over to ISP 2.

Now I will configure the IP SLA probe on the Branch Router. This is going to be an ICMP Echo probe which will be pointed at a destination in the ISP network, represented by a loopback interface on both router ISP_1 and ISP_2.

ISP_1 Loopback 10: 50.0.0.1 255.255.255.0
ISP_2 Loopback 10: 100.0.0.1 255.255.255.0

The probe will be created with the command “IP SLA 10“, the number 10 being its operation number. Further it will be configured as an ICMP-ECHO towards 50.0.0.1 with a frequency of every 10 seconds, a lifetime of forever and a start-time of now.

Branch_Office(config)#ip sla 10
Branch_Office(config-ip-sla)#icmp-echo 50.0.0.1
Branch_Office(config-ip-sla-echo)#frequency 10
Branch_Office(config-ip-sla-echo)#exit
Branch_Office(config)#ip sla schedule 10 life forever start-time now

More information about the probe we configured can be seen with the command “show ip sla configuration 10”

You can also see some statistics about the probe with the command “show ip sla statistics“.

Here you can see, for example, the start time of the probe, how many times it succeeded and failed and its response time (RTT).

To enable tracking for our IP SLA probe towards 50.0.0.1 (To see if ISP_1 WAN link is OK), I will use the command “track 1 rtr 10 reachability“. Note that the command in later IOS versions will be “Track 1 ip sla 10”

Branch_Office(config)#track 1 rtr 10 reachability
Branch_Office(config-track)#delay down 10 up 1
Branch_Office(config-track)#exit

I’ve additionally configured it with a delay down of 10 seconds, meaning the remote ip address has to be unreachable for 10 seconds before any action is taken.

After configuring the above, you can have the router automatically add or remove static routes with the command “ip route source destination metric track 1”

Branch_Office(config)#ip route 0.0.0.0 0.0.0.0 10.1.2.1 2 track 1

I’ve given this default route a metric of 2 and it’s connected to “track 1“. As 50.0.0.1 is reachable, the static route is showing up in our routing table.

Branch_Office#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via “static”, distance 2, metric 0, candidate default path
Routing Descriptor Blocks:
* 10.1.2.1
Route metric is 0, traffic share count is 1

To test proper functioning, I will also add an IP SLA probe for the backup path’s 100.0.0.1 IP address.

Branch_Office(config)#ip sla 20
Branch_Office(config-ip-sla)#icmp-echo 100.0.0.1
Branch_Office(config-ip-sla-echo)#freq
Branch_Office(config-ip-sla-echo)#frequency 10
Branch_Office(config-ip-sla-echo)#exit

Branch_Office(config)#track 2 rtr 20 reachability
Branch_Office(config-track)#delay down 10 up 1
Branch_Office(config-track)#exit
Branch_Office(config)#ip route 0.0.0.0 0.0.0.0 10.1.3.2 3 track 2

And now we can check if the second default route replaces the first one if the IP SLA 10 probe fails:

ISP_1#conf t
ISP_1(config)#int lo 10
ISP_1(config-if)#shut
*Mar 1 06:21:20.890: %LINK-5-CHANGED: Interface Loopback10, changed state to administratively down
*Mar 1 06:21:21.890: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10, changed state to down

And did it change on the branch router?

Branch_Office#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via “static”, distance 3, metric 0, candidate default path
Routing Descriptor Blocks:
* 10.1.3.2
Route metric is 0, traffic share count is 1

It sure did, traffic is now going over the ISP_2 router as intended!
Taking another look at our probe statistics, we can see that probe 10 has failed and that probe 20 is successful.

Branch_Office#sh ip sla stat

Round Trip Time (RTT) for Index 10
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *06:18:52.050 UTC Fri Mar 1 2002
Latest operation return code: Timeout
Number of successes: 265
Number of failures: 39
Operation time to live: Forever

Round Trip Time (RTT) for Index 20
Latest RTT: 40 milliseconds
Latest operation start time: *06:18:43.430 UTC Fri Mar 1 2002
Latest operation return code: OK
Number of successes: 12
Number of failures: 0
Operation time to live: Forever

So there you have it, basic IP SLA configuration.
As always, constructive criticism is encouraged!

References:
IP SLA Track config example.
Object tracking for static route.

Path Control: Implementation and Verification.

In this update I will explore how to implement and verify path control.

Topology

Base Config Overview can be downloaded here.

What is Path Control?

Path Control can be used to change a default IP routing decision. You can use Policy Based Routing (PBR) to selectively cause packets to take different paths based on source address, protocol type or application type. Effectively overriding the router’s normal routing behavior.

Configuring PBR involves configuring a route map with match and set commands and then applying the route map to the interface.

I will be implementing the following policies:

1. All traffic coming from R4 Lo4 to R1 Lo1, must take the path R3 -> R2 -> R1.
2. All traffic coming from R4 Lo5 to R1 Lo1, must take the path R3 -> R1.

Before we move on, let’s first take a look at the current path selection for this traffic.

R4#traceroute 192.168.1.1 source 192.168.4.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 172.16.34.3 28 msec 28 msec 16 msec
2 172.16.23.2 32 msec 20 msec 20 msec
3 172.16.12.1 32 msec * 28 msec

R4#traceroute 192.168.1.1 source 192.168.4.129

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 172.16.34.3 44 msec 36 msec 32 msec
2 172.16.23.2 28 msec 20 msec 20 msec
3 172.16.12.1 32 msec * 32 msec
R4#

We can see both flows go R3 -> R2 -> R1. If you look at the topology above, you can see that this is because these routers are using a faster link, thus it is the preferred path.

You can verify this by looking at  the topology information on R3.

R3#sh ip eigrp topology 192.168.1.0
IP-EIGRP (AS 1): Topology entry for 192.168.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21152000
Routing Descriptor Blocks:
172.16.23.2 (Serial0/2), from 172.16.23.2, Send flag is 0x0
Composite metric is (21152000/20640000), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 45000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
172.16.13.1 (Serial0/1), from 172.16.13.1, Send flag is 0x0
Composite metric is (40640000/128256), Route is Internal
Vector metric:
Minimum bandwidth is 64 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

You can see that the route over Serial 0/2 has a lower feasible distance, ergo it will be the preferred route.

So let’s manipulate this routing decision with Policy Based Routing.

First I will configure an Access-list on R3 for the traffic coming from R4 Lo5

R3#sh access-lists
Extended IP access list PBRACL
10 permit ip 192.168.4.128 0.0.0.127 192.168.1.0 0.0.0.255

And then I will create a route-map that will match the access-list and will change the next-hop interface to R1’s instead of R2.

R3#sh route-map
route-map R3->R1, permit, sequence 10
Match clauses:
ip address (access-lists): PBRACL
Set clauses:
ip next-hop 172.16.13.1
Policy routing matches: 0 packets, 0 bytes

Okay, that is looking good. There have not yet been any matches because it has not yet been assigned to an interface. We’ll do that now:

R3#sh run int se 1/1
Building configuration…

Current configuration : 174 bytes
!
interface Serial1/1
description R3 –> R4
bandwidth 64
ip address 172.16.34.3 255.255.255.248
ip policy route-map R3->R1
serial restart-delay 0
clock rate 64000
end

Okay, now let’s verify the proper operation of our new route-map.
We can use “debug ip policy” on R3 to identify the traffic being matched by our route-map.

First I’ll configure two access-list to match the traffic from Both R4 Lo4 and Lo5.

 R3(config)#access-list 1 permit 192.168.4.0 0.0.0.255

And then enable the debugging.

R3# debug ip policy 1
Policy routing debugging is on for access list 1

Running a trace from Lo4 …

R4#traceroute 192.168.1.1 source 192.168.4.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 172.16.34.3 16 msec 28 msec 20 msec
2 172.16.23.2 28 msec 20 msec 20 msec
3 172.16.12.1 32 msec * 32 msec

On R3 I can see the packets being forwarded normally:

R3#
*Mar 1 01:26:37.611: IP: s=172.16.12.1 (Serial0/1), d=192.168.4.1, len 56, FIB policy rejected(no match) – normal forwarding
R3#
*Mar 1 01:26:40.643: IP: s=172.16.12.1 (Serial0/1), d=192.168.4.1, len 56, FIB policy rejected(no match) – normal forwarding

Now let’s try Lo5:

R4#traceroute 192.168.1.1 source 192.168.4.129

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 172.16.34.3 36 msec 32 msec 20 msec
2 172.16.13.1 28 msec * 24 msec

Looks like that traffic is taking the intended path! What about our debug output on R3?

*Mar 1 01:44:17.947: IP: s=192.168.4.129 (Serial1/1), d=192.168.1.1, len 28, FIB policy match
*Mar 1 01:44:17.947: IP: s=192.168.4.129 (Serial1/1), d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed
*Mar 1 01:44:17.971: IP: s=192.168.4.129 (Serial1/1), d=192.168.1.1, len 28, FIB policy match
*Mar 1 01:44:17.975: IP: s=192.168.4.129 (Serial1/1), d=192.168.1.1, g=172.16.13.1, len 28, FIB policy routed

Perfect, we can see the policy being matched and our traffic being rerouted.

R3#show route-map
route-map R3->R1, permit, sequence 10
Match clauses:
ip address (access-lists): PBRACL
Set clauses:
ip next-hop 172.16.13.1
Policy routing matches: 3 packets, 96 bytes

And the counters on R3’s route-map are going up.
We have successfully implemented and verified Path Control.

References:
Route-maps Configuration.
IP Access-lists.
Cisco Policy Based Routing.

EIGRP/OSPF LAB: The Merger

In this update I will explore how to merge an existing OSPF network with an existing EIGRP network and also touch on some other subjects which you can read about in the objectives below.

Scenario:

Company A has bought Company B and must merge its network into its own. Company A runs the EIGRP routing protocol and Company B runs the OSPF routing protocol. The engineer will also need to take several other objectives into account such as route summarization, redistribution and the actual connection between the two companies over a leased line.

This lab comes with different objectives that we’ll have to research and try to complete.

Topology:

Preliminary configuration:

1. Configure all interfaces and the Frame Relay connection.
2. Configure all Loopback interfaces on each router.
3. Configure EIGRP AS 10 for Company A.
4. Configure OSPF 10 for Company B.
5. Configure OSPF router ID’s for Company B.

Objectives:

1. Before starting, verify proper operations for each network with the use of a Tcl script.
2. Summarize the loopback networks on R2 as efficient as possible.
3. Investigate and implement authentication between R3 & R4.
4. Redistribute OSPF routes into the EIGRP network.

Instead of going step by step through the preliminary configuration, I will just give you an overview of each router and its base configuration.

If you’d like to know how to configure Frame Relay, base EIGRP or OSPF settings, please refer to my previous updates.

Now that is done, we can get started on our objectives.

Objective one; verify proper operations for each network with the use of a Tcl script.

I will use TCL scripting to check if each configured IP address is reachable for each router.
I have prepared the Tcl script for both companies’ networks in notepad as you can see below. This will then be easy to paste into each router’s cli to test inter-connectivity.

Interestingly enough, after the running the script I saw that everything was reachable, except for R3 and R4 Se 0/0 interface, and this only from its own network or locally on the router itself.

I did some research and it seems that on a connection like this, even when pinging its own local interface, the ping address will still transverse the serial link, which is weird if you ask me!

This can be solved by adding a frame-relay map pointing to the router’s own serial interface IP address. After adding this (and advertising the 10.1.1.3/27 on R3) , the Tcl script was showing full connectivity across the grid for Company A.

Now let’s take a look at Company B. I’ve made the same mistake with the frame relay map on R4, so let’s fix that first.

And now to run the Company B script that I prepared.

Seems like everything is working as should so let’s move on to objective #2; Summarize the loopback networks on R2 as efficient as possible.
I explained how to do manual summarization in this update, so you can click that link if you’re interested in learning how to do this. For now I’ll just calculate the best summary and configure it. Here is how it will end up looking for R2:

On to Objective #3, authentication between R3 and R4.
This is kind of a vague objective, what kind of authentication do they want? I’ll just decide for myself and go with route authentication, also because we will have to set up an OSPF relationship between R3 and R4 anyway for the route redistribution in Objective #4 so I will do both objectives in one go.

First I’ve set up an OSPF relationship between R3 and R4. You can also see that R3 is now aware of the OSPF routes of Company B.

And now we can configure OSPF redistribution into our EIGRP network on R3 with the router process command “redistribute OSPF 10“. You should also set the default-metric with the command “default-metric 10000 100 255 1 1500” or your routes will not be redistributed properly.

We will need to also configure R4’s equivalent and redistribute the EIGRP routes into the OSPF or else they will not be able to communicate. You would need to set up an EIGRP relationship between R4 and R3, and then use the command “redistribute EIGRP 10” under R4’s OSPF router process.

We can test proper functioning by checking the routing table and general reachability with the Company B Tcl script on R2.

Routing Table:
Note how you can see the External (EX) routes showing up now.

And let’s test reachability to Company B’s network from R2 with the prepared script.

Great, that seems to work aswell. Now I just need to configure authentication.
OSPF Authentication is implemented with the router OSPF command “area 1 authentication message-digest” and the interface Serial 0/0 command “ip ospf message-digest-key 1 md5 myospfkey” on both R 3 and R4.

You can verify proper operation of this authentication by seeing that the neighbor relationships come back up after setting the key on both sides.

EIGRP LAB # 2 : Load Balancing

In this lab I will explore equal and unequal-cost load-balancing for EIGRP and will explain how EIGRP calculates its metric values.

Topology

R1 is the router we will be doing our tests from. It will connect through R2 and R3 to IP address 124.0.0.1 on the WAN.

Objective:

1. Set up the base EIGRP configuration.
2. Configure and verify load balancing
3. Configure and verify Unequal-cost load balancing.

I have done objective one, configured all the interfaces and set up the EIGRP AS, network commands and set up a default route for 124.0.0.0/24. Here’s the configuration so far.

Okay, so the base configuration is done. I have verified the EIGRP process with the “show ip eigrp neighbours” command.
For loadbalancing we will be concentrating on the connection between R1 and 124.0.0.1 on the WAN.

Let’s do a “show ip route” on R1 to see what the current situation is.

We have a Gateway of last resort for 124.0.0.0/24 as intended and it looks like we have two equal-cost routes for this same network, one going through R2 and one going through R3.

To get some more information on our default route, we can use the command “show ip eigrp topology 124.0.0.0 255.255.255.0“.

In the third line we can see that this router has 2 Successors (next hops) with a FD (Feasible distance) of 2323456.

You can also see the ‘composite metric‘ for both routes. (2323456/2297856) The first number is the Feasible distance (as seen from R1), the second number is the Reported Distance (as seen from the neighbour).

The metric calculation for EIGRP is based on something called the K-values.
These K values are a reference to the entries under “Vector metric” in the screenshot above.

The K values only act as multipliers or modifiers in the composite metric calculation.

K1 = default 1 – Bandwidth = This is used in the calculation by default.
K2 = default 0 – Load = Not participating in the calculation by default.
K3 = default 1 – Delay = This is used in the calculation by default.
K4 = default 0 – Reliability = Not participating in the calculation by default.
K5 = default 0 – MTU = Not participating in the calculation by default.

So in this calculation, we would use 1 x Bandwidth and 1 x Delay (values on the interface). Here’s the complete formula for EIGRP.

I’ve however come across some contradicting information that claims that K5, or MTU is or isn’t used in the EIGRP Metric calculation. In fact, if you look at the last part of the formula, K5/K4 + Reliability, you will see that if K5 is set to the default of zero, it will completely eliminate this part of the calculation as zero divided by anything is always zero.

So, you would think MTU is never used, however, I’ve found an interesting arcticle that explains it will still be used as a tie-breaker when dealing with equal cost paths even if K5 is set to zero.

If your router would have to ignore some equal-cost paths to the same destination (the number of equal-cost paths exceeds the value of the maximum-paths router configuration parameter), it ignores those with the lowest MTU metric.

When processing inbound EIGRP updates, the minimum of the MTU value in the inbound UPDATE packet and the interface MTU is stored in the EIGRP topology database. No MTU processing is done on the outbound updates. The MTU metric thus represents the minimum unidirectional MTU between the current router and the originating router.

How to verify Load Balancing

The default setting for Load Balancing under EIGRP is “per-destination”.
As we’re working with only one destination, we will still end up using one link for all traffic, so it is better to implement “per-packet” load-balancing.

To enable “per-packet” load-balancing we will need to check our CEF (Cisco Express Forwarding) settings. If this device did not use CEF, we would have to disable fast-switching on the interfaces with the interface command “no ip route-cache”

To check CEF for this route, use the command “show ip cef 124.0.0.1”

You can see here that per-destination sharing is enabled for these two routes.
To change this to “per-packet” use the interface command “ip load-sharing per-packet” on all interfaces that forward traffic to the destination.

R1#conf t
R1(config)#int fa 0/0
R1(config-if)#ip load-sharing per-packet
R1(config-if)#int fa 0/1
R1(config-if)#ip load-sharing per-packet

If you now enter the command “show ip cef 124.0.0.1” again, you can see that sharing is now per-packet based.

That’s it, We’ve configured and verified Equal-Cost Load Balancing.

On to objective 3, Configure and verify Unequal-cost load balancing.

To start this, I will higher the Delay value for R1, Fa 0/0 and R2, Fa 0/0 to make one of the links appear faster and therefor more preferred.

R1(config)#int fa 0/0
R1(config-if)#delay 5000
R1(config)#int fa 0/1
R1(config-if)#delay 5000

If you look at the EIGRP topology now, you can see one of the routes has a higher metric. This has as result that only the route via R3 is being used to forward traffic.

If we want to use multiple links that do not have the same metric for Load-Balancing, we need to use the router process command “variance x” where x is a multiplier for the lowest metric of the routes that you want to use.

So for example “Variance 2” would use routes with a metric between 2323456 and, twice that, 4646912. In this case it would allow our higher metric route via R2 to be used in Unequal-cost Load-Balancing for the route to 124.0.0.0/24.

R1#conf t
R1(config)#router eigrp 10
R1(config-router)#variance ?
<1-128> Metric variance multiplier

R1(config-router)#variance 2

And if we take another look at the EIGRP topology, we can see both the router via R3, and the higher metric route via R2, are being used.

Looking at the output from “Show ip cef 124.0.0.1“, we can see that both routes are being used, but the lower route has a higher traffic share, meaning that it will get to forward a bigger share of the traffic that is being Load-Balanced.

And with this, we have successfully implemented and verified Unequal-cost Load-Balancing.

References:
Variance
Influencing EIGRP Metrics

EIGRP LAB # 1 : Manual Summarization and Default Network Advertisement

In this lab I will practice manual summarization for EIGRP and also touch on configuring Default Network Advertisement. As you can see from the topology below, we are dealing with quite a few networks that will be the cause for an inefficient routing table.

The idea is to have all these networks summarized in as few routing entries as possible while still maintaining the same functionality.

Lab Topology:

The Loopback Interface on R1 represents an internet connection.
The Loopback interfaces on R2 and R3 represent remote networks.

Objectives:

1. Configure a Basic EIGRP configuration.
2. Configure and review EIGRP manual summarization.
3. Configure Default Network Advertisement.

Let’s start with the first Objective. “Configure a Basic EIGRP configuration“. I will not go through the entire base configuration step by step, you can check my previous updates for that if needed. Instead, here’s the configuration for all three routers that we are starting out with.

R1
==

interface Loopback0
ip address 172.31.1.1 255.255.255.0

interface FastEthernet0/0
ip address 192.168.100.1 255.255.255.248
duplex auto
speed auto

router eigrp 10
network 172.31.0.0
network 192.168.100.0
no auto-summary

R2
==

interface Loopback1
ip address 192.168.200.1 255.255.255.252

interface Loopback5
ip address 192.168.200.5 255.255.255.252

interface Loopback9
ip address 192.168.200.9 255.255.255.252

interface Loopback13
ip address 192.168.200.13 255.255.255.252

interface Loopback17
ip address 192.168.200.17 255.255.255.252

interface Loopback21
ip address 192.168.200.21 255.255.255.252

interface Loopback25
ip address 192.168.200.25 255.255.255.252

interface FastEthernet0/0
ip address 192.168.100.2 255.255.255.248
duplex auto
speed auto

interface FastEthernet0/1
ip address 10.1.1.2 255.255.255.248
duplex auto
speed auto

router eigrp 10
network 10.0.0.0
network 192.168.100.0
network 192.168.200.0
no auto-summary

R3
==

interface Loopback1
ip address 192.168.1.1 255.255.254.0

interface Loopback5
ip address 192.168.5.5 255.255.254.0

interface Loopback9
ip address 192.168.9.9 255.255.254.0

interface Loopback13
ip address 192.168.13.13 255.255.254.0

interface Loopback17
ip address 192.168.17.17 255.255.254.0

interface Loopback21
ip address 192.168.21.21 255.255.254.0

interface Loopback25
ip address 192.168.25.25 255.255.254.0

interface Loopback100
ip address 10.1.3.1 255.255.255.252

interface Loopback172
ip address 172.16.1.1 255.255.255.0

interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto

interface FastEthernet0/1
ip address 10.1.1.3 255.255.255.248
duplex auto
speed auto

router eigrp 10
network 10.0.0.0
network 172.16.0.0
network 192.168.0.0 0.0.31.255
no auto-summary

The first big difference from OSPF is that the “autonomous system” number must match on all routers that are to become neighbors with each other.
The “AN” number is configured with the global config command “Router EIGRP 10”

I have also disabled auto-summarization for EIGRP with the router config command “no auto-summary“.
EIGRP, like RIP, will summarize at the class-full boundary. Meaning that if you have a route for 10.1.3.0/24 , being a class A address, it will end up being advertised as 10.0.0.0/8
Disabling auto-summary will make it advertise as the classless network 10.1.3.0/24.

Some more explanation on EIGRP.

EIGRP stores its data in three tables.

1. Neighbor Table: Stores data about the neighboring routers, i.e. those directly accessible through directly connected interfaces
2. Topology Table: This table contains the aggregation of the routing tables gathered from all directly connected neighbors. For every destination, a successor and a feasible successor are identified and stored in the table if they exist. Every destination in the topology table can be marked either as “Passive“, which is the state when the routing has stabilized and the router knows the route to the destination, or “Active” when the topology has changed and the router is in the process of (actively) updating its route to that destination.
3. Routing table: Stores the actual routes to all destinations; the routing table is populated from the topology table with every destination network that has its successor and optionally feasible successor identified (if unequal-cost load-balancing is enabled using the variance command). The successors and feasible successors serve as the next hop routers for these destinations.

Now my base configuration is done, we will confirm EIGRP’s proper configuration with the command “show ip eigrp neighbours“.
Here is the output from R2.

R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.1.1.3 Fa0/1 10 01:53:10 48 288 0 3
0 192.168.100.1 Fa0/0 13 02:13:11 377 2262 0 9

In this output we can see that, for EIGRP AS 10, it has formed neighbor relationships with the devices connected on Fa0/0 and Fa0/1.
Another interesting command is “show ip eigrp topology” which shows you the network topology as learned from the device’s neighbours.

R2#sh ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(192.168.200.25)

Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status

P 10.1.3.0/30, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 10.1.1.0/29, 1 successors, FD is 281600
via Connected, FastEthernet0/1
P 192.168.100.0/29, 1 successors, FD is 281600
via Connected, FastEthernet0/0
P 192.168.8.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.12.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.0.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.4.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.24.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.16.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.20.0/23, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1
P 192.168.200.0/30, 1 successors, FD is 128256
via Connected, Loopback1
P 192.168.200.4/30, 1 successors, FD is 128256
via Connected, Loopback5
P 192.168.200.8/30, 1 successors, FD is 128256
via Connected, Loopback9
P 192.168.200.12/30, 1 successors, FD is 128256
via Connected, Loopback13
P 192.168.200.16/30, 1 successors, FD is 128256
via Connected, Loopback17
P 172.31.1.0/24, 1 successors, FD is 409600
via 192.168.100.1 (409600/128256), FastEthernet0/0
P 192.168.200.20/30, 1 successors, FD is 128256
via Connected, Loopback21
P 192.168.200.24/30, 1 successors, FD is 128256
via Connected, Loopback25
P 172.16.1.0/24, 1 successors, FD is 409600
via 10.1.1.3 (409600/128256), FastEthernet0/1

Okay, before I start trying to summarize all those routes for objective # 2, here’s the output of all three router’s routing tables for later reference and comparison.

R1#sh ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
D 172.16.1.0 [90/435200] via 192.168.100.2, 02:03:31, FastEthernet0/0
172.31.0.0/24 is subnetted, 1 subnets
C 172.31.1.0 is directly connected, Loopback0
192.168.200.0/30 is subnetted, 7 subnets
D 192.168.200.0 [90/409600] via 192.168.100.2, 02:23:31, FastEthernet0/0
D 192.168.200.4 [90/409600] via 192.168.100.2, 02:23:31, FastEthernet0/0
D 192.168.200.8 [90/409600] via 192.168.100.2, 02:23:31, FastEthernet0/0
D 192.168.200.12
[90/409600] via 192.168.100.2, 02:23:32, FastEthernet0/0
D 192.168.200.16
[90/409600] via 192.168.100.2, 02:23:32, FastEthernet0/0
D 192.168.200.20
[90/409600] via 192.168.100.2, 02:23:32, FastEthernet0/0
D 192.168.200.24
[90/409600] via 192.168.100.2, 02:23:33, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.1.3.0/30 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 10.1.1.0/29 [90/307200] via 192.168.100.2, 02:03:51, FastEthernet0/0
192.168.100.0/29 is subnetted, 1 subnets
C 192.168.100.0 is directly connected, FastEthernet0/0
D 192.168.12.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.8.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.24.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.4.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.20.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.0.0/23 [90/435200] via 192.168.100.2, 02:03:34, FastEthernet0/0
D 192.168.16.0/23 [90/435200] via 192.168.100.2, 02:03:35, FastEthernet0/0
R2#sh ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
D 172.16.1.0 [90/409600] via 10.1.1.3, 02:02:44, FastEthernet0/1
172.31.0.0/24 is subnetted, 1 subnets
D 172.31.1.0 [90/409600] via 192.168.100.1, 02:21:12, FastEthernet0/0
192.168.200.0/30 is subnetted, 7 subnets
C 192.168.200.0 is directly connected, Loopback1
C 192.168.200.4 is directly connected, Loopback5
C 192.168.200.8 is directly connected, Loopback9
C 192.168.200.12 is directly connected, Loopback13
C 192.168.200.16 is directly connected, Loopback17
C 192.168.200.20 is directly connected, Loopback21
C 192.168.200.24 is directly connected, Loopback25
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.1.3.0/30 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
C 10.1.1.0/29 is directly connected, FastEthernet0/1
192.168.100.0/29 is subnetted, 1 subnets
C 192.168.100.0 is directly connected, FastEthernet0/0
D 192.168.12.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.8.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.24.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.4.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.20.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.0.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
D 192.168.16.0/23 [90/409600] via 10.1.1.3, 02:02:47, FastEthernet0/1
R3#sh ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Loopback172
172.31.0.0/24 is subnetted, 1 subnets
D 172.31.1.0 [90/435200] via 10.1.1.2, 02:04:18, FastEthernet0/1
192.168.200.0/30 is subnetted, 7 subnets
D 192.168.200.0 [90/409600] via 10.1.1.2, 02:04:18, FastEthernet0/1
D 192.168.200.4 [90/409600] via 10.1.1.2, 02:04:18, FastEthernet0/1
D 192.168.200.8 [90/409600] via 10.1.1.2, 02:04:18, FastEthernet0/1
D 192.168.200.12 [90/409600] via 10.1.1.2, 02:04:19, FastEthernet0/1
D 192.168.200.16 [90/409600] via 10.1.1.2, 02:04:19, FastEthernet0/1
D 192.168.200.20 [90/409600] via 10.1.1.2, 02:04:19, FastEthernet0/1
D 192.168.200.24 [90/409600] via 10.1.1.2, 02:04:19, FastEthernet0/1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.3.0/30 is directly connected, Loopback100
C 10.1.1.0/29 is directly connected, FastEthernet0/1
192.168.100.0/29 is subnetted, 1 subnets
D 192.168.100.0 [90/307200] via 10.1.1.2, 02:04:20, FastEthernet0/1
C 192.168.12.0/23 is directly connected, Loopback13
C 192.168.8.0/23 is directly connected, Loopback9
C 192.168.24.0/23 is directly connected, Loopback25
C 192.168.4.0/23 is directly connected, Loopback5
C 192.168.20.0/23 is directly connected, Loopback21
C 192.168.0.0/23 is directly connected, Loopback1
C 192.168.16.0/23 is directly connected, Loopback17

Now let’s get summarizing. I will first make an overview for the loopbacks per router so I know which addresses are available.
Then after that I will look what can be done with the remaining addresses.

Okay, first up, R2. It looks like we have a range from 192.168.200.1 to 192.168.200.25.
To find out which mask we can use to summarize these routes with, we have to check which increment to use that will encompass everything from 1 to 25.

Draw the following chart.

128   64   32   16   8   4   2   1

Now check which number is big enough to hold everything from 1 to 25.
That would be 32 right? So draw the following.

128   64   32   16   8   4   2   1

1        1      1     0   0   0   0   0

Now consider the IP address we’re working with. We know nothing changes in the first three octets right? So we can be sure our subnet mask will look like 255.255.255.x where “x” is the number we’re looking for. Using the method from above, this means we’ll need to add 3 bits to our subnet mask.
( 3 x 8 1‘s + 3 1’s ).
This will give us a subnet mask of 255.255.255.224 or /27 in CIDR notation.

We now end up with the subnet 192.168.200.0/27 which has the host range from 192.168.200.1 to 192.168.200.30
Using the same calculation, we end up with 192.168.0.0/19 for R3.

Now to configure our manual summarization. This can be done with the interface command “ip summary-address eigrp 10 address mask” and should be configured on the interface where you want the summarization to happen.

Let’s do it.

R2(config)#int fa 0/0
R2(config-if)#ip summary-address eigrp 10 192.168.200.0 255.255.255.224
R2(config-if)#int fa 0/1
R2(config-if)#ip summary-address eigrp 10 192.168.200.0 255.255.255.224I’ve configured summarization on those interfaces and looks what happens:

*Mar 1 04:05:11.926: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.1.1.3 (FastEthernet0/1) is resync: summary configured

*Mar 1 04:06:47.706: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.1.1.3 (FastEthernet0/1) is resync: peer graceful-restart

Our router notices what we are up to and gracefully reinitializes the neighbourship so its neighbours can learn of the new route.
Let’s do the same for R3.

R3(config)#int fa 0/1
R3(config-if)#ip summary-address eigrp 10 192.168.0.0 255.255.224.0

Okay, let’s take a look now at our new and improved routing table.

R1#sh ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
D 172.16.1.0 [90/435200] via 192.168.100.2, 00:10:13, FastEthernet0/0
172.31.0.0/24 is subnetted, 1 subnets
C 172.31.1.0 is directly connected, Loopback0
192.168.200.0/27 is subnetted, 1 subnets
D 192.168.200.0 [90/409600] via 192.168.100.2, 00:10:13, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.1.3.0/30 [90/435200] via 192.168.100.2, 00:10:13, FastEthernet0/0
D 10.1.1.0/29 [90/307200] via 192.168.100.2, 00:10:14, FastEthernet0/0
192.168.100.0/29 is subnetted, 1 subnets
C 192.168.100.0 is directly connected, FastEthernet0/0
D 192.168.0.0/19 [90/435200] via 192.168.100.2, 00:06:21, FastEthernet0/0

Much much cleaner. But can we still ping all our loopbacks? Did I even do this right?
Oh god, let’s quickly test.

R1#traceroute 192.168.200.13

Type escape sequence to abort.
Tracing the route to 192.168.200.13

1 192.168.100.2 32 msec * 28 msec
R1#
R1#traceroute 192.168.1.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

1 192.168.100.2 52 msec 20 msec 20 msec
2 10.1.1.3 40 msec * 40 msec

Victory! You don’t see it here, but I tried reaching every loopback address and they all worked.

We still have the other addresses to check, but I plan to update this entry later on with that information.

For now, let’s do objective #3, Configure Default Network Advertisement.

This can be done with the command “IP Default-network address” which should be configured on R1.

R1(config)#ip default-network 172.31.0.0

R1 will then automatically advertise its new default route.
And the routing table on R2 says ..

R2#sh ip route eigrp
172.16.0.0/24 is subnetted, 1 subnets
D 172.16.1.0 [90/409600] via 10.1.1.3, 00:25:54, FastEthernet0/1
* 172.31.0.0/24 is subnetted, 1 subnets
D 172.31.1.0 [90/409600] via 192.168.100.1, 00:03:10, FastEthernet0/0
192.168.200.0/24 is variably subnetted, 8 subnets, 2 masks
D 192.168.200.0/27 is a summary, 00:26:27, Null0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.1.3.0/30 [90/409600] via 10.1.1.3, 00:25:54, FastEthernet0/1
D 192.168.0.0/19 [90/409600] via 10.1.1.3, 00:22:01, FastEthernet0/1

There’s our default route, the one with the *, indicating it’s a “candidate default”

And that’s a wrap!

Note to self: Come back and check the 10. and 172. routes! 

This lab has been based on chapter 2-3 of the Cisco CCNP Route LAB Manual.
Other references:
cbtnuggets.com
Enhanced Interior Gateway Routing Protocol.

GNS 3 – Configuring a Router as a Frame Relay Switch

If you have ever worked with GNS 3 you will know it comes with its own Frame Relay Switch that you can use in your topologies. However, as your labs become bigger and you use multiple FR switches, you might notice some odd behavior.

I will use this update to explain how to configure a normal router as a Frame-Relay switch in GNS 3.

This is the topology we’ll be working with.
The FrameRelay cloud you see is actually just another router with Serial interfaces.
To get it to appear as a cloud, you can right click its symbol and then chose ” Change Symbol“.

Here’s the initial configuration of R1, R2 and R3.

R1#sh run int se 1/1
Building configuration…

Current configuration : 89 bytes
!
interface Serial1/1
ip address 172.17.44.1 255.255.255.0
serial restart-delay 0
end

R2#sh run int se 1/2
Building configuration…

Current configuration : 89 bytes
!
interface Serial1/2
ip address 172.17.44.2 255.255.255.0
serial restart-delay 0
end

R3#sh run int se 1/3
Building configuration…

Current configuration : 89 bytes
!
interface Serial1/3
ip address 172.17.44.3 255.255.255.0
serial restart-delay 0
end

We only have the interface’s IP addressing configured so far.
Let’s first set up our Frame-Relay Switch (router).

I will enter the global config command “frame-relay switching” to enable  frame relay pvc switching on this device.

FrameRelay#conf t
FrameRelay(config)#frame-relay switching

And now to configure the interfaces.
There are a few interface commands that you need to enter.

“encapsulation frame-relay” – to make the interface use this kind of encapsulation.
“frame-relay lmi-type cisco” – To change the LMI type to Cisco. (This is the default)
“frame-relay intf-type dce” – To simulate the provider’s edge and provide clocking.
“Clock rate” – The clocking rate of the interface.
“frame-relay route” – The DLCI routing from one side to the other.

So let’s get started. We will configure R1 as a HUB, R2 and R3 will be spokes and will have no direct connection to each other.

FrameRelay#conf t
FrameRelay(config)#int se 1/1
FrameRelay(config-if)#encapsulation frame-relay
FrameRelay(config-if)#frame-relay lmi-type cisco
FrameRelay(config-if)#frame-relay intf-type dce
FrameRelay(config-if)#clock rate 64000
FrameRelay(config-if)#frame-relay route 102 interface serial 1/2 201
FrameRelay(config-if)#frame-relay route 103 interface serial 1/3 301
FrameRelay(config-if)#no shut

FrameRelay#conf t
FrameRelay(config)#int se 1/2
FrameRelay(config-if)#no shut
FrameRelay(config-if)#encapsulation frame-relay
FrameRelay(config-if)#clock rate 64000
FrameRelay(config-if)#frame-relay lmi-type cisco
FrameRelay(config-if)#frame-relay intf-type dce
FrameRelay(config-if)#frame-relay route 201 interface se 1/1 102

FrameRelay#conf t
FrameRelay(config-if)#int se 1/3
FrameRelay(config-if)#no shut
FrameRelay(config-if)#encapsulation frame-relay
FrameRelay(config-if)#clock rate 64000
FrameRelay(config-if)#frame-relay lmi-type cisco
FrameRelay(config-if)#frame-relay intf-type dce
FrameRelay(config-if)#frame-relay route 301 interface se 1/1 103

Note how we have an incoming frame-relay route that is then pointed towards an interface and its corresponding DLCI.

I will now further configure the interfaces on R1 through R3.

R1(config)#int se 1/1
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay map ip 172.17.44.2 102 broadcast
R1(config-if)#frame-relay map ip 172.17.44.3 103 broadcast

R2(config)#int se 1/2
R2(config-if)#encapsulation frame-relay
R2(config-if)#frame-relay map ip 172.17.44.1 201 broadcast
R2(config-if)#frame-relay map ip 172.17.44.3 201

R3(config)#int se 1/3
R3(config-if)#encapsulation frame-relay
R3(config-if)#frame-relay map ip 172.17.44.1 301 broadcast
R3(config-if)#frame-relay map ip 172.17.44.2 301

For more information on the frame-relay map command the broadcast keyword, please refer to a previous update.

Now to verify connectivity:

R1#ping 172.17.44.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.44.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/51/64 ms
R1#ping 172.17.44.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.44.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/66/92 ms
R1#

Okay, that’s looking good. There’s nothing more to it really.
Now you can set up routing or whatever else you’d like to test.

You can download this GNS 3 lab and the configurations here.

Reference: Cisco CCNP Route OCG.