From: Nick Shah (nshah@xxxxxxxxxxxxxx)
Date: Thu May 23 2002 - 23:46:46 GMT-3
I have seen exact same behaviour... ie. virtual links dont need to enable
authentication. However, I am inclined to think that this is the result of
the RFC2178 implementation (which outlines per-interface auth., superseded
by RFC 2328) hence you could mix n match, null auth (no auth), simple
passwd. auth, md5 etc. across different sets of links in the same area.
Here is the *very little* clarification / explanation that I could find on
the CCO
To support per-interface authentication type as described in
RFC2178, the following command is added for interface configuration
mode:
ip ospf authentication [message-digest | null]
Authentication type may also be specified for a virtual link:
area <id> virtual-link <id> authentication [message-digest | null]
...(other virtual link parameters)...
Authentication type may also be specified for an area. If authentication
type is specified for an interface or virtual link, that type will be
used. Otherwise, the interface or virtual link will use the authentication
type specified for the area. The area defaults to no authentication
(referred to as Null authentication in RFC2178).
And from RFC 2178...
All OSPF protocol exchanges are authenticated. This means that only
trusted routers can participate in the Autonomous System's routing.
A variety of authentication schemes can be used; in fact, separate
authentication schemes can be configured for each IP subnet.
So what I am understanding is that if auth. is not specified for virtual
link, its defaulting to *null* auth. and succeeds as per CCO notes & RFC
notes.
hth
Nick
----- Original Message -----
From: <Ian.C.Stong@mail.sprint.com>
To: <ccielab@groupstudy.com>
Sent: Friday, May 24, 2002 4:53 AM
Subject: Good Ole OSPF virtual-link authentication question !!!
> I've come across some confusion regarding authentication and virtual
> links with OSPF. It seems to work two different ways with
> authentication key parameters specified as well as without. Lab 20 is
> an example using authentication.
>
> So to further explain my question let me lay out a scenario and hope for
> some input into the whats and whys.....
>
> Scenario 1
>
> MD5 authentication in area 0 only. Networks - 192.168.x.0/24 via e0's
>
> R3 --- area 2 --- R2 --- area 1 --- R1 --- area 0 --- R0
>
> 192.168.3.2 -- .3.1 | .2.2 -- .2.1 | .1.1 -- .1.0
>
>
> So the obvious is area 2 needs a virtual link through area 1 and note
> that area 0 is using md5 authentication - config follows:
>
> R3
>
> router ospf 1
> net 192.168.3.0 0.0.0.255 area 2
>
>
> R2
>
> router ospf 1
> net 192.168.3.0 0.0.0.255 area 2
> net 192.168.2.0 0.0.0.255 area 1
> area 1 virtual-link 192.168.2.1
> area 0 authentication message-digest
>
>
> R1
>
> int e0
> ip ospf message-digest-key 1 md5 cisco
>
> router ospf 1
> net 192.168.2.0 0.0.0.255 area 1
> net 192.168.1.0 0.0.0.255 area 0
> area 0 authentication message-digest
> area 1 virtual-link 192.168.2.2
>
>
> R0
>
> int e0
> ip ospf message-digest-key 1 md5 cisco
>
> router ospf 1
> net 192.168.1.0 0.0.0.255 area 0
> area 0 authentication message-digest
>
>
> Using this scenario R3 is able to see OSPF data from router 1.
>
> I've also seen this work by adding key information on the virtual-link
> line.
> So R2 would be: area 1 virtual-link 192.168.2.1 message-digest-key 1
> md5 cisco
> and R1 would be: area 1 virtual-link 192.168.2.2 message-digest-key 1
> md5 cisco
>
> This scenario works as well. So the confusion..........
>
>
> Ideas?????
>
>
> Thanks
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:59:07 GMT-3