From: Khalid Siddiq (khalid@xxxxxxxxxx)
Date: Thu Aug 01 2002 - 02:43:42 GMT-3
i am using ios c2500-jos56i-l.121-5.T9.bin and tunnel goes down when i remove t
he default and static to null route.
khalid
-----Original Message-----
From: Horszczaruk Krzysztof [mailto:Krzysztof.Horszczaruk@getronics.com]
Sent: Wednesday, July 31, 2002 7:19 PM
To: Volkov, Dmitry (Toronto - BCE); Khalid Siddiq; Carlos G Mendioroz
Cc: ccielab@groupstudy.com
Subject: RE: other way to monitor deleted route than dialer Watch
I tested it on 12.1(9). works fine as well (tunnel goes down)
regards - Krzysztof.
>>>-----Original Message-----
>>>From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
>>>Sent: Wednesday, July 31, 2002 4:10 PM
>>>To: 'Khalid Siddiq'; Horszczaruk Krzysztof; Carlos G Mendioroz
>>>Cc: ccielab@groupstudy.com
>>>Subject: RE: other way to monitor deleted route than dialer Watch
>>>
>>>
>>>
>>>
>>>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:48:13 GMT-3