Introduction to Redistribution

Lessons Discussion
21

Hi Sir,

i think i found one more typo error, R2 rip info must be sent to R1.

R2 will redistribute EIGRP routing information into RIP and advertise it to R3.
R2 will redistribute RIP routing information into EIGRP and advertise it to R3.

Regards
Subrahmanya

22

Hello Subbu

Yes you are correct, that should read “and advertise it to R1.” not R3.

I will let @ReneMolenaar know to change it.

Thanks very much!

Laz

23

Thanks for letting me know, just fixed this typo.

24

Hi Rene,

Would it be correct to say that we should only redistribute between 2 routing protocols in a given network at only 1 router in order to avoid creating loops?

25

Hi Waleed,

That would prevent routes from looping around but it also means you have a single point of failure. Redistribution on two routers is no problem but you have to understand and deal with potential issues. For example, take a look at route tagging:

Rene

1 Like
26

Hello Rene/Laz,
I have a question and I am going to use the below topology as a reference of my question.

image
image1947×851 11.4 KB

As you see in the topology, Two different routing protocols are running in this network(EIGRP & BGP). R2 is running both protocols as it is shown in the diagram. If mutual redistribution is done at R2 between EIGRP and BGP, R2 will take all the routes from EIGRP and inject it in BGP and also take all the routes from BGP and inject it into EIGRP. Based upon this statement, R1 is not supposed to see any routing entry for 10.10.10.0 /24. In another words, R2 is not supposed to inject 10.10.10.0 /24 route into BGP because R2 does not have 10.10.10.0 /24 route listed as EIGRP route in its routing table. Instead, R2 will have a routing entry for 10.10.10.0 /24 as a directly connected link. Now R1’s routing table does have a routing entry for 10.10.10.0 /24 that it is learning from BGP which means R2 is indeed injecting 10.10.10.0 /24 network into BGP. Would you please let me know why R2 is injecting 10.10.10.0 /24 into BGP even though it is not an EIGRP route?

Thanks a lot.

Azm

27

Hello Azm

I don’t see why this statement is true. Actually, R1 will see the 10.10.10.0/24 network in it’s routing table. This is because, as you stated, R2 redistributes all of its BGP routes into EIGRP, so R2 will share this route with R1 through redistribution.

It is true that R2’s interface on the 10.10.10.0/24 network does not participate in EIGRP, but it is being redistributed into EIGRP. Remember that BGP will place in the BGP table any route that already exists in the routing table. This is a prerequisite for BGP. Since 10.10.10.0/24 is a directly connected route, it is in the routing table, thus it will be in the BGP table, and will be redistributed to EIGRP and thus it will reach R1.

I hope this has been helpful!

Laz

28

Good Evening

NetworkLessons team,

I have a big question and I was reviewing all the material related to it, but I could not find my answer, I am assuming that is related to TTL (EIGRP/RIP)

Example :
I have 3 EIGRP AS and I want to redistribute all of them in ONLY one (EIGRP AS 100) to make it like main and needs to redistributed all the routes learned from each AS and Its static route as well like you can see below.

Router1:

 router eigrp 200
 network 2.2.2.1 0.0.0.0
 redistribute static

Router2:

 router eigrp 300
 network 3.3.3.1 0.0.0.0
 redistribute static

Router3:---------------------------------> MAIN (BACKBONE)

router eigrp 100 
 network 1.1.1.2 0.0.0.0
 redistribute eigrp 200
 redistribute eigrp 300
 redistribute static
!
 router eigrp 200
 network 2.2.2.2 0.0.0.0
 redistribute eigrp 100
!
 router eigrp 300
 network 3.3.3.2 0.0.0.0
 redistribute eigrp 100

Router4:

 router eigrp 100
 network 1.1.1.1 0.0.0.0
 redistribute static

in conclusion router4 can see all the routes from router1, router2 and router3, but router1 and router2 can’t see the static routes redistributed in AS100

Thanks

29

Hello Ricardo

