Jul
19

For the benefit of those who do not have access to the lab below is the task and the diagram:

4.11. IGP Redistribution
• Redistribute between RIP and OSPF on SW1.
• Redistribute between OSPF and EIGRP on R2, R3, and R4.
• Ensure that full reachability is maintained throughout the IGP domain when the Frame Relay circuit between R3 and R5 is down.

3 Points

First off this task is only worth 3 points but will take most people 45 minutes to 1 hour to complete due to the fact the requirements create a routing loop. This means that it’s really not worth 3 points in the real lab due to the fact you’re giving away 1 hour of your 8 hours for just 3 points. In the real lab most people would be better off just getting full IP reachability and moving on. Think about it like this. If you could give up 3 points in every lab and implement you own solution to obtain full IP reachability would you be better off?

When you run across a redistribution task in a lab your first goal is to determine what is the minimum redistribution needed to achieve full reachability. This is your “safety net” in the event you are not able to complete the task as required or do not have the time to fully complete the task as required. You can pass the lab without getting these 3 points but you can’t really expect to pass the lab without having full IP reachability.

Since our first goal is just to determine what is needed to obtain full IP reachability lets look at this network and determine where we need to perform redistribution to achieve this. Obviously we must redistribute between RIP and OSPF on SW1 to provide reachability between the OSPF and RIP domains. Since this will be a single point of redistribution between RIP and OSPF and these protocols are only both run on one router (SW1) we will not have any problems. This means we can just redistribute RIP into OSPF, then OSPF into RIP and finally verify our redistribution by viewing the routing tables and doing some basic pinging. No tagging, filtering, distribute-list, etc is needed on SW1.

Once the RIP and OSPF redistribution is finished and verified we should then move onto the EIGRP and OSPF redistribution. Do not make the mistake of moving onto the EIGRP and OSPF redistribution without first verifying your RIP and OSPF redistribution. You must verify each stage of the network as it’s built. If you wait until the end of the IGP section to test for full IP reachability it will be much harder to determine what the cause of the problems are. Think about it like this. If I gave you a network and told you to find 10 errors in it would it be easier to find the 10 errors after I’ve applied all of the configuration or would it be easier to check for the errors as I apply each part of the configuration? If you didn’t answer the latter I would hope you never have aspirations on becoming an airline engine inspector ;-)

First off we need to determine what are the minimum points of redistribution needed between OSPF and EIGRP to obtain full IP reachability. Normally this is easy to determine but in this network we have a backup link being used. In the real lab we don’t need to worry about redundancy or sub-optimal routing unless specified directly or indirectly. In this case we need to take redundancy into consideration since full IP reachability will need to be obtained when the network is in two different states. The first state is when the backup link is in the standby mode. The second state is when the backup interface is active due to the fact the primary link is down. In this case the backup link is the serial between R4 and R5 and the primary link is the Frame Relay connection between R3 and R5.

Now that we know what items to take into consideration for the EIGRP and OSPF redistribution we can determine that at a minimum EIGRP and OSPF will need to be redistributed on R4 and either R2 or R3. R4 is selected for redistribution because when the backup link is active it will need to provide connectivity between R5 and the rest of the network.

Where we start having problems is with the redistribution on R2 or R3 so lets look at what the problem is. OSPF routes going into EIGRP will not present a problem because once the OSPF routes are in EIGRP they will have a higher AD. Remember that the problems with redistribution occur when we take a higher AD protocol and then redistribute it into a lower AD protocol and finally attempt to redistribute it back into the original higher AD protocol (Higher->Lower->Higher). In this case the OSPF routes will have an AD of 170 when redistributed into EIGRP. Since the AD of EIGRP external is 170 these routes will not overtake the original OSPF routes. So lower AD protocol to higher AD protocol isn’t a problem. For those who have always wondered why the external distance of EIGRP is 170 now you know ;-)

