Redistribution lab in GNS3/Dynamips

At first I had some trouble understanding route redistribution. I’ve tried getting better at it and now I have a solid understanding of it. Darren did some labs on his blog and I decided to give it a go as well. It is really good practice to create a lab of your own. Surprisingly it is more difficult than one would expect to create tricky scenarios, this is my go at it.

This is the topology.

The goal of the lab is to achieve full reachability and provide optimum routing. Since all links have the same bandwidth the fewer number of hops the better the route (try staying inside the routing domain if possible).

Follow these steps in order:

• Configure mutual redistribution between RIP and EIGRP on R5
• Configure mutual redistribution between OSPF and EIGRP on R3
• Configure mutual redistribution between OSPF and EIGRP on R2
• Configure mutual redistribution between RIP and OSPF on R7
• Configure mutual redistribution between RIP and OSPF on R8

All interfaces have been preconfigured with IP-adresses.

Download the topology and initial config here. Post your findings in the comments section.

 

Useful commands for CCIE lab exam

Was chatting with Darren at Darren’s CCIE mission yesterday. We started to discuss some of the commands we frequently used to check IP addresses etc. He thought I should do a post on it and here it is.

This first one I stumbled upon when I was going to type show ip prot but accidentally typed show ip port which turned out to be a good thing. This command show port mappings for different protocols used by IOS. If we get a task on lab to do filtering and can’t remember the port this can be really useful.

As you can see we can do an include to match on a port number or a protocol name.

The next command is one of the commands I use the most, show ip int brief | ex una. This will list all interfaces that have an IP address configured.

This is good but it will not tell us the netmask. If we have a troubleshooting task it is nice to check what IP’s are configured and if the correct netmask is used. Wit the next command we can check the netmask. Show ip int | i Internet.

If I want to verify reachability quickly I need to list all IP address configured on the devices. I use the show ip aliases command to do this. I paste the command in including a line feed on all devices and then hold alt down while I mark all the adresses.

I then put these addresses in a simple TCP script like below:

tclsh
foreach ip {
1.1.1.1
2.2.2.2
3.3.3.3
} { ping $ip}

This post should give you some tips on how to quickly discover IP addresses configured.

Filtering routes in EIGRP

EIGRP is often called a hybrid because it has some similar features to link state protocols and
also has distance vector features but the truth is that it is a distance vector protocol.

Even though it is distance vector it does have some nice features and today I will show a
couple of different ways of filtering in EIGRP.

We start out with this topology of four routers. You can download the topology and initial
configs from here.

Routers R1-R3 are running EIGRP in AS1 and routers R2-R4 are running RIP. R4 is announcing
a loopback in RIP. We configure R2 and R3 to redistribute from RIP to EIGRP and then
I will show how to filter the route.

R3 is configured exactly the same. Let’s see if we can see the prefix.

Indeed we can. Now let’s look at our filtering options.

We will start out with a regular distribute-list, everyone knows how to do this. We create
a standard access-list matching our prefix 4.4.4.0/24.

The prefix is now filtered. What if we want to block the prefix but only from R2 and allow
it in from R3? Either we could reuse the ACL and apply it to the interface in our distribute-list
but that might not be possible if R1-R2-R3 were connected on a common Ethernet segment.

We will use an extended access-list instead, the source will match on the gateway
announcing the prefix and the destination will be the prefix we want to filter.
So let’s block the prefix from R2. In this case we must use a numbered ACL, named ACL’s
don’t work for some reason.

That worked as expected. We now only see the route from R3.

The downside of using ACL’s is that we can’t match on prefix length. We need to use
a prefix-list for this. Lets try that. We will announce a /25 subnet from R4 and filter
any prefixes that are longer than /24.

Let’s check that it is reachable from R1.

Indeed it is. Now let’s filter this with a prefix-list.

Hey! Where did all my routes go?! We forgot to permit everything else with 0.0.0.0/0 le 32.
Now we have filtered the /25 but allowed everything else. If we want to be more
specific we can tie this distribute-list to the neighbors and even interfaces.

