RE: ospf auth and network type clarification

From: Volkov, Dmitry (Toronto - BCE) (dmitry_volkov@ca.ml.com)
Date: Mon Sep 09 2002 - 21:06:53 GMT-3


> -----Original Message-----
> From: Nick Shah [mailto:nshah@connect.com.au]
> Sent: Monday, September 09, 2002 7:45 PM
> To: Volkov, Dmitry (Toronto - BCE); ccielab@groupstudy.com
> Subject: Re: ospf auth and network type clarification
>
> > I have to subj fo clarificationj:
> > A) If the Lab requirements: "Configure strongest authent for Area 0"
> > and there are virt links exist in design.
> >
> > We MUST configure authentication for virtual links as well,
> because Virt
> > links are considered to be as part of Area 0.
>
> Yes.
>
> > The following must be done under OSPF process on the
> routers where virt
> > links terminated :
> >
> > 1) "area 0 authentication message-digest"
> > OR
> > 2)
> > "area 1 virtual-link a.b.c.d authentication message-digest"
> >
> > command:
> > " area 1 virtual-link a.b.c.d message-digest-key 1 md5
> ccie" can be added
> in
> > both cases,
> > if it's not added - OSPF will still work but without
> authentication, we
> > will get in this case
> > Message digest authentication enabled
> > No key configured, using default key id 0
>
> Always enable area 0 authentication, AND also explicitly
> specify area 1
> virtual-link blah auth & appropriate authentication type & key. Unless
> explicitly mentioned not to.

Nick,

These BOTH commands below work fine without explicit "area 0 authentication
message-digest":
"area 1 virtual-link a.b.c.d authentication message-digest"
"area 1 virtual-link a.b.c.d message-digest-key 1 md5 ccie"
Isn't it ?

>
> > B) If the Lab requirements: Don't use ospf neigbors command
> and we have FR
> > cloud as one subnet, we have two choices using multipoint
> subs ot physical
> > int:
> >
> > 1) to use "ip ospf network point-to-multipoint" - drawback
> - we get /32
> > routes
> > OR
> > 2) to use "ip ospf network broadcast" - drawback - we have
> to put "ip ospf
> > priority 0" under interfaces/subint on spokes to force HUB to be DR.
>
> If you choose to use option 1, then you must see if there would be any
> summaries needed for IGRP/RIP.

Exactly - because of /32 routes

> If you choose option 2, then also you must see if there are
> any requirements
> of having a backup DR (generally I dont anticipate a scenario
> like this, but
> its possible in case of full mesh), if not, then 'explicitly nail' the
> priorities of spokes to zero and hub to something higher or leave as
> default.

I would say that in partial mesh option 2 is OK. As soon as You assign
priority "0" to spokes
HUB will be DR always and if we loose HUB - who cares about BDR ? since
spokes can not communicate without HUB. My opinion that option 2 is better
for those Hub-Spokes Lab scenarios.
I would prefer option 2 when we have FLSM/VLSM design and option 1 in case
of pure VLSM.

>
> There is one more thing that I would generally nail down, and that is
> router-id's , these I think are not only good practices
> especially when
> using virtual links and also preventing synch issues in case
> of using BGP
> RR's & OSPF. This also makes more sense if you are using meaning ful
> loopback addresses as RID's and want to preserve that
> meaningfulness upon
> reload.

Fully agree.

Thanks a lot.

Dmitry

> rgds
> Nick



This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:47 GMT-3