Now that we know we shouldn’t have any problems with the OSPF routes going into EIGRP we next need to consider if we’ll have any problems with EIGRP routes going into OSPF. By default EIGRP internal routes have an AD of 90 and an AD of 170 for external routes. This being the case we’ll need to consider the higher->lower->higher problem for both types of routes (internal and external). For the internal EIGRP routes there won’t be a problem since we will be going from a lower AD protocol to higher AD protocol. It’s the external EIGRP routes that weren’t originally OSPF routes. In this lab a previous task asked for the Ethernet segments (E0/0 and E0/1) on R5 to be redistributed into EIGRP. These are the routes which we will see that create the routing loop problem.

We should now be able to see what the problem is. It’s the external EIGRP routes being redistributed into OSPF and then possibly back into EIGRP. This is because we have the higher->lower->higher situation. The higher (external EIGRP) going into a lower (OSPF) and finally back into a higher (external EIGRP).

To illustrate the problem I have mutual redistribution configured between EIGRP and OSPF on both R2 and R3. We can see from the output below that R2 and R3 can not reach R5′s E0/0 interface but they can reach R5′s Loopback0 interface. The only difference is the Loopback is an internal EIGRP route while the Ethernet is an external EIGRP route. This is exactly what we expected to happen.

Rack1R2#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.23.3 16 msec 17 msec 16 msec
  2 132.1.0.2 36 msec 32 msec 36 msec
  3 132.1.23.3 32 msec 32 msec 32 msec
  4 132.1.0.2 52 msec 56 msec 52 msec
  5 132.1.23.3 48 msec 48 msec 48 msec
  6 132.1.0.2 68 msec 68 msec 68 msec
  7 132.1.23.3 64 msec 68 msec 64 msec
  8 132.1.0.2 88 msec 88 msec 84 msec
  9 132.1.23.3 105 msec 96 msec 96 msec
 10 132.1.0.2 120 msec 104 msec 101 msec
Rack1R2#
Rack1R2#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.23.3 16 msec 16 msec 16 msec
  2 132.1.35.5 44 msec *  44 msec
Rack1R2#

Rack1R3#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.0.2 28 msec 32 msec 28 msec
  2  *  *  *
  3 132.1.0.2 44 msec 48 msec 44 msec
  4  *  *  *
  5 132.1.0.2 60 msec 64 msec 64 msec
  6  *  *  *
  7 132.1.0.2 76 msec 84 msec 81 msec
  8  *  *  *
  9 132.1.0.2 269 msec 128 msec *
 10  *  *  *
Rack1R3#
Rack1R3#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.35.5 32 msec *  28 msec
Rack1R3#

Now that we know what the problem is we need to consider all of the possible solutions and implement the simplest solution. First off we could break this potential routing loop by just removing redistribution from R2. The output below shows the traceroutes from R2 and R3 to R5 when redistribution has been removed from R2.

Rack1R2#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.23.3 16 msec 16 msec 16 msec
  2 132.1.35.5 44 msec *  60 msec
Rack1R2#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.0.3 28 msec 32 msec 28 msec
  2 132.1.35.5 56 msec *  56 msec
Rack1R2#

Rack1R3#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.35.5 28 msec *  28 msec
Rack1R3#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.35.5 32 msec *  28 msec
Rack1R3#

It may seem like everything is working now but there is actually another problem that we need to resolve. R6 is not getting the external EIGRP routes originated by R5′s.

Rack1R6#show ip route 132.1.5.0
% Subnet not in table
Rack1R6#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 21154560, type internal
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:14:03 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:14:03 ago, via FastEthernet0/0.26
      Route metric is 21154560, traffic share count is 1
      Total delay is 45100 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 3

Rack1R6#

So lets look back at the first router who should be receiving them and view it’s routing table.

Rack1R3#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2560512256, type external
  Redistributing via ospf 1, eigrp 10
  Advertised by ospf 1 subnets
  Last update from 132.1.35.5 on Serial1/1.1, 00:43:58 ago
  Routing Descriptor Blocks:
  * 132.1.35.5, from 132.1.35.5, 00:43:58 ago, via Serial1/1.1
      Route metric is 2560512256, traffic share count is 1
      Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