I tried labbing up your topology and I found that with your configurations, R4 is able to see the directly connected networks on R1 and R2, and both R1 and R2 are able to see the directly connected networks on R4. What I did find was that R2 was not able to see R1’s directly connected routes until the redistribute static command was also applied to the EIGRP 100 configuration in R3, and visa versa for R1.

I suggest you troubleshoot by looking at the EIGRP topologies in each router, and perform a debug to see what EIGRP routes are being exchanged, in order to determine why you don’t see the routes appearing in R1 and R2.

I hope this has been helpful!

Laz

30

Hi,

Good lesson. I have couple of questions, How do you avoid routing loops in redistribution when we configure redistribution on multiple routers? When we change default-metric for the routes being redistributed into the protocol, will it change metric for existing routes/prefixes as well? Also when we redistribute routes from RIP to EIGRP on R2, which protocol does routing table install in R2 reaching 3.3.3.3/32? Will it show EIGRP due to less Administrative distance than RIP as it is redistributed from RIP to EIGRP?

Thanks,
Nihar

31

Hello Nihar

If you have more than one router redistributing routes between two different routing domains, then the most effective method of preventing loops is to use route tagging. A detailed lesson on this can be found below:

By changing the default seed metric, you are changing the way in which the router assigns the metric to redistributed routes only. The actual default metric of other prefixes and routes within the routing domain remain the same.

In the lesson, Rene says something very important about this:

Redistribution happens outbound. If I configure redistribution on R2 then nothing will change in the routing table of R2.

So the routing table of R2 is unchanged by the local redistribution commands. It is only the routing table of R1 that is affected when R2 redistributes the 3.3.3.0/24 subnet into the EIGRP routing domain. So R2 still sees R3 as the next hop to reach the 3.3.3.0/24 route.

I hope this has been helpful!

Laz

32

Question Rene:

I have a star topology with R1 in the middle, doing all redistribution. I can reach all networks except for this problem:

I can ping from the IS-IS network to all other networks but I cannot ping from any other network to the IS-IS network.
I think this issue is at the level of redistribution. Here is the running config of R1:

R1#show running-config 
Building configuration...

Current configuration : 2155 bytes
!
! Last configuration change at 09:28:09 EET Thu Sep 30 2021
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
bsd-client server url https://cloudsso.cisco.com/as/token.oauth2
clock timezone EET 2 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
!


!
!
!
!
ip cef    
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
cts logging verbose
!
!
!
redundancy
!
!
! 
!
!
!
!
!         
!
!
!
!
!
!
!
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
!
interface Ethernet0/1
 ip address 172.16.1.1 255.255.255.0
!
interface Ethernet0/2
 ip address 10.10.1.1 255.255.255.0
!
interface Ethernet0/3
 ip address 20.20.1.1 255.255.255.0
 ip ospf 1 area 0
!
interface Ethernet1/0
 ip address 172.16.2.1 255.255.255.0
 ip router isis 
!
interface Ethernet1/1
 no ip address
 shutdown
!
interface Ethernet1/2
 no ip address
 shutdown
!
interface Ethernet1/3
 no ip address
 shutdown
!
!
router eigrp 1
 default-metric 1500 100 255 1 1500
 network 192.168.1.0
 redistribute rip
 redistribute ospf 1
 redistribute bgp 1
 redistribute isis level-1
!
router ospf 1
 redistribute eigrp 1 subnets
 redistribute rip subnets
 redistribute bgp 1 subnets
 redistribute isis level-1 subnets
!
router isis
 net 49.0001.0000.0000.0001.00
 is-type level-1
 log-adjacency-changes
 redistribute ospf 1 level-1
 redistribute eigrp 1 level-1
 redistribute rip level-1
 redistribute bgp 1 level-1
!
router rip
 version 2
 redistribute ospf 1
 redistribute eigrp 1
 redistribute bgp 1
 redistribute isis level-1
 network 10.0.0.0
 default-metric 5
 no auto-summary
