From: Legend Zhu (legendyz@xxxxxxxxxxxxxxxxx)
Date: Wed Nov 08 2000 - 07:06:55 GMT-3
Hello zhangxianqi,
Wednesday, November 08, 2000, 10:38:12 AM, you wrote:
Let's see what will happen after you configure the follow command:
First in first the router only prefer the lowest AD route to a same
destination, in your configuration I think all the command happen in
a same Cisco box, so router only prefer the "C" route which means
"connect" because the "connect" has AD number 0 and all other routing
protocol's AD is larger than that.
But what will happen when you configure "redistribute" command in your
"rip" protocol? All directly attached interface ip address will be
redistribute into RIP and of course RIP will pick up all this
information into RIP process , now, in router there are two kinds of
information appear one from RIP and another from it's own
interface,guess which one the router will prefer, yes, the one from
his own interface because this is marked as "c", BUT, don't forget
there is another same copy is actually in the RIP process, all these
information in RIP process will definitely be redistributed into OSPF
because you have configured that in your OSPF process, hence, there
will be another copy of the same information will be in your OSPF
database and all these information in OSPF will be exchanged with
other OSPF routers in your network.
Anyway, the following configuration will not affect in the router
which you have configured it. Actually it will effect the OSPF
database. The proctor is right that this configure will prevent your
OSPF demand circuit flapping. Let's discuss why it can really prevent
it. Please don't forget in your configured router, it is act as a
ASBR between your OSPF partition and RIP partition. The main
objective of the following configuration is focus on the link between
your OSPF network and RIP network. Usually we call this is area is
DMZ, and also usually OSPF will not include this area in OSPF
configuration for security purpose and look back what RIP will do, if
this area's ip address is the same classful address space with your
interface in OSPF partition ( i.e. this interface's address is 121.1.1.0
and other interface in OSPF area is 121.1.2.0) RIP has no way to prevent
to include this address in his process (command " router rip --> network
121.1.0.0" ). The problem here is your OSPF network want full connectivity
within all the network which include this DMZ and RIP partition.
Only way is redistribute but you can implement different solution:
>From RIP and passive the RIP process from OSPF interface and
redistribute back from OSPF to RIP process. This we call it two ways
redistribution. Normally the injected routes from RIP to OSPF will
carefully filter when redistribute from OSPF back to RIP, but look
at the link between your ASBR to another RIP router, this link's address
normally been configured in RIP process and you want it been
redistributed into OSPF, things happen here, as I early mentioned
this link in your router will be marked as "C" even you have configured
it in RIP process, hence, OSPF will NOT get this information from RIP
so in the rest of your OSPF network which not directly connect to this
link can not ping this DMZ area. You may want to redistribute it from
connect to OSPF, OK, this is another solution but also has bug. This
bug is now this link has been injected from "connect" to OSPF process.
It is as well no problem in this very router which you configured
redistribution action because this link still been marked as "c" but
think again, this very link has been injected into OSPF and then IT
WILL BE REDISTRIBUTE FROM OSPF TO RIP, and then from RIP to OSPF again
as you have configured redistribute from RIP to OSPF. This fact will
cause your OSPF database in-stable. Look back the proctor's word "it
will cause OSPF demand circuit flapping". The OSPF demand circuit
configuration will not bring up the ISDN line unless the OSPF DATABASE
INFORMATION CHANGE. Suppose if the database is in-stable of course
the ISDN line will up and down regularly which we call "flapping". If
you ISDN line flapping, HEY HEY!!!.... Guess what will the proctor
tell you...... try next attemp, of course......
~~~~~~~~~o o~~~~~~~~~~
P
So follow the configuration which the proctor gave you can make the
OSPF database clearly stable, because the connect link has been first
redistribute to RIP and then go into OSPF, of course when you
redistribute back from OSPF to RIP, filter this route.
Another solution to prevent loop and flapping I think you can
redistribute connect when you configure OSPF and when you configure
RIP protocol when redistribute from OSPF, Filter this link.
I think these two solutions (proctor's and mine ) almost do the same
thing but the proctor's first let the link come into RIP and my
solution just let the link directly inject into OSPF.
Hope this help
z> in power session of beijing,the procotor present a slide and say this will p
roduce route loop and make ospf demand circuit flap,the slide is like that:
z> router ospf 1
z> redistribute rip subnet
z> network 1.0.1.0 0.0.0.255 area 0
z> router rip
z> redistribute connected
z> default-metric 2
z> network 3.0.0.0
z> i try it,but can't produce loop,so what it mean? please the person who atten
d the power session recall it and give me a answer,thanks in advance.
z> ----- Original Message -----
z> From: David FAHED
z> To: zhangxianqi
z> Cc: ccielab@groupstudy.com ; zhang zhichao
z> Sent: Tuesday, November 07, 2000 10:17 PM
z> Subject: Re: ospf redis
z> It is true with a distance vector protocol if ip split horiton is turned o
ff permanent routing loops can form in the internetwork. But I think with link
state protocol it is not possible.
z> zhangxianqi wrote:
z> hi allI hearded because the ospf have not split-horizen,so when ospf an
d another igp do mutual redistribution,there maybe produce route loop,but when
I try it,I can't produce the loop.can
z> someone give me a example,thanks in advance.
Best regards,
mailto:legendyz@public.sta.net.cn
Zhu Yi Ming
Office : +8612-52985255
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:25:43 GMT-3