From: Volkov, Dmitry (Toronto - BCE) (dmitry_volkov@xxxxxxxxx)
Date: Wed Jul 31 2002 - 11:10:09 GMT-3
Well, maybe as Carlos mentioned, it was IOS related...
Can somebody explain this phenomenon ???
What IOS do You have ? I used 12.1(15)
Does Tunnel go down when You remove static to null and default ?
Dmitry
-----Original Message-----
From: Khalid Siddiq [mailto:khalid@sys.net.pk]
Sent: Wednesday, July 31, 2002 7:47 AM
To: Horszczaruk Krzysztof; Carlos G Mendioroz; Volkov, Dmitry (Toronto -
BCE)
Cc: ccielab@groupstudy.com; Tom Larus
Subject: RE: other way to monitor deleted route than dialer Watch
-My tunnel interface is not down even i specify the destiantion route to
nullo 0
Please clarify what i am missing,
configguration is,
inter tunnel 0
tunnel source 10.1.0.2
tunnel destination 192.168.1.1
ip route 0.0.0.0 0.0.0.0 10.1.0.1
ip route 192.168.1.0 255.255.255.0 null 0 200
TERM-SER#sh int tu 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set, keepalive set (10 sec)
Tunnel source 10.1.0.2, destination 192.168.1.1
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
TERM-SER# sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default
U - per-user static route, o - ODR
Gateway of last resort is 10.1.0.1 to network 0.0.0.0
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback1
172.17.0.0/24 is subnetted, 4 subnets
I 172.17.17.0 [100/10004001] via 172.17.3.1, 00:00:29, Serial0
I 172.17.1.0 [100/10476] via 172.17.3.1, 00:00:29, Serial0
C 172.17.3.0 is directly connected, Serial0
I 172.17.2.0 [100/8576] via 172.17.3.1, 00:00:29, Serial0
R 172.16.0.0/16 [120/2] via 172.17.3.1, 00:00:24, Serial0
R 172.21.0.0/16 [120/2] via 172.17.3.1, 00:00:24, Serial0
R 172.20.0.0/16 [120/2] via 172.17.3.1, 00:00:24, Serial0
10.0.0.0/16 is subnetted, 1 subnets
C 10.1.0.0 is directly connected, Ethernet0
S 192.168.1.0/24 is directly connected, Null0
S* 0.0.0.0/0 [1/0] via 10.1.0.1
From: Horszczaruk Krzysztof [mailto:Krzysztof.Horszczaruk@getronics.com]
Sent: Wednesday, July 31, 2002 12:24 PM
To: Carlos G Mendioroz; Volkov, Dmitry (Toronto - BCE)
Cc: ccielab@groupstudy.com; Tom Larus
Subject: RE: other way to monitor deleted route than dialer Watch
Dmitry,
I think Carlos has explained everything, so just for summarization:
when there is default-route, the tunnel will always stay up, regardles of
presence of particular route to destination.
But even this was solved by Carlos with floating static route to tunnel
destination pointing to null 0.
when the router find, that tunnel destination is reachable through its local
null 0 - it puts tunnel down.
Carlos,
you are a real Wizard ;-)
greetings ...
>>>-----Original Message-----
>>>From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
>>>Sent: Tuesday, July 30, 2002 7:20 PM
>>>To: Volkov, Dmitry (Toronto - BCE)
>>>Cc: Horszczaruk Krzysztof; ccielab@groupstudy.com; Tom Larus
>>>Subject: Re: other way to monitor deleted route than dialer Watch
>>>
>>>
>>>Krzysztof is right, this will not work if you have default route,
>>>but even that could be solved, if we could relax a bit lab
>>>game rules.
>>>The dependency comes from the fact that the tunnel protocol state
>>>(up/down) is tied to destination reachability (i.e. is the
>>>destination
>>>address in the route table ?)
>>>The way to solve it is to put a floating static for the "watched"
>>>network
>>>pointing to null 0.
>>>
>>>The method does (appart from the said inconvinience) track the
>>>availability
>>>of the destination, not the state of any interface, so it
>>>does work in
>>>your
>>>proposed scenario...
>>>
>>>
>>>"Volkov, Dmitry (Toronto - BCE)" wrote:
>>>>
>>>> Krzysztof ,
>>>>
>>>> Sorry, I didn't understand, what are the dependencies on
>>>default-route ?
>>>>
>>>> Let say we have the following
>>>>
>>>> R3(e0)---------(e0)R1 ---isdn----R2(s0)----(s0)R3
>>>>
>>>> In case of link R2-----R3 goes down and network between R2
>>>& R3 flushes from
>>>> routing table,
>>>> I want to bring up isdn between R1 & R2. No Dialer Watch
>>>or static routes
>>>> are allowed.
>>>>
>>>> As far as I understand method proposed by Carlos:
>>>> to put tunnel between R1 and R3 (terminate on S0) and make
>>>isdn int on R1 as
>>>> backup for tunnel
>>>> If s0 goes down, tunnel goes down and R1 will dial R2. Am I right ?
>>>>
>>>> What is special about default-route here ?
>>>>
>>>> Unfortunately this scenario will not work in case of
>>>multipoint Frame link
>>>> between R1 & R2, as it monitors only interface status
>>>> and doesn't monitor of existence of route to network
>>>between R2 & R3.
>>>>
>>>> Thanks,
>>>>
>>>> Dmitry
>>>>
>>>> -----Original Message-----
>>>> From: Horszczaruk Krzysztof
>>>[mailto:Krzysztof.Horszczaruk@getronics.com]
>>>> Sent: Tuesday, July 30, 2002 11:24 AM
>>>> To: Carlos G Mendioroz; Volkov, Dmitry (Toronto - BCE)
>>>> Cc: ccielab@groupstudy.com
>>>> Subject: RE: other way to monitor deleted route than dialer Watch
>>>>
>>>> many magic things can be made with tunnel ...
>>>>
>>>> this one (invented by Carlos) would work provided there is
>>>no default-route.
>>>> am i right ?
>>>> (in case of default-route the fake tunnel will stay permanently up)
>>>>
>>>> krzysztof horszczaruk
>>>>
>>>> >>>-----Original Message-----
>>>> >>>From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
>>>> >>>Sent: Tuesday, July 30, 2002 4:51 PM
>>>> >>>To: Volkov, Dmitry (Toronto - BCE)
>>>> >>>Cc: 'ccielab@groupstudy.com'
>>>> >>>Subject: Re: other way to monitor deleted route than
>>>dialer Watch
>>>> >>>
>>>> >>>
>>>> >>>Yes,
>>>> >>>you can combine a fake tunnel endpoint and backup to achieve the
>>>> >>>same functionality. A tunnel goes down when there's no route to
>>>> >>>the other side. Backup on it will keep down an ISDN down for
>>>> >>>as long as the remote is reachable. Add some interesting traffic
>>>> >>>to the mix to get a homebrew dialer watch recipe! :-)
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>"Volkov, Dmitry (Toronto - BCE)" wrote:
>>>> >>>>
>>>> >>>> Hello group,
>>>> >>>>
>>>> >>>> Does anybody know the way (other than Dialer Watch) to
>>>> >>>monitor the existence
>>>> >>>> of a specified route
>>>> >>>> and if that route is not present, to initate dialing of
>>>> >>>the backup link ???
>>>> >>>>
>>>> >>>> Is it possible to monitor deleted (not connected) route to
>>>> >>>make ISDN dial
>>>> >>>> using something else than Dialer Watch ?
>>>> >>>>
>>>> >>>> Let say I want do make call to provide backup when some
>>>> >>>link (not connected)
>>>> >>>> goes down.
>>>> >>>>
>>>> >>>> Thanks,
>>>> >>>>
>>>> >>>> Dmitry
>>>> >>>>
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:50 GMT-3