From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Tue Jun 08 2004 - 20:40:51 GMT-3
Boy, I've (re)learned a lot of dialer watch today.
It seems that dialer watch has changed quite a bit from my previous
in-depth analysis.
First, asnwering your question, I would not say it's poor design to do
some "routing engineering". What I was proposing would not change what
was available/routable, but which specific prefix was in the route table
to control dialer watch.
But then, the whole thing (I said) is wrong according to current
dialer-watch workings.
Now, dialer watch does know the outgoing interface assigned to the
current route table entry, and it will consider "PRIMARY DOWN" as long
as the interface is the DDR interface. So basically what you need is for
the current routing protocol to prefer the primary (frame relay) route
when both are up, for dialer-watch to see "PRIMARY UP" and tear down the
DDR. (So I agree with Richard in that this seems to be an OSPF
cost/select issue).
I don't agree with the layer2/3 mapping not implying a connected route.
Dialer watch does use the layer 2 mapping scheme to determine the
destination to dial, and so uses a layer 2 scheme, which is what the
"Connected" routing protocol uses. So yes, you see the watched route
"Connected" for as long as the watch is active! (But OSPF does not know
about that and it will try to install the other route, at which time
dialer watch will remove the "phantom" connected route).
To make matters even more interesting, OSPF does have its own on-demand
scheme but almost every example of DDR bypasses that by filtering OSPF
from interesting traffic. Making OSPF on-demand work has its own troubles...
Sorry about the previous miss-guiding advice...
-Carlos
jean.paul.baaklini@accenture.com wrote:
> Carlos,
>
> Thanks for your comments, I appreciate mate.
>
> Just one last word then.
>
> Is it honest to say that that kind of network would be an example of
> poor design as normally, we should be able to have IP connectivity
> throughout the network?
>
> Cheers guys,
> JP
>
> -----Original Message-----
> From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
> Sent: 08 June 2004 11:55
> To: Baaklini, Jean paul
> Cc: ccielab@groupstudy.com
> Subject: Re: dialer watch and OSPF
>
> No, I'm talking about not learning that prefix via the ISDN link.
> You can filter some prefixes from specific neighbours...
>
> If your target is to have full time access to R3's loopback, then I
> guess is not the best candidate to watch. Try watching a remote link
> (may be R2-R3) or have R3 to also advertize a summary that covers the
> loopback too.
> (You can watch the detail /32 and filter that in the ISDN link, but be
> able to receive a more general route that keeps the connectivity
> requirement).
>
> jean.paul.baaklini@accenture.com wrote:
>
>
>>Are you talking about blocking the prefix at all?
>>
>>But then I would miss the whole point of having a dialer watch... I
>
> did
>
>>all this to be able to access R3's loopback in case of a failure on
>
> the
>
>>primary link.
>>
>>-----Original Message-----
>>From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
>>Sent: 08 June 2004 11:24
>>To: Baaklini, Jean paul
>>Cc: ccielab@groupstudy.com
>>Subject: Re: dialer watch and OSPF
>>
>>What about filtering (distribute-list) the watched route on the ISDN
>>link ?
>>
>>jean.paul.baaklini@accenture.com wrote:
>>
>>
>>>Hi all,
>>>
>>>
>>>
>>>If you conisdere the following layout:
>>>
>>>
>>>
>>> FR FR
>>>
>>>R1-----R2-----R3
>>>
>>>|____________|
>>>
>>> ISDN
>>>
>>>
>>>
>>>We have enabled ospf everywhere on this network, and used a dialer
>>
>>watch
>>
>>
>>>on R1 to "track R3's loopback interface".
>>>
>>>The problem is when ISDN comes up, the route to R3's loopback appears
>>>then as connected (there's layer 3 to layer 2 mapping).
>>>
>>>Thus, even when the Frame-relay path comes back up, the ISDN line
>>
>>stays
>>
>>
>>>up...
>>>
>>>
>>>
>>>How can I make the route leant through OSPF to be preferred?
>>>
>>>
>>>
>>>Your comments would be much appreciated.
>>>
>>>
>>>
>>>Thanks
>>>
>>>
>>>
>>>Regards,
>>>
>>>JP
>>>
>>>
>>>
>>>This message is for the designated recipient only and may contain
>>
>>privileged,
>>
>>
>>>proprietary, or otherwise private information. If you have received
>>
>>it in
>>
>>
>>>error, please notify the sender immediately and delete the original.
>>
>>Any
>>
>>
>>>other use of the email by you is prohibited.
>>>
>>>
>>
>>
> _______________________________________________________________________
>
>>>Please help support GroupStudy by purchasing your study materials
>>
>>from:
>>
>>
>>>http://shop.groupstudy.com
>>>
>>>Subscription information may be found at:
>>>http://www.groupstudy.com/list/CCIELab.html
>>>
>>
>>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:36 GMT-3