Rack1R3#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 20640000, type internal
  Redistributing via ospf 1, eigrp 10
  Advertised by ospf 1 subnets
  Last update from 132.1.35.5 on Serial1/1.1, 20:48:19 ago
  Routing Descriptor Blocks:
  * 132.1.35.5, from 132.1.35.5, 20:48:19 ago, via Serial1/1.1
      Route metric is 20640000, traffic share count is 1
      Total delay is 25000 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 1

Rack1R3#

So R3 has them. Next lets go to R2 and view it’s routing table.

Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
  Last update from 132.1.0.3 on Serial0/0, 00:02:36 ago
  Routing Descriptor Blocks:
  * 132.1.0.3, from 150.1.3.3, 00:02:36 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R2#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 21152000, type internal
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 21:14:51 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 21:14:51 ago, via Serial0/1
      Route metric is 21152000, traffic share count is 1
      Total delay is 45000 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 2

Rack1R2#

R2 has the external EIGRP route (R5′s Ethernet0/0) as an OSPF route and the internal EIGRP route (R5′s Loopback0) still as an internal EIGRP route. This is what we expect to happen since the OSPF route has an AD of 110 and the external EIGRP route has an AD of 170. But why doesn’t R6 get the 132.1.5.0/24 route? R6 doesn’t get the route because EIGRP is not sending it due to the fact the route isn’t in the routing table as an EIGRP route. This is important to understand so let me repeat it. When EIGRP goes to send an update to it’s neighbors it selects the routes from the IP routing table and not the EIGRP topology table. This is the same behavior as RIP in that the route must be in the routing table as a RIP route or a connected route advertised by RIP before it can be sent. So what routes is EIGRP sending? It’s going to send the directly connected routes that EIGRP is advertising from the network statement under the routing process and the dynamically learned EIGRP routes in the routing table. Of course it will not send the EIGRP routes from the routing table back out the same interface they were learned on due to split horizon. So this is why the 132.1.5.0/24 route does not get advertised onto R6 even though EIGRP has the route from R3 in it’s topology table.

Rack1R2#show ip eigrp topology 132.1.5.0/24
IP-EIGRP (AS 10): Topology entry for 132.1.5.0/24
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
  Routing Descriptor Blocks:
  132.1.23.3 (Serial0/1), from 132.1.23.3, Send flag is 0x0
      Composite metric is (2561024256/2560512256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 40010 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 2
      External data:
        Originating router is 150.1.5.5
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)
Rack1R2#

The goal of any solution to this problem is to ensure that the 132.1.5.0/24 route is installed into R2′s routing table as an EIGRP route. Basically there are a few standard methods we could use to achieve this goal so lets list them out:

1) Administrative distance
2) Filtering
3) Summarization

Using administrative distance there are multiple ways to resolve the problem. Below I’ve listed a few of them.

1) Change the administrative distance of the external EIGRP routes to be lower than the OSPF routes on R2.
2) Change the administrative distance of the external OSPF routes to be higher than the external EIGRP routes on R2.
3) Change the administrative distance for all of the OSPF routes to be higher than the external EIGRP routes on R2.
4) Change the administrative distance of just the OSPF routes originated by R3 on R2.
5) Change the administrative distance of just the 132.1.5.0/24 OSPF route on R2.
6) Change the administrative distance of just the 132.1.5.0/24 OSPF route originated by R3 on R2.

As we can see there are a lot of options using AD to ensure the 132.1.5.0/24 gets installed into R2′s routing table as an EIGRP route. If we were to select one of the options, option 6 would be the best. The reason 6 would be the best option is because it’s the most specific option. We normally want to select the most specific solution as we don’t want to implement a solution that could effect other routes. There are actually a couple schools of thought on this and both could be considered correct. The other way of looking at it would be to select the simplest solution regardless of what other routes it effects. Personally I prefer to select the most precise solution assuming that it’s not overly complicated.