!
router bgp 1
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 redistribute ospf 1
 redistribute eigrp 1
 redistribute rip
 redistribute isis level-1
 neighbor 172.16.1.4 remote-as 4
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!         
!
!
!
!
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
!
end
33

Hello Ayong

There may be several areas in which the routing is failing for your communication from a non-ISIS router to an ISIS router. To determine where the problem is, I suggest you try some of the following:

  1. Try a “mirror image” of the ping that worked. In other words, if ISIS_R1 pinged EIGRP_R1 successfully, try to ping the exact opposite. Make sure however that you are using the same source and distination IPs!! If you just use ping, the router may choose a different source IP. More info about ping can be found at this lesson. I have a hunch that if you do this, your ping will work.
  2. If it doesn’t, then trace the proper path that such a packet should take, and write down the expected next-hop IPs for each of the routers it passes through. Check the routing table of each of those routers and see that the routers do indeed have a next-hop router configured for that destination, or if a default gateway is serving your destination correctly. Remember to trace both directions! It could be that the ping successfully reaches the destination, but the return trip fails! By doing this, you will find the specific router which drops the packet. You can then investigate why that router doesn’ thave a proper route to serve that destination.

Once you perform these steps, you should be in a position to determine the reason for the failure, whether it is redistribution or not. The fact that your initial pings worked tell me that redistribution is working correctly, at least for the source and destination IP addresses in question.

Try this out and let us know how you get along…

I hope this has been helpful!

Laz

34

Thank you Laz, I tried the options but still it did not work. I have simplified the topology for just two protocols (ISIS-Level-1 and EIGRP 1) this time. If we can get this one working, then the others will probably work.
Topology:
image

Here is the configs:

R11_EIGRP#show run
Building configuration...

Current configuration : 1157 bytes
!
! Last configuration change at 15:41:58 EET Mon Oct 4 2021
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R11_EIGRP
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
bsd-client server url https://cloudsso.cisco.com/as/token.oauth2
clock timezone EET 2 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
!


!
!
!
!
ip cef    
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
cts logging verbose
!
!
!
redundancy
!
!
! 
!
!
!
!
!         
!
!
!
!
!
!
!
interface Loopback0
 ip address 11.11.11.11 255.255.255.255
!
interface Ethernet0/0
 ip address 192.168.100.11 255.255.255.0
!
interface Ethernet0/1
 no ip address
 shutdown
!
interface Ethernet0/2
 no ip address
 shutdown
!
interface Ethernet0/3
 no ip address
 shutdown
!
!
router eigrp 1
 network 11.11.11.11 0.0.0.0
 network 192.168.100.0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!         
!
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
!
end

R12EIGRP_ISIS-Level1#show run
Building configuration...

Current configuration : 1268 bytes
!
! Last configuration change at 15:40:12 EET Mon Oct 4 2021
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R12EIGRP_ISIS-Level1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
bsd-client server url https://cloudsso.cisco.com/as/token.oauth2
clock timezone EET 2 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
!


!
!
!
!
ip cef    
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
cts logging verbose
!
!
!
redundancy
!
!
! 
!
!
!
!
!         
!
!
!
!
!
!
!
interface Ethernet0/0
 ip address 192.168.100.12 255.255.255.0
!
interface Ethernet0/1
 ip address 172.16.100.12 255.255.255.0
 ip router isis 
!
interface Ethernet0/2
 no ip address
 shutdown
!
interface Ethernet0/3
 no ip address
 shutdown
!
!         
router eigrp 1
 network 192.168.100.0
 redistribute isis level-1 metric 1 1 1 1 1
!
router isis
 net 49.0001.0000.0000.0012.00
 is-type level-1
 log-adjacency-changes
 redistribute eigrp 1 level-1
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!         
!
!
!
!
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
!
end

R13_ISIS_Level-1#show run
Building configuration...

