EIGRP default route propagation
cristi.grigore
Member Posts: 18 ■□□□□□□□□□
in CCNP
Hi everyone,
I have the following scenario:
R1 is connected to the outside world and I want to create a default route and advertise it to the other 3 routers through EIGRP. I did this setup on dynagen, so I had to create a loopback interface on R1 and use at as the default route to the outside.
The loopback has an ip address of 172.16.10.1/24 and it seems there is a problem with the fact that the ip default-network command is classful: whenever I enter the command ip default-network 172.16.10.0, the command changes into ip route 172.16.0.0 255.255.0.0 172.16.10.0 in the running config. I then have to use ip default-network 172.16.0.0 to mark the default candidate, instead of 172.16.10.0. The default candidate in the routing table is now 172.16.0.0 and it looks like this:
The problem is: its not working, the default route is not advertised in the netw If I change the static route from ip route 172.16.0.0 255.255.0.0 172.16.10.0 to ip route 172.16.0.0 255.255.0.0 loopback 1, the default route will be advertised in the netw. Also, if I use a class C address on the loopback (192,168.10.1, for example) and set ip default-network 192.168.10.0, the default network of 192.168.10.0 is propagated.
Cisco says that:
"...(EIGRP) it redistributes a default route as a result of the ip route 0.0.0.0 interface command (but not as a result of the ip route 0.0.0.0 address..."
My opinion is that this is a bug in EIGRP, but Cisco put it in the documentation and it became a feature
What are your thoughts on this?
PS: here is the running config from R1 for the situation where it actually propagates the default route:
I have the following scenario:
R3 / | R1------R2 | \ | R4
R1 is connected to the outside world and I want to create a default route and advertise it to the other 3 routers through EIGRP. I did this setup on dynagen, so I had to create a loopback interface on R1 and use at as the default route to the outside.
The loopback has an ip address of 172.16.10.1/24 and it seems there is a problem with the fact that the ip default-network command is classful: whenever I enter the command ip default-network 172.16.10.0, the command changes into ip route 172.16.0.0 255.255.0.0 172.16.10.0 in the running config. I then have to use ip default-network 172.16.0.0 to mark the default candidate, instead of 172.16.10.0. The default candidate in the routing table is now 172.16.0.0 and it looks like this:
* 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.16.10.0/24 is directly connected, Loopback1 S* 172.16.0.0/16 [1/0] via 172.16.10.0 10.0.0.0/24 is subnetted, 4 subnets D 10.2.0.0 [90/30720] via 10.1.0.2, 00:43:19, FastEthernet1/0 D 10.3.0.0 [90/30720] via 10.1.0.2, 00:43:19, FastEthernet1/0 C 10.1.0.0 is directly connected, FastEthernet1/0 D 10.4.0.0 [90/33280] via 10.1.0.2, 00:43:19, FastEthernet1/0Of course, under router eigrp i have the network 172.16.0.0 command in order to redistribute the default route.
The problem is: its not working, the default route is not advertised in the netw If I change the static route from ip route 172.16.0.0 255.255.0.0 172.16.10.0 to ip route 172.16.0.0 255.255.0.0 loopback 1, the default route will be advertised in the netw. Also, if I use a class C address on the loopback (192,168.10.1, for example) and set ip default-network 192.168.10.0, the default network of 192.168.10.0 is propagated.
Cisco says that:
"...(EIGRP) it redistributes a default route as a result of the ip route 0.0.0.0 interface command (but not as a result of the ip route 0.0.0.0 address..."
My opinion is that this is a bug in EIGRP, but Cisco put it in the documentation and it became a feature
What are your thoughts on this?
PS: here is the running config from R1 for the situation where it actually propagates the default route:
R1#sh run Building configuration... Current configuration : 868 bytes ! ! Last configuration change at 04:20:53 UTC Tue Sep 4 2007 ! version 12.4 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 ! ! ip cef ! ! ! interface Loopback1 ip address 172.16.10.1 255.255.255.0 ! interface FastEthernet0/0 no ip address shutdown duplex half ! interface FastEthernet1/0 ip address 10.1.0.1 255.255.255.0 duplex half ! router eigrp 1 network 10.0.0.0 network 172.16.0.0 no auto-summary ! ip default-network 172.16.0.0 ip route 172.16.0.0 255.255.0.0 Loopback1 ! no ip http server ! ! control-plane ! ! line con 0 logging synchronous stopbits 1 line aux 0 stopbits 1 line vty 0 4 login ! ! end R1#
Comments
-
dtlokee Member Posts: 2,378 ■■■■□□□□□□I don't think it's a bug in the IOS, just how the IOS behaves. Since the administrative distance of a static route pointing to a connected interface will be 0 and it is treated as connected, it can be originated with a "network" statement in router configuration mode. If the route is created pointing to another IP address, it will have an administrative distance greater than or equal to 1 so it would need to be redistributed into the routing process using a redistribute command.The only easy day was yesterday!
-
mikej412 Member Posts: 10,086 ■■■■■■■■■■cristi.grigore wrote:Cisco says that:
"...(EIGRP) it redistributes a default route as a result of the ip route 0.0.0.0 interface command (but not as a result of the ip route 0.0.0.0 address..."
My opinion is that this is a bug in EIGRP, but Cisco put it in the documentation and it became a feature
What are your thoughts on this?
Could have been poor programming, delivery deadlines, poor specifications, code size issues, etc...
At least they did document it:mike: Cisco Certifications -- Collect the Entire Set! -
cristi.grigore Member Posts: 18 ■□□□□□□□□□So what if R1 is connected via ethernet with the isp border router (one that has proxyARP disabled). This means I can't use a static route pointing to the exit interface. And this means I can't do this kind of default route redistribution via EIGRP.
-
mikej412 Member Posts: 10,086 ■■■■■■■■■■cristi.grigore wrote:This means I can't use a static route pointing to the exit interface.:mike: Cisco Certifications -- Collect the Entire Set!