Let’s look at what option 6 applied to R2:

Rack1R2(config)#ip access-list standard OSPF_AD
Rack1R2(config-std-nacl)#permit 132.1.5.0
Rack1R2(config-std-nacl)#router ospf 1
Rack1R2(config-router)# distance 171 150.1.3.3 0.0.0.0 OSPF_AD
Rack1R2(config-router)#^Z
Rack1R2#
Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:01:24 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:01:24 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#show ip ospf database external 132.1.5.0

            OSPF Router with ID (150.1.2.2) (Process ID 1)

		Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1513
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 132.1.5.0 (External Network Number )
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0x6F09
  Length: 36
  Network Mask: /24
	Metric Type: 2 (Larger than any link state path)
	TOS: 0
	Metric: 20
	Forward Address: 0.0.0.0
	External Route Tag: 0

Rack1R2#

Now the route is in R2′s routing table as an EIGRP route R6 should have learned it from R2. R6 should also now be able to reach R5 E0/0.

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:02:08 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:02:08 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 0 msec 4 msec 4 msec
  2 132.1.23.3 16 msec 20 msec 16 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

We can see that the administrative distance solution works. Now lets look at the filtering option and remove the administrative distance solution. The simplest filtering option would be to not allow R2 to install the 132.1.5.0/24 OSPF route into it’s routing table.

Rack1R2(config)#ip access-list standard OSPF_FILTER
Rack1R2(config-std-nacl)#deny 132.1.5.0
Rack1R2(config-std-nacl)#permit any
Rack1R2(config-std-nacl)#router ospf 1
Rack1R2(config-router)#distribute-list OSPF_FILTER in
Rack1R2(config-router)#^Z
Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:00:06 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:00:06 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#

The next option we listed was to use summarization. Before we do that I’ll remove the distribute list and then summarize the 132.1.5.0/24 route to 132.1.4.0/23 when it’s advertised by OSPF on R3. By doing this R2 will receive the 132.1.5.0/24 via external EIGRP from R3 over the serial and the 132.1.4.0/23 via OSPF from R3 over the Frame Relay link. Since the external EIGRP route is more specific R2 will use it to reach R5′s E0/0 interface and in turn advertise the route onto R6.

Rack1R3(config)#router ospf 1
Rack1R3(config-router)#summary-address 132.1.4.0 255.255.254.0

Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:00:21 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:00:21 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#show ip route 132.1.4.0
Routing entry for 132.1.4.0/23
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
  Last update from 132.1.0.3 on Serial0/0, 00:00:26 ago
  Routing Descriptor Blocks:
  * 132.1.0.3, from 150.1.3.3, 00:00:26 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R2#

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:00:39 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:00:39 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 0 msec 4 msec 0 msec
  2 132.1.23.3 16 msec 16 msec 16 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

Technically we could have not allowed the 132.1.5.0/24 route from being redistributed into OSPF on R3 by filtering it with a route-map. Additionally we could have also used the “not-advertise” option on the summary command to summarize the route but not advertise. This is basically just a different way of filtering since the not-advertise option summarizes the routes but doesn’t advertise the summary.

To this point we have achieve full IP reachability but we have not met the requirements of the task. The task stated that redistribution should be done on both R2 and R3. We’ve only done it on R3. Now we need to perform redistribution on R2. We will need to implement whatever solution we used on R3 on R2.

Rack1R2(config)#router ospf 1
Rack1R2(config-router)#redistribute eigrp 10 subnets
Rack1R2(config-router)#summary-address 132.1.4.0 255.255.254.0
Rack1R2(config-router)#
Rack1R2(config-router)#router eigrp 1
Rack1R2(config-router)#redistribute ospf 1 metric 1 1 1 1 1
Rack1R2(config-router)#

We can now verify that we still have reachability from R6:

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:00:04 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:00:04 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 4 msec 0 msec 4 msec
  2 132.1.23.3 16 msec 16 msec 20 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

