|
For those who don't have the book, the problem is
mutual redistibution from rip to ospf and ospf to rip. The admin distance
of OSPF is lower so without any distro lists or filters, a routing loop is
formed.
What he is saying makes sense - you don't want to
advertise a route redistributed into ospf from rip, back to rip again.
That doesn't solve the problem he's talking about though.
For this scenerio to work ( I think ) you need to
actually do a combo of things:
1. Use a route map to deny the 172.16.1.0 /24
network from being redistro from ospf to rip
2. Set the admin distance on the
redistributing routers for RIP to be lower than OSPF. This will stop the
routers from preferring the OSPF routes advertised by OSPF-11 - even though as
soon as the RIP route is gone, a loop will still occur.
OR
3. Use a distribute list on the redistro
routers in the ospf process that denies the 172.16.1.0 /24 network. I
actually don't think this can be done - cuz OSPF is a link state
protocol
So the commands for the 3rd option might be
something like:
!!On router RIP-10
router rip
network 172.16.1.0
!!On Border-1 and Border-2
router ospf 1
network <link to area 0> etc...
redistribute rip subnets route-map rip_in
in
distribute-list 2 in serial0
##possible link to ospf area
0
router rip
network 172.16.2.0 ( possible link to RIP-10
)
redistribute route-map ospf_in in
access-list 1 permit 172.16.1.0
255.255.255.0 access-list 2 deny 172.16.1.0
255.255.255.0
access-list 2 permit any route-map ospf_in permit 10
match address 2
route-map rip_in permit 10
match address 1
I know OSPF is a Link state protocol, so the LSDB
on Border-1 and 2 will have the 172.16.1.0 network, but the route will not be
installed in the routing table because of the "distribute-list 2 in serial0"
Does this make sense to anyone? Will this
work ( I'll lab it later - for now I'm stuck in a hotel room with no lab access
).
Kenny
|
