From: Albert Lu (albert_ccie@xxxxxxxxx)
Date: Mon Nov 19 2001 - 05:40:14 GMT-3
Brian,
I know that this is an old thread, but I just wanted to share my experiences
on redistributing connected.
The scenario I was working on was with RIP, IGRP, and connected
redistributing into OSPF. From the config, you can see that the networks of
RIP and IGRP overlap each other, since they can only define classful
networks.
Redistributing one routing process at a time, starting with RIP and tagging
them. It can be seen that all directly connected networks that cover the
150.50.0.0 boundary that is not part of OSPF is redistributed.
After that, IGRP is redistributed into OSPF, and it can be seen that IGRP
has taken over the directly connected routes that RIP has redistributed.
>From what Doyle says, it is because IGRP has a lower admin distance than
RIP.
Finally, redistributing connected with a tag, it can be seen that it
redistributes "ALL" directly connected networks of the router that is not
part of OSPF. I believe that it is because connected has the lowest admin
distance out of all of them.
I'm not sure whether this is correct behavior, my explanation sounds
logical. I just wanted to make sure, and see what you can add from your
findings.
Thanks
Albert
Here is a section of my config:
interface Loopback0
ip address 200.0.0.2 255.255.255.255
!
interface Loopback1
ip address 172.16.0.1 255.255.0.0
!
interface Ethernet0
ip address 150.50.17.2 255.255.255.0
!
interface Serial0
no ip address
shutdown
no fair-queue
!
interface Serial1
no ip address
encapsulation frame-relay
!
interface Serial1.1 point-to-point
ip address 150.50.24.2 255.255.255.0
frame-relay interface-dlci 104
!
interface Serial1.2 multipoint
ip address 150.50.100.2 255.255.255.224
ip ospf network point-to-multipoint
frame-relay interface-dlci 105
frame-relay interface-dlci 106
!
interface BRI0
ip address 150.50.9.2 255.255.255.192
shutdown
isdn x25 static-tei 0
!
router ospf 10
log-adjacency-changes
redistribute connected metric-type 1 subnets tag 3
redistribute rip metric 100 metric-type 1 subnets tag 1
redistribute igrp 10 metric 10 metric-type 1 subnets tag 2
network 150.50.100.0 0.0.0.31 area 0
!
router rip
passive-interface default
no passive-interface Ethernet0
network 150.50.0.0
!
router igrp 10
passive-interface default
no passive-interface Serial1.1
network 150.50.0.0
!
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Brian Hescock
Sent: Wednesday, October 24, 2001 6:55 AM
To: ccielab@groupstudy.com
Subject: update: redistribution of directly connected networks
I've spoken with several Cisco Development Engineers and here's the
correct behavior regarding whether we redistribute directly connected
networks:
The correct behavior is to redistribute directly connected networks as
long as the network is covered by a network statement in the protocol to
be redistributed. It's a bug if the directly connected network isn't
redistribued in that situation. So the statement "we only redistribute
from the routing table" is incomplete, we redistribute routes from the
routing table and those directly connected networks covered by a network
statement in the protocol to be redistributed.
Example:
int e 0
ip add 10.1.1.1 255.255.255.0
int e 1
ip add 10.2.2.1 255.255.255.0
router rip
network 10.0.0.0
router ospf 1
network 10.2.2.1 0.0.0.0 area 0
redistribute rip metric 100 subnets
10.1.1.0 /24 is known as a directly connected route. But it's included
under the 10.0.0.0 network statement under router rip so the network is
flagged by rip and ospf will then redistribute the directly connected
network. You do not need to use "redistributed connected" unless you
don't have a network statement that doesn't cover the network on the
interface. So if ethernet 2 was 9.1.1.1, it wouldn't be redistributed
unless you use "redistribute connected" since 9.1.1.1 doesn't fall under
the 10.0.0.0 network statement. But it would be redistributed if you
had "network 9.0.0.0" under router rip also.
So the answer is any behaviour you see in earlier code where it doesn't
redistribute in this situaiton is a bug and where it does redistribute
in 12.1 and 12.2 is correct. This wasn't a change in behavior, just
bugs in earlier code where you saw the problem.
Please let me know if I've made a typo that changes the meaning and I'll
send out a correction, thanks.
Brian
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:18 GMT-3