We can now do a full reachabilty test to ensure everything is reachable. We will also need to do another reachabilty test when the backup link is active. Before we do that we should implement the same solution we used to stop the routing loop on R2 and R3 on R4. We do this because when the Frame Relay link between R3 and R5 is down the 132.1.5.0/24 route will be redistributed into OSPF on R4.

Rack1R4(config)#router ospf 1
Rack1R4(config-router)#redistribute eigrp 10 subnets
Rack1R4(config-router)#summary-address 132.1.4.0 255.255.254.0
Rack1R4(config-router)#
Rack1R4(config-router)#router eigrp 1
Rack1R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1
Rack1R4(config-router)#

I need to add that for simplicity I only discussed the solution in regards to the 132.1.5.0/24 network but in the full solution we would need to consider the other network that is being redistributed into EIGRP on R5 (192.10.1.0/24). Also you may have noticed that the routing loop problem only occurred because a previous task asked us to redistributed the connected Ethernet interfaces into EIGRP on R5. If we would have just solved that 2 point task by advertising it natively using network statements we wouldn’t have had any routing loop problems and only lost the 2 points ;-)

Lastly you will find similar in-depth discussions added to the new IEWB-RS Volume II version 5 in regards to route redistribution. It’s important that everyone understands not only the solution we chose but what problems the solution is resolving along with any other possible solutions.

About Brian Dennis, CCIE #2210:

Brian Dennis has been in the networking industry for more than 22 years, with a focus on Cisco networking for the past 16 years. Brian achieved his first CCIE in Routing & Switching in 1996, and is currently the only ten year CCIE that holds five CCIE certifications. Prior to working with INE, Brian taught and developed CCIE preparation courses for various well known training organizations. Brian not only brings his years of teaching experience to the classroom, but also years of real world enterprise and service provider experience.

Find all posts by Brian Dennis, CCIE #2210 | Visit Website


You can leave a response, or trackback from your own site.

