From: fwells12 (fwells12@xxxxxxxxxxx)
Date: Sat Nov 24 2001 - 04:45:53 GMT-3
http://www.cisco.com/warp/public/104/10.html
----- Original Message -----
From: "Albert Lu" <albert_ccie@yahoo.com>
To: "'Brian Hescock'" <bhescock@cisco.com>
Cc: <ccielab@groupstudy.com>
Sent: Monday, November 19, 2001 10:41 PM
Subject: RE: update: redistribution of directly connected networks
> Brian,
>
> I'm not sure what you meant by the requirement to have an intra or inter
> area to a non-zero forwarding address. Could you please elaborate, or
> explain.
>
> Thanks
>
> Albert
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Brian Hescock
> Sent: Tuesday, November 20, 2001 2:34 AM
> To: albert_ccie@yahoo.com
> Cc: ccielab@groupstudy.com
> Subject: Re: update: redistribution of directly connected networks
>
>
> Albert,
> Sounds correct. But I tend to avoid "redist connected" because it
> basically gives you a noose to hang yourself with, particularly with ospf.
> Read up on the ospf "fowarding address", as seen in "show ip ospf database
> external", and the requirement to have an intra or inter area route to a
> non-zero forwarding address.
>
> B.
>
> Albert Lu wrote:
>
> > 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