I got to thinking about this a little bit further. Warning - what follows is more metaphysical, and less technical. I believe it does adequately explain the thought process that resulted in the original homily.
It comes down to Augustinian and anti-Augustinian thought. According to Augustine of Hippo, evil is not a thing in an of itself. Evil is merely the absence of good. Same as darkness is merely the absence of light. This good and evil, day and night, are not opposites. I suppose one might then argue that a vacuum is merely the absence of air. In this Augustinian viewpoint, when no area authentication is configured then what you have is nothing. Which leaves the mystery of interface authentication and it's purpose. However, if one takes an anti-Augustinian view, which it appears that the Cisco developers did, then when you read the documentation that states that the default area authentication is null, one must then agree that null authentication is a thing in and of itself. If no area authentication is configured, then in reality null authentication is configured. The area does indeed have authentication configured. The interface authentication, then, is doing what the docs say - overriding the area configuration with a specific authentication that applied to the interface only. The proof of this is that when specific area authentication is configured, one can override it with the interface configuration of null, which is a kind of authentication. It is fair to say that now there are three kinds of OSPF authentication. clear text, md5, and null. One of those types MUST be configured under the ospf process. The default is null ( not "none" ) One of those types must be configured on each ospf interface. the default is null except when an area authentication is configured under the ospf process ( had to include this one or else the flow of logic fails ) The happy accident that results from this is that area authentication need not be configured on routers on both sides of the link. Only on one side. Well, maybe not really an accident. After all, the other side ospf process has the default authentication set to null. The interface authentication overrides for just that interface. This explains the result I documented below. So how'd I do, Howard? :-> footnote: I realize that in terms of router code, there is probably a register with certain bit positions indicating authentication in place. for example: 0000 = area authentication = null, interface authentication = null 0001 = area authentication = null, interface authentication = clear text 0010 = area authentication = null, interface authentication = md5 0011 = area authentication = clear text, interface authentication = null 0100 = area authentication = clear text, interface configuration = clear text 0101 = area authentication = clear text, interface authentication = md5 0110 = area authentication = md5, interface authentication = null 0111 = area authentication = md5, interface authentication = clear text 1000 = area authentication = md5, interface authentication = md5 1011 = area authentication required but interface not configured 1111 = area authentication = null, interface authentication configuration not required ( the absence of good ) these would be pointers to the appropriate subroutine process for handling OSPF packets received or sent on an interface. sorry for the boring lecture. Chuck -- TANSTAAFL "there ain't no such thing as a free lunch" ""The Long and Winding Road"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > As many of you know, I've been reading Parkhurst's OSPF book for a number of > reasons. So I'm fooling around in the chapter on interface commands, when > something hits me over the head. > > authentication can be done on an interface by interface basis! > > one of those things that I just never noticed before. Maybe because all the > practice labs always instruct you to use area authentication. Maybe cause > I'm just a Homer Simpson kind of guy. > > So check this out. Topology will look strange, because I'm doing this over a > vlan tunnel. > > router-------------vlan tunnel-------------router > > each router has 4 subinterfaces, making four point-to-point links > > FrameSwitch#o nei > > Neighbor ID Pri State Dead Time Address Interface > 222.222.222.14 1 FULL/DR 00:00:33 122.1.4.1 > Ethernet0/1.4 > 222.222.222.14 1 FULL/DR 00:00:36 122.1.3.1 > Ethernet0/1.3 > 222.222.222.14 1 FULL/DR 00:00:36 122.1.2.1 > Ethernet0/1.2 > 222.222.222.14 1 FULL/DR 00:00:33 122.1.1.1 > Ethernet0/1.1 > FrameSwitch# > > FrameSwitch#ir os > O 197.32.44.0/24 [110/11] via 122.1.4.1, 00:01:21, Ethernet0/1.4 > [110/11] via 122.1.1.1, 00:01:21, Ethernet0/1.1 > [110/11] via 122.1.2.1, 00:01:21, Ethernet0/1.2 > [110/11] via 122.1.3.1, 00:01:21, Ethernet0/1.3 > O 195.100.3.0/24 [110/11] via 122.1.4.1, 00:01:21, Ethernet0/1.4 > [110/11] via 122.1.1.1, 00:01:21, Ethernet0/1.1 > [110/11] via 122.1.2.1, 00:01:21, Ethernet0/1.2 > [110/11] via 122.1.3.1, 00:01:21, Ethernet0/1.3 > FrameSwitch# > > So let's play! > > interface Ethernet0/1.1 > encapsulation dot1Q 121 > ip address 122.1.1.2 255.255.255.0 > ! > interface Ethernet0/1.2 > encapsulation dot1Q 122 > ip address 122.1.2.2 255.255.255.0 > ip ospf authentication > ip ospf authentication-key sycon > ! > interface Ethernet0/1.3 > encapsulation dot1Q 123 > ip address 122.1.3.2 255.255.255.0 > ip ospf authentication message-digest > ip ospf authentication-key cisco > ! > interface Ethernet0/1.4 > encapsulation dot1Q 124 > ip address 122.1.4.2 255.255.255.0 > ! > > Ethernet0/1.3 is up, line protocol is up > Internet Address 122.1.3.2/24, Area 1 > Process ID 1, Router ID 222.222.222.11, Network Type BROADCAST, Cost: 10 > Message digest authentication enabled > No key configured, using default key id 0 > > Ethernet0/1.2 is up, line protocol is up > Internet Address 122.1.2.2/24, Area 1 > Process ID 1, Router ID 222.222.222.11, Network Type BROADCAST, Cost: 10 > Simple password authentication enabled > > FrameSwitch#o nei > > Neighbor ID Pri State Dead Time Address Interface > 222.222.222.14 1 FULL/DR 00:00:33 122.1.4.1 > Ethernet0/1.4 > 222.222.222.14 1 FULL/DR 00:00:37 122.1.3.1 > Ethernet0/1.3 > 222.222.222.14 1 FULL/DR 00:00:37 122.1.2.1 > Ethernet0/1.2 > 222.222.222.14 1 FULL/DR 00:00:33 122.1.1.1 > Ethernet0/1.1 > FrameSwitch# > > FrameSwitch#ir os > O 197.32.44.0/24 [110/11] via 122.1.4.1, 00:03:18, Ethernet0/1.4 > [110/11] via 122.1.1.1, 00:03:18, Ethernet0/1.1 > [110/11] via 122.1.2.1, 00:03:18, Ethernet0/1.2 > [110/11] via 122.1.3.1, 00:03:18, Ethernet0/1.3 > O 195.100.3.0/24 [110/11] via 122.1.4.1, 00:03:18, Ethernet0/1.4 > [110/11] via 122.1.1.1, 00:03:18, Ethernet0/1.1 > [110/11] via 122.1.2.1, 00:03:18, Ethernet0/1.2 > [110/11] via 122.1.3.1, 00:03:18, Ethernet0/1.3 > FrameSwitch# > > during the entirety, the following is the ospf configuration: > > router ospf 1 > log-adjacency-changes > network 100.36.0.0 0.0.255.255 area 1 > network 122.1.0.0 0.0.255.255 area 1 > ! > > next, lets use area authentication > > router ospf 1 > log-adjacency-changes > area 1 authentication > network 100.36.0.0 0.0.255.255 area 1 > network 122.1.0.0 0.0.255.255 area 1 > ! > > FrameSwitch#o nei > > Neighbor ID Pri State Dead Time Address Interface > 222.222.222.14 1 FULL/DR 00:00:33 122.1.3.1 > Ethernet0/1.3 > 222.222.222.14 1 FULL/DR 00:00:33 122.1.2.1 > Ethernet0/1.2 > FrameSwitch# > > note that the only two interfaces that are up are the two with > authentication configured. note also that it appears not to matter if the > authentication is plain text or md5. > > Also, I should note that the other side does not have area authentication > enabled > > router ospf 1 > log-adjacency-changes > network 122.1.0.0 0.0.255.255 area 1 > network 195.100.3.0 0.0.0.255 area 1 > network 197.32.44.0 0.0.0.255 area 1 > ! > > tells me that as far as either router is concerned, so long as the ospf > packets have authentication fields filled, nothing else matters. pretty > neat! of course there is a down side, but for purposes of illustration, this > is wonderful! > > as long as I am on the topic, here's another knob: > > interface Ethernet0/1.1 > encapsulation dot1Q 121 > ip address 122.1.1.2 255.255.255.0 > ip ospf authentication null >>>>>>>>> THIS ONE! > end > > And the neighbor comes up on that subinterface: > > Neighbor ID Pri State Dead Time Address Interface > 222.222.222.14 1 FULL/DR 00:00:38 122.1.3.1 > Ethernet0/1.3 > 222.222.222.14 1 FULL/DR 00:00:38 122.1.2.1 > Ethernet0/1.2 > 222.222.222.14 1 FULL/DR 00:00:35 122.1.1.1 > Ethernet0/1.1 > FrameSwitch# > > ip ospf authentication null can be used to "excuse" one or more interfaces > from the authentication requirement. > > Pretty neat stuff! I'm not sure why it never occurred to me that you can > have interface authentication, and you can have area authentication on top > of that. Now that I've re-read the CCO docs under the influence of this > enlightenment, some things are clearer. For example, the docs suggest > beginning with interface authentication configuration, then adding the area > authentication under the routing process. I checked earlier notes on the > topic, and can find only the checklist points of doing it the other way > around. now I understand why the docs say what they do. > > Well, the third dimension gets built out just a little bit deeper. > > Still Waters. Green hillsides. An hour or two TV break - this much work > deserves a reward! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60314&t=60314 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