22 Responses to “Advanced Route Redistribution Scenario (IEWB-RS v4.1 Vol II Lab 2 Task 4.11)”

 
  1. Kabir Ibrahim says:

    That eas well explained Brian. Keep up to good work.

  2. Kabir Ibrahim says:

    I meant that was well explained. Keep up the good work

  3. Amit Chopra says:

    My suggestion to others , first finished the Lab2 Redistribution section from workbook and read this article , you will find that you have better understanding of Redistribution for this task.

    Amit Chopra

  4. [...] InternetworkExpert Blog – Advanced Route Redistribution by Brian Dennis [...]

  5. Ivan says:

    Hello Brian,
    could we take as a standard solution approach in the Lab Exam just to work with route-maps and tags when redistributing is asked and there is a risk of a routing loop?
    I know it all depends on the requirements of the task, but besides taht I see that whe you tag the redistributed routes in other routing protocol you don’t have to take care of specific routes like in the example above.
    Do you think is a valid approach just to save a few minutes and avoid possible mistakes?

  6. Ram says:

    thanks Brian…

  7. bam says:

    If you just look at the network you can see that ideally you want OSPF to be the WAN core. Configuring 132.1.23.0/24 with the EIGRP network statement causes big problems because it will have an AD of 90 which is lower and more preferred over OSPF. If there was a way to make that network have a higher AD than OSPF, all would be OK — even when you try reachability with the backup link (between R4 and R5) up.

    And the answer is….

    On R2 and R3…
    router eigrp 10
    redistribute connected route-map CON->EX metric 1 1 1 1 1
    route-map CON->EX permit 10
    match interface Serialx/x
    route-map CON->EX permit 999

    BTW — it doesn’t seem to violate task 4.4. I suppose it depends on your interpretation of “Enable EIGRP…”.

  8. Matija says:

    Hi,
    thanks for great article Brian.
    What is your opinion on inserting default routes (like ospf default-information originate always) to achieve full connectivity?

  9. CCIETalk.com says:

    Aaah.. this just kicked my butt and after reading your explanation I feel better. IEWB 4.1 Solution guide doesn’t explain this in detail. I will redo this task and see how I do. Also in the Solutions Guide – you are permitting a few external prefixes esp 132.1.7.0 but I don’t see that anywhere in the topology. Any explanation?

  10. Osama says:

    HOW I can do it by using route-map under redistribution command please heeeeeeeeeeeeeeeeeelp me!!!!!!!!!!

  11. Osama says:

    I’m trying to use tag with route-map but it is not working!! can you please explain it ….

  12. [...] Advanced Route Redistribution Scenario (IEWB-RS v4.1 Vol II Lab 2 … [...]

  13. BINISH says:

    IT WAS REALLY HELPUL.IT NOW IT IS SOMEWHAT CLEAR

  14. BINISHTIMENET says:

    ROUTE REDISTRIBUTION HAS BEEN MADE SIMPLE.BASIC CONCEPTS HAS BEEN THROUGLY DEFINED

  15. parveen jindgar says:

    hi Mr Brian it is very nice explanation.But still i need clarification how R1 is learning RIP native routes from R3.

    Regards
    parveen jindgar

  16. Jains says:

    I have abstracted from Mr. Dennis and Mr. Lapukhov articles. hth
    Goal #1 Determine the minimum redistribution necessary to obtain full IP reachability as a “safety net”.
    Goal #2 Determine what the problems will be. Routing loops must always be fixed. Subotimal, backup routes etc. may not matter.
    Goal #3 Verify full IP reachability and save configs.
    Goal #4 If there is time try meet the full requirements for the redistribution task. Go back to the safety net (Goal#1-3) if time runs out.

    Rule #1 Always prefer Internal Routing Info over External.
    Rule #2 Never redistribute a prefix injected from Domain A into Domain B back into Domain A.
    Rule #3 A routing protocol selects only routes that are in its routing table as that routing protocol and directly connected routes when it redistributes.

    Tool#1 Administrative Distance
    Tool#2 Filtering
    Tool#3 Summartiztion
    Tool#4 Forward/Backward Chaining to determine where a route is lost or changed.
    Tool#5 TCL script to verify reahability.

  17. Adrian says:

    Something doesn’t quite make sense to me regarding this. I am trying to lab this scenario now and kind of stumbled upon a similar fix to what Brian outlines here.

    However Brian suggests “When EIGRP goes to send an update to it’s neighbors it selects the routes from the IP routing table and not the EIGRP topology table”

    However when you look at R3′s route for R6′s external EIGRP route, you see the following:

    R3#sh ip route 132.1.6.0
    Routing entry for 132.1.6.0/24
    Known via “ospf 1″, distance 110, metric 20, type extern 2, forward metric 64
    Redistributing via eigrp 10
    Advertised by eigrp 10 metric 10000 1 255 1 1500
    Last update from 132.1.0.2 on Serial0/0, 00:04:13 ago
    Routing Descriptor Blocks:
    * 132.1.0.2, from 150.1.2.2, 00:04:13 ago, via Serial0/0
    Route metric is 20, traffic share count is 1

    So following on from what Brian suggests, R5 (whose only neighbour is R3 and only talks EIGRP with him), should therefore have no route to R6. But it does!

    R5#sh ip route 132.1.6.0
    Routing entry for 132.1.6.0/24
    Known via “eigrp 10″, distance 170, metric 2170112, type external
    Redistributing via eigrp 10
    Last update from 132.1.35.3 on Serial0/0.1, 00:05:10 ago
    Routing Descriptor Blocks:
    * 132.1.35.3, from 132.1.35.3, 00:05:10 ago, via Serial0/0.1
    Route metric is 2170112, traffic share count is 1
    Total delay is 20010 microseconds, minimum bandwidth is 1544 Kbit
    Reliability 255/255, minimum MTU 1500 bytes
    Loading 1/255, Hops 1

    R5 has learnt of this prefix seemingly via R;3 EIGRP topology table. Can someone shed light on why this is happening in this case?

  18. Audyn Espinoza says:

    Let’s say we redistribute a rip (AD 120) route into ospf (AD 90). My question is: what tells the router not to use the redistributed route since it has a better AD of 110-ospf, than the original rip route with AD of 120. i know it obviously doesn’t use the ospf route in this case, but just curious as to how the router come to this conclusion.

  19. Audyn Espinoza says:

    Adrian, to answer your question, it seems to me (i could be wrong) that it should always advertise. If we were to expect the eigrp to advertise only if it was put in RT, then this could cause flapping, because once the eigrp would get added to RT, the router would lose its ospf route from RT and therefore stop redistributing (according to the rule of thumb that says redistribute only routes in RT). it would cause the router to flap endlessly. Also, notice what it says in your output:
    Advertised by eigrp 10 metric 10000 1 255 1 1500

  20. sovanvichet says:

    awesome explaination, i understand alot more about redistribution.

    super brian

  21. jay says:

    Hi Brian,

    I just looked at this briefly, regarding that redistribution problem of BGP > EIGRP > OSPF @R5. why cant we just change the AD of BGP routes >OSPF @ R5 redistribution point (e.g. AD 100)? or I am missing something.

    This way EIGRP > OSPF routes will be less attractive to other ASBR in Area 0 OSPF.

    Will appreciate some answer.

    Thanks
    Jay

  22. ccie99999 says:

    I’ve labbed this but I don’t see the issue Brian is talking about where he says about the higher->lower->higher situation.
    Higher->lower->higher situation in my opinion here is not bad since AD are 170 -> 110 -> 170
    Brian says he did mutual redistribution on R2 and R3 (not R4 so far).
    W/o filtering anything I see prefix 132.1.5.0 with AD170 on R3, point to R5 (via backup link) and to R2 (since R2 gets it as 110AD):

    RSRack1R3#sh ip route 132.1.5.0
    Routing entry for 132.1.5.0/24
    Known via “eigrp 10″, distance 170, metric 2560512256, type external
    Redistributing via eigrp 10, ospf 1
    Advertised by ospf 1 subnets
    Last update from 132.1.35.5 on Serial1/1.1, 00:01:14 ago
    Routing Descriptor Blocks:
    * 132.1.35.5, from 132.1.35.5, 00:01:14 ago, via Serial1/1.1
    Route metric is 2560512256, traffic share count is 1
    Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
    Reliability 1/255, minimum MTU 1 bytes
    Loading 1/255, Hops 1
    132.1.23.2, from 132.1.23.2, 00:01:14 ago, via Serial1/3
    Route metric is 2560512256, traffic share count is 1
    Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
    Reliability 1/255, minimum MTU 1 bytes
    Loading 1/255, Hops 1

    Since R2 has interface fa0/0.26 with eigrp enabled, R6 is able to get the prefix.
    This prefix comes as 170 from R5 -> R3 -> R2 -> R6. It starts as AD170 and it is always like that till R6

    RSRack1R6#sh ip route 132.1.5.0
    Routing entry for 132.1.5.0/24
    Known via “eigrp 10″, distance 170, metric 2560002816, type external
    Redistributing via eigrp 10
    Last update from 132.1.26.2 on FastEthernet0/0.26, 00:09:20 ago
    Routing Descriptor Blocks:
    * 132.1.26.2, from 132.1.26.2, 00:09:20 ago, via FastEthernet0/0.26
    Route metric is 2560002816, traffic share count is 1
    Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
    Reliability 1/255, minimum MTU 1 bytes
    Loading 1/255, Hops 1

    If I put in shut the R2 se0/1 face to R3, situation won’t change that much:

    R3 will be able to get the route from R5 as 170
    R2 will be able to get the route from R3 via se0/0 as AD110 (170->110).
    R2 will redistribute the route into eigrp as 170 (from 110->170).

    in this scenario I don’t see loops.

    am I missing something?

 

Leave a Reply

Categories

CCIE Bloggers