From: George Cassels \(gcassels\) (gcassels@cisco.com)
Date: Fri Apr 22 2005 - 08:44:50 GMT-3
Paresh,
It is definitely the route-map, and is the reason I made a point to
say if you add a redistribute connected command you have to add all
connected routes to the route-map. Here is a really good explanation I
got from another individual that I thought I would pass on.
So when you configure redistribute connected with a route-map and the
route-map allows only the 10.20.20.0 network to be redistributed, all
other connected links are excluded including the 10.2.2.0/24 and
10.3.3.0/24 from the respective OSPF/EIGRP routing processes. This
restriction takes precedence over the fact that you also have a
"redistribute eigrp" command under ospf and a "redistribute ospf" under
eigrp. The fact that these routes a CONNECTED OSPF routes and CONNECTED
EIGRP routes is the key factor. Their CONNECTED characteristic/attribute
takes precedence over their assignment to an IGP.
To prove this, add one of these networks to the route-map restricting
the redistribute connected process. For example, add the 10.2.2.0/24
network to the route-map and you will then see the route in the OSPF
tables/routing tables as external.
Remember this "dual citizenship" role of connected routes assigned to
IGP's.
They are both a connected route and an IGP assigned route. And when it
comes to redistribution and filtering of routes during the
redistribution process, the connected characteristic takes precedence
over the IGP assigned characteristics. This precedence of routing
sources is associated with administrative distance values. Connected
always has the lowest AD.
George L. Cassels
Network Consulting Engineer - FSP Team
E-mail: gcasssels@cisco.com
epage: gcassels@epage.cisco.com
Phone: 919.392.1650
Cell: 919.669.6067
Page: 800.365.4578
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Paresh Khatri
Sent: Thursday, April 21, 2005 10:06 PM
To: George Cassels (gcassels); ccielab@groupstudy.com
Subject: RE: route redistribution question
Hey George,
It's your route-map (i.e route-map connected) that is blocking those
connected networks because the origin protocol for each of the connected
routes is 'connected' after all, as it appears in the route-table, even
though they are being injected because the route-protocol that is
running over those interfaces is getting redistributed.
I still believe the connected interfaces over which the source protocol
runs are being redistributed; they just got blocked by your route-map.
I don't think there is any way of really testing it because if you open
up the connected routes within the connect route-map, then they are
being let through due to 'red connected'....
Paresh.
-----Original Message-----
From: George Cassels (gcassels) [mailto:gcassels@cisco.com]
Sent: Friday, 22 April 2005 11:41 AM
To: George Cassels (gcassels); Paresh Khatri; Lanny Ballard;
ccielab@groupstudy.com
Subject: RE: route redistribution question
All I labbed it up and see attached. R1 and R3's router configs did not
change from the initial configs in the router configs before redistr
connected doc, but notice that in the ip routing table after the
redistribution that R3 no longer has 10.2.2.0 and that R1 no longer has
10.3.3.0 in the routing table. I attached a diagram for clarity.
George
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
George Cassels (gcassels)
Sent: Thursday, April 21, 2005 9:07 PM
To: Paresh Khatri; Lanny Ballard; ccielab@groupstudy.com
Subject: RE: route redistribution question
Paresh,
No what I am saying is if you redistribute an interface as
connected that does not have any routing protocol running over it such
as a loopback that does not have a network statement under any routing
protocol. From that moment on any interface that DOES have a routing
protocol running over it will no longer redistribute as you said below.
So in Lanny's first email the network 10.5.5.0 that was in the routing
table as connected, but redistributed because it was part of OSPF will
no longer redistribute into EIGRP after I do redistribute connected for
the loopback that was not covered by any routing protocol. I know you
won't believe it but try it....
George L. Cassels
Network Consulting Engineer - FSP Team
E-mail: gcasssels@cisco.com
epage: gcassels@epage.cisco.com
Phone: 919.392.1650
Cell: 919.669.6067
Page: 800.365.4578
-----Original Message-----
From: Paresh Khatri [mailto:Paresh.Khatri@aapt.com.au]
Sent: Thursday, April 21, 2005 8:59 PM
To: George Cassels (gcassels); Lanny Ballard; ccielab@groupstudy.com
Subject: RE: route redistribution question
Hi George,
In your test setup, are other interfaces over which OSPF is running
still advertised into EIGRP, or did you not have OSPF running over any
other interfaces ?.
In the example you have cited, you are redistributing connected
interfaces into OSPF - that does not mean that you are running OSPF over
the interface and hence, it should not be injected into EIGRP. So that
initial statement of mine still holds. Redistribution is not transitive
i.e if you redistribute from protocol X into protocol Y and then
redistribute protocol Y into protocol Z, routes from protocol X will NOT
get redistributed into protocol Z - which is consistent with your
performance.
Appreciate your response.
Paresh.
-----Original Message-----
From: George Cassels (gcassels) [mailto:gcassels@cisco.com]
Sent: Friday, 22 April 2005 10:45 AM
To: Paresh Khatri; Lanny Ballard; ccielab@groupstudy.com
Subject: RE: route redistribution question
Lanny I have also noticed that if you redistribute any interface as
redistribute connected the statement below from Paresh is not longer
true. So say I did the following because we will say loopback 0 was not
included in any routing protocol and the requirement is for full IP
connectivity.
Router OSPF 1
Redistribute connected route-map connected subnets
Route-map connected permit 5
Match interface loopback 0
After I do the above the connected interfaces over which the source
protocol is running will no longer be injected from OSPF to EIGRP. So in
your case the 10.5.5.0 network would also need to be added to the
redistribute connected. This seems to hold true no matter which
protocol the router is running that is doing the redistribute connected.
Try is out and see if the same happens to you.
George
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Paresh Khatri
Sent: Wednesday, April 20, 2005 8:46 PM
To: Lanny Ballard; ccielab@groupstudy.com
Subject: RE: route redistribution question
Hi Lanny,
When redistributing routes, routes for the connected interfaces over
which the "source" protocol is running are injected as well...
HTH,
Paresh.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Lanny Ballard
Sent: Thursday, 21 April 2005 10:34 AM
To: ccielab@groupstudy.com
Subject: route redistribution question
I am doing yet another route redistribution lab, and i have a question I
was under the assumption that in order to redistribut a route into a
routing protocol, that route had to be in the rout table; however, i
have done a lab recently where I was redistribution ospf into eigrp, and
eigrp advertised a route that was connected, and not an ospf route.
here is the example.
route 5 is mutually redistributing between ospf and eigrp.
Now if you notice I have added 10.5.5.5 to the ospf process. This
address is a loopback interface. But eigrp is also advertising it. Why
is this? I thought eigrp should only advertise this route if it was in
the route table as an ospf route, but it is in the route table as
connected.
C 10.5.5.0 is directly connected, Loopback0
router eigrp 100
redistribute ospf 1 metric 1544 100 255 1 1500 network 172.150.1.5
0.0.0.0 no auto-summary !
router ospf 1
router-id 10.5.5.5
log-adjacency-changes
area 0 authentication message-digest
area 1 nssa default-information-originate redistribute eigrp 100 metric
10 subnets network 10.5.5.5 0.0.0.0 area 0 network 172.150.5.5 0.0.0.0
area 0 network 172.150.8.5 0.0.0.0 area 1 neighbor 172.150.5.6 neighbor
172.150.5.2
TIA for any help!
Lanny
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:55:06 GMT-3