From: Stefan L. Dozier (doziersl@yahoo.com)
Date: Fri Dec 27 2002 - 09:39:04 GMT-3
Thanks Justin
And you know that actually makes sense, now that I've gotten some
much needed rest!
Happy Holidays
Stefan
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Justin Menga
Sent: Friday, December 27, 2002 4:25 AM
To: Stefan L. Dozier; Groupstudy CCIELab List
Subject: RE: Adjusting Admin Distance to Influence Route Selection
Hi
As a general rule, when you reference an access-list that doesn't exist on
IOS, all traffic will be matched.
For example, if you apply an access list inbound on an interface and the
access list doesn't exist, all traffic inbound is permitted, not dropped as
you might expect. The same logic applies for your configs below...
Regards,
Justin #6640 (R&S, Security)
-----Original Message-----
From: Stefan L. Dozier [mailto:doziersl@yahoo.com]
Sent: Friday, December 27, 2002 5:13 PM
To: Groupstudy CCIELab List
Subject: Adjusting Admin Distance to Influence Route Selection
Reference: Parkhurst's OSPF Command and Configuration Handbook
I need to bounce this off the list just to help clear up
some confusion on my part:
Basic 3 router network, Routers A, B, and C
Configuration posted on the end of the message!
The gist of the scenario demonstrates how adjusting (lowering) the admin
distance of OSPF allows the 3.3.3.0/24 advertised from RouterA to be placed
in the routing table of RouterB vice the eigrp derived 3.3.3.0/24 network
from RouterC.
Entering "distance 80" under the OSPF process on RouterB causes an instant
spf recalc and the 3.3.3.0/24 from RouterA is placed in RouterB's routing
table. *No issues here*
Cleaning up the scenario to default, and entering
"distance 80 1.1.1.1 0.0.0.0" under the OSPF process on RouterB
does not cause an instant spf recalc and requires a
"clear ip ospf 1 process" command to get the 3.3.3.0/24 network from RouterA
into RouterB's routing table! *OK, strange, but I've move on for now!
Cleaning up the scenario to default, and entering
"distance 80 1.1.1.1 0.0.0.0 1" under the OSPF process on RouterB but before
I actually defined "access-list 1" requires a "clear ip ospf 1 process"
command [*not surprised] and actually sets the admin distance of 3.3.3.0/24
to 80 which allows the 3.3.3.0/24 network into RouterB's routing table via
ospf from RouterA.
*Now I'm confused*
I'm thinking, since I instructed the distance command to use access-list 1
but didn't actually define access-list 1, and with access-lists default to
implicitly deny all, that no routes from RouterA would make it into
RouterB's routing
table, and the opposite happened. It set the admin distance
on all ospf routes from RouterA to 80 and placed them in the routing table.
RouterA
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 3.3.3.3 255.255.255.0
ip ospf network point-to-point
!
interface TokenRing0/0
ip address 172.16.1.1 255.255.255.0
ip mtu 4464
ring-speed 16
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 3.3.3.0 0.0.0.255 area 0
network 172.16.1.0 0.0.0.255 area 0
RouterB
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Serial1
bandwidth 64
ip address 10.1.1.5 255.255.255.252
clockrate 64000
!
interface TokenRing0
ip address 172.16.1.2 255.255.255.0
ring-speed 16
!
router eigrp 1
network 10.0.0.0
no auto-summary
eigrp log-neighbor-changes
!
router ospf 1
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 0
network 172.16.1.0 0.0.0.255 area 0
RouterC
interface Loopback0
ip address 3.3.3.3 255.255.255.0
!
interface Serial0
bandwidth 64
ip address 10.1.1.6 255.255.255.252
no fair-queue
!
router eigrp 1
network 3.0.0.0
network 10.0.0.0
no auto-summary
eigrp log-neighbor-changes
.
.
This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:53 GMT-3