From: Nick Tucker (kitt@vnet.net)
Date: Sun Jun 27 2004 - 09:44:00 GMT-3
Wanted to say things again for the isis help last week. I was another
victim of not knowing it didn't take care of connected routes by default.
This week, I'm at it again. As well as getting everything from the past
weeks running that had my stumped, I was messing around with the various
ways of doing atm, pppoa, etc and run into a setup in which I was having
the same problem as before with ISIS. My connected route (in my case
12.1.1.x/24) is not getting sent from r1 to the rest of the network.
The associated topology r2 <--> atm <--> r1 --<rest of network, topology
irrevelevent)
r3 directly on the other side of r1 does not see the atm interfaces in the
routing table. As before, r3, and any router further out in my topology
can ping r2 just fine. r2 cannot ping out anywhere except for r1. Here is
the associated configs
r1
-----
vc-class atm type1
encapsulation aal5snap
interface ATM1/0
no ip address
ip router isis ccie
class-int type1
no atm ilmi-keepalive
pvc 1/5
protocol ip 12.1.1.2 broadcast
protocol ppp Virtual-Template5
!
pvc 1/10
protocol clns 49.0002.0100.0100.2002.00 broadcast
protocol ppp Virtual-Template5
interface Virtual-Template5
ip address 12.1.1.1 255.255.255.0
ip router isis ccie
router isis ccie
net 49.0001.0100.0100.1001.00
redistribute ospf 1
is-type level-2-only
r2
------
vc-class atm type2
encapsulation aal5snap
interface ATM1/0
no ip address
ip router isis ccie
class-int type2
no atm ilmi-keepalive
pvc 1/5
protocol ip 12.1.1.1 broadcast
protocol ppp Virtual-Template5
!
pvc 1/10
protocol clns 49.0001.0100.0100.1001.00 broadcast
protocol ppp Virtual-Template5
!
no scrambling-payload
bridge-group 1
interface Virtual-Template5
ip address 12.1.1.2 255.255.255.0
ip router isis ccie
!
router isis ccie
net 49.0002.0100.0100.2002.00
is-type level-2-only
r2#sh ip route (snipped a lot of it out, had lots going on here, this just
to show I did have routes everywhere from r2)
Gateway of last resort is not set
16.0.0.0/24 is subnetted, 1 subnets
i L2 16.1.1.0 [115/10] via 12.1.1.1, Virtual-Access2
[115/10] via 12.1.1.1, Virtual-Access1
71.0.0.0/24 is subnetted, 23 subnets
i L2 71.1.6.0 [115/10] via 12.1.1.1, Virtual-Access2
[115/10] via 12.1.1.1, Virtual-Access1
i L2 71.1.7.0 [115/10] via 12.1.1.1, Virtual-Access2
[115/10] via 12.1.1.1, Virtual-Access1
11.0.0.0/24 is subnetted, 1 subnets
i L2 11.1.1.0 [115/10] via 12.1.1.1, Virtual-Access2
[115/10] via 12.1.1.1, Virtual-Access1
12.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 12.1.1.0/24 is directly connected, Virtual-Access1
is directly connected, Virtual-Access2
C 12.1.1.1/32 is directly connected, Virtual-Access1
is directly connected, Virtual-Access2
13.0.0.0/24 is subnetted, 1 subnets
i L2 13.1.1.0 [115/10] via 12.1.1.1, Virtual-Access2
[115/10] via 12.1.1.1, Virtual-Access1
14.0.0.0/24 is subnetted, 1 subnets
i L2 14.1.1.0 [115/10] via 12.1.1.1, Virtual-Access2
[115/10] via 12.1.1.1, Virtual-Access1
15.0.0.0/24 is subnetted, 1 subnets
i L2 15.1.1.0 [115/10] via 12.1.1.1, Virtual-Access2
[115/10] via 12.1.1.1, Virtual-Access1
r2#sh ip int brie
Virtual-Access1 12.1.1.2 YES manual up up
Virtual-Access2 12.1.1.2 YES TFTP up up
Virtual-Template5 12.1.1.2 YES manual
down down
Loopback0 10.1.2.2 YES manual up up
My questions.
1) On R1 is there something else I should be trying to match to make sure
my atm interface gets put into ospf? I DID specify match interface
virtual-template5 in my redistribute connect into the ospf process in
r1. There is no option to match virtual-access1 or 2.
2) Why in the show ip int brief above is the virutal access-2 a type 'TFTP'
instead of manual? Just because its clns ?
now, unrelated
3) Is there any signifigance to using dynamic when setting up dlsw peers
that would use an isdn circuit that has ONLY dialer watch-group defined (or
for that matter, backup interface as well)? I modeled this last nite
without using dynamic and my peers stayed up even thru the transition from
frame to isdn. My reasoning is dialer-watch only cares about the watched
route, it doesn't care that dlsw has traffic to send, and thus there is no
worry of sna or netbios or whatever keeping my line up indefinitly or
causing it to bounce. I can see the potential problem if you also keep a
group on the interface that just denys ospf and permits everything else.
4) This is just a general question about tunnels. I dont know why, but
I'm still not really that comfortable with them. I've been able to do cool
things like recursive routing loops and such with it. In a lot of examples
I see most of the time the ip address of the tunnel is unnumbered and
pointing to another interface. Is there a good rule of thumb of when you
would actually want to put addresses on tunnels and advertise them, vs just
using another interfaces address? For some reason I'm not thinking out of
the box here, but in just about every instance I've worked with them, I
never used them with their own addresses.
My apologies if any of this had been discussed before but I did some more
searching on isis and atm and wasnt able to turn up anything conclusive.
As always thanks for any comments. My day is rapidly approaching. :o
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:51 GMT-3