From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Sun May 14 2006 - 12:05:53 ART
No worries, Shamin. Redistribution can be a interesting topic. When you do redistribution, this includes (by default) the connected interfaces that are included in the routing process. However, if you also perform redistribution of (for example), a loopback, and don't include a second route-map (as in my example). You are essential breaking the redistribution of the former connected interface that was covered by the routing protocol. Keep in mind, that you only need to do this to avoid breaking redistribution of the routed connected interfaces. In other words... Only needed when redistruting protocol and connected interfaces on the same router.
I hope this helps cover you question. Maybe some of the experts can chime in.
Dave Schulz
*** Sent from my Blackberry ***
-----Original Message-----
From: Shamin <ccie.xpert@gmail.com>
To: Schulz, Dave <DSchulz@dpsciences.com>
Sent: Sun May 14 10:06:36 2006
Subject: Re: redistributing localy injected routes [20060510]
Dave,
A basic Redistribution question,
When doin redistribution, for eg into OSPF. With the "Redistribute rip subnets" command under the OSPF proces , by default, will it not redistribute the connected interfaces , even if the the connected interfaces are in the RIP process?.
I hope you understood my question. I am still a novice. Just tryin to make things clear. I will lab it for sure, but your input will be appreciated!
thanks
shamin
On 5/14/06, Schulz, Dave <DSchulz@dpsciences.com> wrote:
Yes, the second permit statement is necessary to cover the interface that is covered by the routing protocol and is also connected. Otherwise, you can break the redistribution of the connected interface, that is part of the redisribution process. It is not necessary to this on routers where you are not redistributing one protocol into another, but only redistruting connected interfaces. HTH
Dave Schulz
*** Sent from my Blackberry ***
-----Original Message-----
From: Shamin <ccie.xpert@gmail.com>
To: Schulz, Dave < DSchulz@dpsciences.com>
Sent: Sat May 13 10:57:33 2006
Subject: Re: redistributing localy injected routes [20060510]
Dave,
I read through your config. Didnt understand the requirement for the " route-map LOOP 20".
From what you have labbed, I understand that, it is necessary to have a routemap matching the connected interfaces, inorder to redistribute the connected interfaces. Is my understanding in the right direction?
regards
shamin
On 5/11/06, Schulz, Dave <DSchulz@dpsciences.com> wrote:
San -
There should not be an issue, unless you are redistributing connected
interfaces. This is where many issues arise (redistributing connected
interfaces), since the redistribution already includes the connected
interfaces. When you redistribute connected interfaces, then you must
take care how you do this, since you can easily break the redistribution
process. Also, if you are redistributing connected interfaces (a
loopback, for example), into OSPF and redistributing OSPF into RIP on
the same router, then I find it necessary to redistribute the connected
interfaces into RIP as well. Same thing would hold true for the RIP
into OSPF.
I labbed up a little scenario here for you......
There is a frame link from R1 to R2 running OSPF. And, a serial link
from R2 to R5 running RIP. Here is the configuration at R2 that works
and allows all links and interfaces to be pinged from R1 or R5. Without
the redistributed route-map on both protocols, you will not see the
loopback from the side missing the redistributed connected. Hope this
helps.
!
!
!
interface Loopback0
ip address 2.2.2.2 <http://2.2.2.2/> 255.255.255.0 <http://255.255.255.0/> <http://255.255.255.0 <http://255.255.255.0/> >
!
interface Serial0/0
ip address 192.168.1.2 <http://192.168.1.2/> 255.255.255.0 <http://255.255.255.0/>
encapsulation frame-relay
ip ospf priority 0
frame-relay map ip 192.168.1.1 <http://192.168.1.1/> 201 broadcast
frame-relay map ip 192.168.1.2 <http://192.168.1.2/> 201
frame-relay map ip 192.168.1.3 <http://192.168.1.3/> < http://192.168.1.3 <http://192.168.1.3/> > 201
no frame-relay inverse-arp
!
interface Serial0/1
ip address 25.5.5.2 <http://25.5.5.2/> 255.255.255.0 <http://255.255.255.0/>
!
router ospf 1
log-adjacency-changes
redistribute connected subnets route-map LOOP
redistribute rip subnets
network 192.168.1.0 <http://192.168.1.0/> 0.0.0.255 <http://0.0.0.255/> area 0
!
router rip
version 2
redistribute connected metric 1 route-map LOOP
redistribute ospf 1 metric 1
passive-interface default
no passive-interface Serial0/1
network 25.0.0.0 <http://25.0.0.0/> < http://25.0.0.0 <http://25.0.0.0/> >
no auto-summary
!
!
route-map LOOP permit 10
match interface Loopback0
!
route-map LOOP permit 20
!
Dave Schulz,
Email: dschulz@dpsciences.com < mailto:dschulz@dpsciences.com <mailto:dschulz@dpsciences.com> > <mailto:dschulz@dpsciences.com%20>
________________________________
From: san [mailto: san.study@gmail.com <mailto:san.study@gmail.com> ]
Sent: Thursday, May 11, 2006 12:05 AM
To: Schulz, Dave
Cc: Koen Zeilstra; ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>
Subject: Re: redistributing localy injected routes [20060510]
Dave,
I am seeing a different behaviour for RIP.
Connected Interfaces of RIP network gets redistributed to OSPF .....when
"redistribute rip subnets" under ospf.
Connected Interfaces are present in RIP database & not in Routing table
as connected.
Is this an exception for RIP ?
On 5/10/06, Schulz, Dave < DSchulz@dpsciences.com <mailto:DSchulz@dpsciences.com> > wrote:
Zoen -
There is a lot to discuss here, but one item that helped clear up
redistribution for me, was understanding what is redistributed from
where (RIB or database). When you redistribute from one protocol to
another, it will look in the routing table (not the database) to
determine which routes to redistribute. So, when you redistribute RIP
into OSPF, it is going to pull the routes that are in the routing table
that are learned by RIP, if the route was already learned by EIGRP
(having a better admin distance, then it will not get redistributed.
So, if you redistribute from RIP to OSPF to EIGRP....the route that is
in the route table is redistributed from that routing protocol, even
though they are in the database. And, you will not have the same route
in the routing table from three different protocols.
Dave Schulz,
Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com>
-----Original Message-----
From: nobody@groupstudy.com < mailto:nobody@groupstudy.com <mailto:nobody@groupstudy.com> > [mailto:nobody@groupstudy.com] On Behalf Of
Koen Zeilstra
Sent: Wednesday, May 10, 2006 7:49 AM
To: ccielab@groupstudy.com < mailto:ccielab@groupstudy.com <mailto:ccielab@groupstudy.com> >
Subject: redistributing localy injected routes [20060510]
Hi Group,
I have 3 questions regarding redistribution.
Q1.
2 steps:
1. Make an interface part of an IGP via the network statement
2. Redistribute that IGP into another IGP via another link.
In some occasions this will work. For example RIP -> OSPF. Because rip
sees the routes part of the network statement as redistributed from
connected.
I have seen it working for OSPF -> EIGRP as well.
Why doesn't it work for others? Ie. what rule prohibits this.
Q2.
Why doesn't a redistribute RIP to OSPF to EIGRP on the same router work?
Q3.
This merely sums up the questions above I guess. When redistributing,
does
the redistribution process go from database to database directly or via
the general routing table? For example does a OSPF proces redistributes
EIGRP routes from the EIGRP topology or from the EIGRP routes in
the routing table?
thanks,
Koen
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html <http://www.groupstudy.com/list/CCIELab.html>
--
Thanks & Rgds
SAN
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:21 ART