Thanks ,I got it. Wow!The following summary is very classical. From Brian Dennis, There isn't support for "area" and "interface" authentication in OSPF. All OSPF authentication is done on a per segment basis. The RFC says that all routers on a "network" (i.e. segment/subnet) must have the same authentication type configured and not all routers within an "area". The confusion comes in the way Cisco has implemented the commands to set the authentication type. The "area authentication" and "area authentication message-digest" commands are just simple methods to set the authentication type for all interfaces within an area on router.The interface level commands (ip ospf authentication, ip ospf authentication message-digest, and ip ospf authentication null" are methods to enable authentication on a single interface and/or override the authentication type set under the routing process. If you have ten interfaces in area 0 and you want to perform authentication on all ten of them, it's easier to just enable authentication using the "area 0 authentication " command than it is to type the "ip ospf authentication " command under each of the ten interfaces. But if you have ten interfaces in area 0 and you want to authenticate just a single interface, it's easier to use the interface level command on the one interface than it is to use the routing process level command. If the routing process level command is used, you will need to override it on the other nine interfaces by setting them back to the default of null authentication by using the "ip ospf authentication null" command. Lastly the authentication type configured under the interface will always override the authentication type configured under the routing process. ---- Subject: RE: OSPF redistribute connected issue Dave, OSPF network types that use a DR (broadcast and non-broadcast) can neighbor with each other and function properly. Likewise OSPF network types that do not use a DR (point-to-point and point-to-multipoint) can neighbor with each other and function properly. But if you mix DR types with non-DR types they will not function properly as you have seen. You should see in the OSPF database "Adv Router is not-reachable" messages when you've mixed DR and non-DR types. ----- I guess the decision process for OSPF is as follows: (lets suppose that both prefixes are identical in terms of mask length) 1. Intra-area route 2. Inter-area route from backbone (which should be closer to the ABR originating the LSA) 3. Inter-area route from another area 4. External route In case of a tie, AD and metric enter into play ----- There are three ways to get the ip address of a loopback interface advertised as a /24 in the network. 1 - ip ospf network point-to-point 2 - area range - requires the loopback be on a different area 3 - redistribute connected ---- > I was thinking about all the ways that the lab could possibly ask for > authentication in OSPF, and a thought came to mind....what if, they ask to > perform area 0 authentication, and, you happen do have a virtual link. Would > you also put authentication on the virtual link, like you would on a tunnel > that is part of area 0. Technically, you could call the virtual link an > "extension of area 0". I was doing some work on this earlier today. Others have talked about having to authenticate the virtual links as well. What's also interesting is to look at how md5 is used. It's easy to think you've configured it but find you haven't, which I thought was quite interesting. Known to many I'm sure, but anyway - for the record: router ospf 1 area 0 authentication message-digest area 30 virtual-link 150.10.7.7 authentication message-digest area 30 virtual-link 150.10.7.7 message-digest-key 1 md5 cisco Without the second of these lines, a 'show ip ospf virtual-link' gives a null key although it's md5 authenticated. If you don't remember the message-digest in the first of the area30 lines, then you get plain authentication - and lose your points no doubt :-( ---- Subject: RE: filtering ospf routes possible? Which part? The distribute list can be done on any router since it only has a local effect. The area filter-list, you're correct, must be done on an ABR since it filters things going into or out of an area itself. HTH, Scott _____ From: Donny mateo Tandase [mailto:donnymateo@yahoo.com] Sent: Wednesday, November 23, 2005 10:52 AM To: Scott Morris; 'de Witt, Duane'; 'lim es'; ccielab@groupstudy.com Subject: RE: filtering ospf routes possible? Scott, just to clarify, this only applies to ABR I pressume... Scott Morris wrote: The rule (per spec) is that all OSPF devices within an area must have an identical database. The distribute-list command works fine, but it's only inbound. And actually it filters between the database and the routing table (see rule above). You can do an area filter-list if you want, that filters a route from entering (or leaving) an entire area. That's more specific than using a stub type area, but still doesn't violate the above rule. Cheers, Scott --- ---------- Forwarded message ---------- From: "Brian Dennis" To: "Le Anh Duong" , "Cisco certification" Date: Wed, 7 Dec 2005 13:52:16 -0500 Subject: RE: Admin Distance of External EIRGP route The distance command for EIGRP doesn't work when you try to specify a particular external route (distance but the command will let you set the administrative distance for all EIGRP external routes (distance eigrp ). As a side note you can set the administrative distance for a particular OSPF external route. Rack1R4#sho ip route os 155.1.0.0/24 is subnetted, 2 subnets O E2 155.1.1.0 [110/20] via 155.1.146.1, 00:00:01, Ethernet0/0 O E2 200.1.1.0/24 [110/20] via 155.1.146.1, 00:00:01, Ethernet0/0 150.1.0.0/24 is subnetted, 1 subnets O E2 150.1.1.0 [110/20] via 155.1.146.1, 00:00:01, Ethernet0/0 Rack1R4#conf t Enter configuration commands, one per line. End with CNTL/Z. Rack1R4(config)#access-list 5 permit 150.1.1.0 Rack1R4(config)#router ospf 1 Rack1R4(config-router)#distance 140 200.1.1.1 0.0.0.0 5 Rack1R4(config-router)#do clear ip rout * Rack1R4(config-router)#do sho ip rout os 155.1.0.0/24 is subnetted, 2 subnets O E2 155.1.1.0 [110/20] via 155.1.146.1, 00:00:05, Ethernet0/0 O E2 200.1.1.0/24 [110/20] via 155.1.146.1, 00:00:05, Ethernet0/0 150.1.0.0/24 is subnetted, 1 subnets O E2 150.1.1.0 [140/20] via 155.1.146.1, 00:00:05, Ethernet0/0 Rack1R4(config-router)# HTH, Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security) bdennis@internetworkexpert.com Internetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Direct: 775-745-6404 (Outside the US and Canada) ---- Hi, There is an important distinction that you need to be aware of: - when you configure a standard NSSA (without the no-summary), NO default routes are injected - when you configure a totally stubby NSSA (with the no-summary), a type-3 default is injected - when you configure a standard NSSA together with the default-information-originate keyword, a type-7 default is injected - when you configure both a totally stubby NSSA and the default-information-originate keyword, both type-3 and type-7 defaults are injected (see 'sh ip ospf database'). You only see the default resulting from the type-3 being installed since its an internal route compared to the external type-7 So there are differences between the two if you look deep enough... Paresh. --