Current configuration : 1201 bytes
!
! Last configuration change at 15:36:57 EET Mon Oct 4 2021
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R13_ISIS_Level-1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
bsd-client server url https://cloudsso.cisco.com/as/token.oauth2
clock timezone EET 2 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
!
!


!
!
!
!
ip cef    
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
cts logging verbose
!
!
!
redundancy
!
!
! 
!
!
!
!
!         
!
!
!
!
!
!
!
interface Loopback0
 ip address 13.13.13.13 255.255.255.255
 ip router isis 
!
interface Ethernet0/0
 ip address 172.16.100.13 255.255.255.0
 ip router isis 
!
interface Ethernet0/1
 no ip address
!
interface Ethernet0/2
 no ip address
 shutdown
!
interface Ethernet0/3
 no ip address
 shutdown
!
router isis
 net 49.0001.0000.0000.0013.00
 is-type level-1
 log-adjacency-changes
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!         
!
!
!
line con 0
 logging synchronous
line aux 0
line vty 0 4
 login
 transport input none
!
!
end

Problem: I can ping from EIGRP router to ISIS router lo0 but I cannot ping from ISIS router to the lo0 of EIGRP router.

35

Hello Ayong

Once again, you must make sure that your pings in both directions are consistent. In this particular case you should do the following:

From R11: ping 13.13.13.13 source 11.11.11.11

From R13: ping 11.11.11.11 source 13.13.13.13

This way you are ensuring that the pings in both directions are performing an identical test. If you don’t use the source keyword, then the source IP will be different for the ping in each direction, which can change results.

Now, if this is still successful in one direction and not in the other, it would be very strange. Why? Because a ping has two directions of travel: echo request, and echo reply. If a ping is successful, it means that routing between those two loopbacks has been established in both directions. This means that the opposite ping between the same to IP addresses should also be successful. If it is not, then the issue may not be with the redistribution, but elsewhere.

Take a look at the routing tables of all three routers and see if the correct entries are there to route the packets. Specifically, make sure that the entries for 13.13.13.13 and 11.11.11.11 are correct on all three routers and that the next hop IPs are reachable. If you still have problems, can you share the routing tables of all three devices?

I hope this has been helpful!

Laz

36

Thank you so much Laz.
It works as you said but I am not sure of why pings from the ISIS network must be source from the Lo0 interface before it works

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

R11_EIGRP#show ip route
Gateway of last resort is not set

      11.0.0.0/32 is subnetted, 1 subnets
C        11.11.11.11 is directly connected, Loopback0
      13.0.0.0/32 is subnetted, 1 subnets
D EX     13.13.13.13 
           [170/2560025856] via 192.168.100.12, 00:11:48, Ethernet0/0
      192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.100.0/24 is directly connected, Ethernet0/0
L        192.168.100.11/32 is directly connected, Ethernet0/0

R13_ISIS_Level-1#ping 11.11.11.11            
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R13_ISIS_Level-1#
R13_ISIS_Level-1#ping 11.11.11.11 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
Packet sent with a source address of 13.13.13.13 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R13_ISIS_Level-1#show ip route
Gateway of last resort is not set

      11.0.0.0/32 is subnetted, 1 subnets
i L1     11.11.11.11 [115/10] via 172.16.100.12, 00:07:36, Ethernet0/0
      13.0.0.0/32 is subnetted, 1 subnets
C        13.13.13.13 is directly connected, Loopback0
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.100.0/24 is directly connected, Ethernet0/0
L        172.16.100.13/32 is directly connected, Ethernet0/0
i L1  192.168.100.0/24 [115/10] via 172.16.100.12, 00:07:40, Ethernet0/0

R12EIGRP_ISIS-Level1#show ip route
Gateway of last resort is not set

      11.0.0.0/32 is subnetted, 1 subnets
D        11.11.11.11 [90/409600] via 192.168.100.11, 00:12:21, Ethernet0/0
      13.0.0.0/32 is subnetted, 1 subnets
