From: Volkov, Dmitry (Toronto - BCE) (dmitry_volkov@ca.ml.com)
Date: Mon Sep 09 2002 - 21:52:05 GMT-3
> > 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 ?
>
> With the implementation of per-interface authentication, and
> per-interface
> authentication overriding, I guess that affects the virtual
> link as well. So
> the earlier requirement to have similar authentication across
> the virtual
> link (as area 0) has been relaxed.
>
> However I would still stick to whatever authentication is
> defined for area
> 0.
Sorry, don't really understand what do You mean ?
Do You mean if other parts of area "0" have one type of auth, virt link has
to have the same type ? I believe they have to be the same only on
multiaccess media. Of course if lab req say to have the same type in area
"0" - they ave to be the same.
I guess both ways of defining of authentication lead to the same result.
with exceptions:
1) It's easier to put one statement "area 0 authentication [message-digest]"
under ospf process rather than put it under each interface
2) "interface" variant overrides "ospf process" variant
> I also explicitly specify area 0 authentication
> message-digest (or plain
> authentication), and then explicitly specify number 2 ("area
> 1 virtual-link
> a.b.c.d message-digest-key 1 md5 ccie")
>
>
> > 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.
>
> Watch out for scenarios of full mesh, (consider 3 sites, not the
> conventional hub/spoke scenario). In that case, the 2 sites
> should continue
> to talk to each other if the third site goes down. In that
> case it would be
> ideal to have one DR, one BDR and one DROTHER.
There are no problems in this full mesh scenario : if DR gone, BDR will be
promoted to DR and DROTHER will be BDR. I see only problem in extra election
processes in case of failure.
The same time, network type P-2-M doesn't have election process, it forms
adjacencies between
direct neighbors - so it may have less overhead because of that on NMBA
(like FR) medias.
Dmitry
>
> rgds
> Nick
This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:47 GMT-3