We can also filter using the distance command. How does that work? Remember that
the lower the AD the more trustworthy a route is. What happens if we set it to 255?
255 is the worst and routes with 255 won’t even be considered for installing into
the routing table. Let’s try that. We start by adding some prefixes on R2.
We add 2.2.2.0/24 on a loopback and then we create two static routes, one that is
redistributed via the network command and one that is redistributed via static.

Let’s look at the routing table of R1.

First notice that 22.22.22.0/24 is an internal route but 222.222.222.0 is an external.
If we redistribute static they will be external, that is well known. No as well known
is the possibility to create a static route and redistribute it via the network command.
If we do this we must route to an interface instead of a next-hop. The advantage is that we
can make the route look internal. Now let’s try some filtering. Unfortunately we can’t
change the AD for specific external routes, it’s all or nothing. Let’s say that we don’t
want to install any external paths. This is the current state of R1 and external routes.

We will set the AD to 255 for all external routes.

Now the routes are gone. What if we want to filter a specific internal route?

We set to distance to 255, we don’t care about the route source and we match ACL 1
which is the route that we want to filter.

There is one more type of filtering I would like to show and it is the route-map.
We will configure a route tag on R3 and match this tag on R1.

First we look at the route to 4.4.4.0/24 on R1, it is installed via R3.

Then we configure tagging on R3.

Now we configure a route-map that matches the tag and denies the prefix.

The route is now installed via R2 instead. The great thing with EIGRP is that we
can use the route-map with the distribute-list which we can’t with other
protocols.

We can even do more advanced things like matching on source-protocol or metric.

Now look at the routing table.

Only the routes that were not source from RIP are still in the routing table.

This post should give you a good understanding of what filtering is available
in EIGRP. The possibilities are endless!

EIGRP on secondary interfaces – quiz

When we configure EIGRP on interfaces that are not on the same subnet we will get a message from EIGRP telling us this. What happens if we configure EIGRP on secondary interfaces? Try this setup with two routers:

R1:

Primary IP: 163.19.1.1/24
Secondary IP: 163.19.11.1/24

R2:

Primary IP: 163.19.1.2/24
Secondary IP: 163.19.22.2/24

Then you enable EIGRP and run network 163.19.11.1 0.0.0.0 and 163.19.22.2 0.0.0.0 respectively on each router. Will they be able to form an adjacency? Post your answer in the comments section.

CCIE link #12

This post is by Brian McGahan on OSPF type 5 E1 vs E2 routes. It explains in detail how the OSPF state machine works and busts a few myths on OSPF metric calculation. Remember that OSPF prefers E1 over E2 regardless of metric. A common misconception is that E2 does not use cost to ASBR when calculating metric. Read the post to understand why this is wrong.

CCIE link #11

To be a CCIE we need a good grasp of switching and STP. This post by Petr Lapukhov (again) is one of the best I’ve ever seen on STP. This post describes PVST+ in detail. Read it here.

Flashcards updated

I’ve added some more flashcards. The latest addition contains some questions on QoS, EEK, BGP and OSPF authentication etc. The total number of flashcards now exceeds 260. Download as usual from here.

CCIE link #10

This is the final post by Petr on route redistribution. If you have read all three of them you should have a much better understanding of route redistribution. Also, INE has released a few videos on route redistribution from ther ATC. These videos are very good and I recommend you watch them.

Good week

I’ve had a good week of studying so far. I’ve been doing INEs Vol2 lab7 and it’s a really challenging lab and it’s rated a 9 for difficulty. If the real lab is close to this then time is going to be a factor, the lab includes a lot of tasks. I do take a lot of notes when doing the labs so that takes extra time of course. I have to include my notes into Anki and make questions out of it. The hardest thing for me with the CCIE is to keep everything current. I will try to use Anki more often to do repitition and when I update my questions database I will upload it here also. Happy studying everyone.

CCIE link #9

This is Petr from INEs second blog post on route redistribution in a three part series. I am starting to get a better grasp of route redistribution. I want to reach the level where I can look at a diagram and immediately identify potential loops and problems and think about what measures to take to prevent problems. If Cisco says I can’t use feature X or Y I should know how to do it using feature Z. So here is part second part in the route redistribution series.