i L1     13.13.13.13 [115/20] via 172.16.100.13, 00:12:22, Ethernet0/1
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.100.0/24 is directly connected, Ethernet0/1
L        172.16.100.12/32 is directly connected, Ethernet0/1
      192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.100.0/24 is directly connected, Ethernet0/0
L        192.168.100.12/32 is directly connected, Ethernet0/0
37

Hello Ayong.

Let’s take a look at it step by step.

If you ping 11.11.11.11 from R13 using the ping 11.11.11.11 command, then R13 will use the IP address of the local exit interface as the source IP address. If you look at the routing table of R13, you will see that the route to 11.11.11.11 uses the Ethernet0/0 interface, which has an IP address of 172.16.100.13. So these pings will have a source address of 172.16.100.13. Here are the next steps:

  • The packet will be routed to R12 correctly since there is a route in the routing table of R13 that matches the destination address.
  • R12 will receive the packet, and correctly route it to R11 since there is a route in the routing table that matches the destination address.
  • R11 will receive the packet successfully and see it is an echo request. It prepares a response with a source IP address of 11.11.11.11 and a destination IP address of 172.16.100.13.

However, there is no match for the destination address of 172.16.100.13 in the routing table of R11. The packet will be dropped and the ping will fail.

Now if a source address of 13.13.13.13 were used in the ping, the ping would be successful because R11 has a route to that destination.

In order to solve this problem, you must redistribute the 172.16.100.0/24 network from IS-IS to EIGRP as well. For some reason that is not happening, even though the interface has been enabled using the ip router isis command on both R12 and R13. I suggest you do some troubleshooting of ISIS similar to what you see in the following lesson:

Check to see what the isis database looks like in both R12 and R13. Let us know how you get along so we can help you out further in the troubleshooting process…

I hope this has been helpful!

Laz

1 Like
38

Thank you so much Laz. That did the trick. I appreciate your help.

1 Like
39

Hello, everyone!

Just a quick question. Does anyone know the design reason behind why some Routing Protocols have a seed metric of Infinity (RIP, EIGRP), 20 (OSPF) and 1 (From BGP into OSPF)?

Wouldn’t it be much easier and friendlier if everyone just shared the same seed metric? Also does anyone have an idea about why is the seed metric set specifically to 1 in the BGP scenario?

Thank you in advance for your help.

Kind regards,
David

40

Hello David

The seed metric is an initial value that a routing protocol uses when learning about routes from another routing protocol. Although it would be easier and friendlier to use the same seed metric for all routing protocols, this would not be ideal. The reason for different seed metrics in different routing protocols is due to the differing methods they use to calculate the best path.

RIP and EIGRP use a seed metric of infinity because they are distance-vector protocols. In these protocols, a route with a metric of infinity is considered unreachable. By initially setting the seed metric to infinity, the protocol essentially considers the new route as unreachable. This prevents the route from being used until the protocol can assign a more accurate metric to it, based on subsequent updates or configuration changes. In practice, a network administrator will configure a more useful seed metric based on design and network requirements.

In OSPF, the maximum cost is 65535, and anything beyond that is considered infinite. However, OSPF is a link-state protocol whose metric is based on link bandwidth. It uses a seed metric of 20 when redistributing routes from other protocols. This seemingly arbitrary number is likely a design decision made to provide a “middle of the road” value, as the OSPF cost value is typically much higher than that of RIP or EIGRP.

Now when redistributing BGP into OSPF we have an exception where the default seed metric used is 1. The likely reason for this is that BGP uses a very complex path selection process and doesn’t really have a comparable metric to OSPF’s cost. Therefore, setting the seed metric to 1 ensures that the routes redistributed from BGP are not immediately considered less favorable than OSPF’s internal routes simply because of a higher cost.

Ultimately, these values have been chosen by design to ensure the most appropriate behavior of redistributed routes. Keep in mind however that these default seed metrics should ultimately be manually configured by an administrator to more appropriate values depending on the specific requirements of the particular network.

I hope this has been helpful!

Laz

1 Like