----- Original Message ----- From: "Vicuna, Mark" To: "The Long and Winding Road" ;
Sent: Thursday, 13 February, 2003 1:13 AM Subject: RE: Tonight's Homily - OSPF authenitcation - I didn't know [7:60282] Hi Chuck, Just curious to know what ios release you were using with this? I could not replicate the same results. CL: all the routers in question have 12.1.5T10 cheers, Mark. -----Original Message----- From: The Long and Winding Road [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 9:52 PM To: [EMAIL PROTECTED] Subject: Re: Tonight's Homily - OSPF authenitcation - I didn't know [7:60282] ""Eric Rogers"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > For those who don't have the book in question - > > Pg 17 of the Parkhurst OSPF book: > > "...In Cisco IOS Software Release 12.X, the authentication used on an > interface can be different from the authentication enabled for an area. When > using Cisco IOS Software release 12.X, the authentication method used on > different interfaces in the same area does not need to be the same. > Authentication can be turned off on selected interfaces using the command ip > ospf authentication null (see section 19-1). The key and password do not > need to be the same on every interface, but both ends of a common link need > to use the same key and password. Authentication is enabled by area (Cisco > IOS Software Release 11.X and earlier) so it is possible to employ > authentication in other areas..." Eric, I've been re-reading this passage, and thinking about it, and I am not so sure that the intent was to completely divorce area authentication ( under the ospf process ) from interface authentication. Consider that you can configure area authentication ( under the ospf process ) on one side, along with the approrpiate interface configuration, and all that the other side needs is interface configuration. And it works! Somehow that does not seem like an intended consequence. Is that your understanding of the intent? The passage quoted above "appears" to me to be saying that the intent is to allow the interface specific configuration to be different than the general area configuration. Maybe a concession to mixed vendor environments? I just found it fascinating that one now has a number of options, and that one can now introduce authentication without necessarily enforcing it on all interfaces. Anyone know any of the IOS progammer managers? I'm really curious about the thought behind this. > > CL - Thanks for the heads up the other day about the OSPF Parkhurst > book...Pulled it from my bookshelf and wiped off the dust just yesterday and > I'm currently on page105 going through it with my highlighter. I like the > way he's formatted it by pounding on the same example building on the > commands as he goes. After the third or forth example it all just all clicks > together with the little nuances he's placed in there. When I first got this > book I just thought of it as a command reference nothing more but it's > really a good book that I would have never delved into without your comment > the other day. I'll be finishing OSPF this weekend and moving into my other > currently unread Parkhurst book BGP. > > Eric R > > ----- Original Message ----- > From: "The Long and Winding Road" > To: > Sent: Friday, January 03, 2003 7:46 PM > Subject: Tonight's Homily - OSPF authenitcation - I didn't know that! > [7:60275] > > > > 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=62961&t=62961 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
