From: Craig Tompkins (craig.tompkins@verizon.net)
Date: Thu Sep 19 2002 - 23:25:03 GMT-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
OSPF authentication on a virtual link.
http://www.cisco.com/warp/public/104/27.html
I think his point was that you no longer have to have the entire are
with the same authentication. So your virtual link going to area 0
can have authentication while the rest of area 0 doesn't. This is
the per link basis as he stated.
Craig W. Tompkins
Network Engineer
Temecula, CA 92592
760.583.6544
"The credit belongs to the man who is actually in the arena, whose
face is marred by dust and sweat and blood; who strives valiantly;
who errs and comes short again and again, who knows the great
enthusiasms, the great devotions, and spends himself in a worthy
cause; who at best, knows the triumph of high achievement; and who,
at the worst, if he fails, at least fails while daring greatly, so
that his place shall never be with those cold and timid souls who
know neither victory nor defeat."
- -Theodore Roosevelt, "Citizen in a Republic", April 23, 1910
- -----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of frank.yu@japan.bnpparibas.com
Sent: Thursday, September 19, 2002 6:38 PM
To: netsat@optonline.net
Cc: ccielab@groupstudy.com
Subject: Re: ospf authentication
Netsat,
I understand these two types of authentication, but do you mean
virtual
link authentication is independent of BB authentication now? As in
the old
version virtual link authentication has to follow BB authentication
type.
Thanks.
Frank
Internet
netsat@optonline.net@groupstudy.com - 09/20/2002 02:25 AM
Please respond to netsat@optonline.net
Sent by: nobody@groupstudy.com
To: Frank Yu, ccielab
cc:
Subject: Re: ospf authentication
Frank,
The confusion is caused by the fact that there are two ways to do
authentication. The old way, by area, and the new way, by interface.
The
new
way which conforms to the latest RFC was implemented in IOS 12.0.
You can
still use either method
Under the old way if area 0 was configured for authentication then
the
virtual
link
had to mirror that authentication type. Under the new way the
virtual
link
or any other interface does not have to track the area 0
authentication and
can
be any type of authentication or no (null) authentication. Under the
old
way
only one authentication command was required on the interface. Under
the
new
way two authentication type commands are required on the interface.
One
of
these authentication commands lets the IOS know that you are using
the new
authentication type.
any wrote:
> Group,
>
> I know this topic has been talked a lot, but just one thing is
> still
not
> clear in my mind.
> Is there any relationship between virtual link authentication
> and backbone authentication or transit area authentication?
> For example, if ospf backbone has been asked to config as clear
> text authentication and transit area has been asked to config as
> MD5
> authentication, do I have to config virtual link authentication as
> clear text or MD5 or I don't even need to do authentication on
> virtual link?
> Thanks.
>
> Frank
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
> ---------------------------------------------
>
> Ce message et toutes les pieces jointes (ci-apres le
> "message") sont etablis a l'intention exclusive de ses
> destinataires et sont confidentiels. Si vous recevez ce
> message par erreur, merci de le detruire et d'en avertir
> immediatement l'expediteur. Toute utilisation de ce
> message non conforme a sa destination, toute diffusion
> ou toute publication, totale ou partielle, est interdite, sauf
> autorisation expresse. L'internet ne permettant pas
> d'assurer l'integrite de ce message, BNP PARIBAS (et ses
> filiales) decline(nt) toute responsabilite au titre de ce
> message, dans l'hypothese ou il aurait ete modifie.
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPYqG/8BQYrtUgT/NEQJM9QCfboaRrO79ko2qTY0NXJFddZRYJBAAnROZ
e4wVeAPwjRuzRZmKugLHr31K
=2gwt
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:57 GMT-3