From: Khalid Siddiq (khalid@xxxxxxxxxx)
Date: Wed Jul 31 2002 - 08:07:26 GMT-3
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
TERM-SER#
-----Original Message-----
From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
Sent: Wednesday, July 31, 2002 4:23 AM
To: 'Carlos G Mendioroz'
Cc: 'Horszczaruk Krzysztof'; ccielab@groupstudy.com
Subject: RE: other way to monitor deleted route than dialer Watch
Carlos,
Thanks a lot. I got it finally :)
Only one thing confuses me:
Why existence route via Null brings Tu down ?
I've tried to replace Null with Loopback but Tu keeps UP state when we have
deault-route.
Only Null brings it down.
route 192.168.1.0 255.255.255 null 0 200 - works fine
route 192.168.1.0 255.255.255 Loop 0 200 - doesn't work
Why ??
Dmitry
-----Original Message-----
From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
Sent: Tuesday, July 30, 2002 4:26 PM
To: Volkov, Dmitry (Toronto - BCE)
Cc: 'Horszczaruk Krzysztof'; ccielab@groupstudy.com
Subject: Re: other way to monitor deleted route than dialer Watch
Dmitry,
you don't need a far end tunnel interface. Just a local router tunnel
interface with tunnel destination in the "watched" network.
i.e.
interface tunnel 0
tunnel source eth 0/0
tunnel destination 192.168.1.1
backup interface bri 0/0
In this case, the tunnel will be up/up is 192.168.1.1 is in your
routing table, up/down if it is not.
"Volkov, Dmitry (Toronto - BCE)" wrote:
>
> Carlos,
>
> I just tested and found that local tunnel Interface state doesn't depend
on
>
> far end tunnel interface state.
>
> Local Tu will be Up/Up when far end Tu is Up/Down, so, it doesn't depend
on
> state of destination hence doesn't tied to destination reachability.
>
> I still don't understand where the default-route comes into play ?
>
> Dmitry
>
> -----Original Message-----
> From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
> Sent: Tuesday, July 30, 2002 1: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