From: kasturi cisco (kasturi_cisco@hotmail.com)
Date: Thu Feb 05 2004 - 13:10:34 GMT-3
Ellie,
This is how i do it and know it.
Whenever u redistribute ISIS into OSPF it does not redistribute connected
interfaces running ISIS into OSPF. You will also have to give
"redistribute connected" to have this direclty connected interfaces
running ISIS into OSPF. I have seen other routing protocols redistribute
into OSPF and of course other protocols into one another in gen.
Also when u redistribute any routing protocol say 1 into any other
protocol say 2 (the target or Rx protocol), remember to also redistribute
the directly connected interfaces running protocol one also. Then check
all aspects like route-maps ,filters etc to ensure that all
expected/required networks or subnets are there ELSE u may have
redistribute connected also.
I would always check every scenarion rather than building a thumb rule as
there have been some variations with IOS versions and it is diificult to
remember all rules for all protocols for version changes too...make it
complicated (at least for me).
Here is a good post by Brian Dennis which i have seen.. may be it helps.
-------------------------
This is the expected behavior between OSPF, IS-IS, EIGRP and RIP. I
haven't tried it with any other protocols. Think of route redistribution
as being two steps. The first step is to get the routes that the other
routing protocol is sending to the routing table. The second step is to
get the connected interfaces that are being advertised by the other
protocol.
router ospf 1
redistribute connected subnets route-map DEFAULT <-- Second Step
redistribute eigrp 100 subnets tag 100 <-- First Step
network 172.16.123.0 0.0.0.255 area 0
!
route-map DEFAULT permit 10
match interface FastEthernet0/1
Now because this second step involves getting the connected interfaces
that show up (show ip route x.x.x.x) as being "advertised by" the other
routing protocol, IS-IS connected interfaces do not get redistributed
in. Why? Because unlike other routing protocols, connected interfaces
that are being advertised by IS-IS do not show up as being "advertised by
IS-IS". So this breaks the second step for IS-IS and is the reason we
have to manually redistribute the connected interfaces that are running
IS-IS when redistributing IS-IS into another routing protocol. Here we
can see what protocols these interfaces are being advertised by.
Notice that the interface running IS-IS does not say "advertised by".
Rack1R6#sho run int atm0/0/0.4
interface ATM0/0/0.4 point-to-point
ip address 54.1.2.6 255.255.255.0
ip router isis
pvc 1/100
!
end
Rack1R6#sho ip route 54.1.2.6
Routing entry for 54.1.2.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via ATM0/0/0.4
Route metric is 0, traffic share count is 1
Rack1R6#
Rack1R3#sho run int s1/2
interface Serial1/2
ip address 163.1.13.3 255.255.255.0
end
Rack1R3#sho ip route 163.1.13.0 255.255.255.0
Routing entry for 163.1.13.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Advertised by ospf 100 <-- ADVERTISED BY
Routing Descriptor Blocks:
* directly connected, via Serial1/2
Route metric is 0, traffic share count is 1
Good Luck,
Kasturi.
------------------------------------------------------------------------
Easiest Money Transfer to India. Send Money To 6000 Indian Towns. Easiest
Way To Send Money Home!
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 07:13:46 GMT-3