Re: Static routes with tracking

From: Mathew (mathewfer@gmail.com)
Date: Sun Jan 21 2007 - 17:04:10 ART

Hi Brian,

First, thanks for your reply.

I am trying to achieve an alternative to what you described with 2
dialer interfaces & backup command. That also worked for me.

I am just trying to do the same without the 2nd dialer & backup command.
For me it worked but I am just asking your opinion on a configuration like this.

I was trying to tell that before GRE encapsulation, policy routing
takes place as expected & traffic is sent to null 0 - local black hole
- similar to my original configuration with tracking.

I just want your comment with this alternative configuration. I am
thinking whether we have any issues with this GRE as it is configured
only at this local router (kind of a self-tunnel) and it is only used
to change it status UP or DOWN depending on the reachability of
1.1.1.1.

Thanks your comments.

mathew

On 1/22/07, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
> What are you trying to accomplish with this?
>
>
> Brian McGahan, CCIE #8593 (R&S/SP)
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
> -----Original Message-----
> From: Mathew [mailto:mathewfer@gmail.com]
> Sent: Saturday, January 20, 2007 7:27 AM
> To: Brian McGahan
> Cc: ccielab@groupstudy.com
> Subject: Re: Static routes with tracking
>
> Hi Brian/GS,
>
> Thank you for your excellent reply.
>
> After I post it, I too came up with the below & that does not use 2
> dialer interfaces & backup command. Also it worked with only the
> tunnel config only on the local router. I mean there is no
> remote/other end of the GRE config.
>
> Do you see any issues or inconsistencies etc with this config?
>
> With this, there is no output for "debug tunnel" which shows GRE
> encapsulation does not take place. It gives the below for "debug ip
> policy".
>
> 000466: *Mar 1 18:18:25 S11: IP: s=7.3.3.3 (Tunnel1), d=1.1.1.1, len
> 1224, policy match
> 000467: *Mar 1 18:18:25 S11: IP: route map DROP, item 1, permit
> 000468: *Mar 1 18:18:25 S11: IP: s=7.3.3.3 (Tunnel1), d=1.1.1.1
> (Null0), len 1224, policy routed
> 000469: *Mar 1 18:18:25 SYD: IP: Tunnel1 to Null0 1.1.1.1
>
> !
> interface Loopback1111
> ip address 7.3.3.3 255.255.255.255
> !
> interface Tunnel1
> Description -- Fake tunnel UP/UP when 1.1.1.1 is reachable
> ip address 2.2.2.1 255.255.255.252 <-------- I had to configuire this
> IP address.
> ip policy route-map DROP
> tunnel source Loopback1111
> tunnel destination 1.1.1.1
> !
> interface Dialer1
> .
> !
> route-map DROP permit 1
> set interface Null0
> !
> ip route 0.0.0.0 0.0.0.0 Tunnel1
> ip route 0.0.0.0 0.0.0.0 Dialer1 250
> !
>
> Thank you for your reply.
>
> mathew
>
> On 1/20/07, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
> > You could create multiple dialer interfaces, one that is for
> > backup and one that is just for testing the circuit. For older IOSes
> > you can get an IP SLA like tracking of the end to end circuit status
> by
> > using a GRE tunnel. Configure a tunnel between two endpoints and add
> > the "keepalive" command on it. Put the "backup interface dialer2"
> > command on the tunnel, or whatever interface you want to use as
> backup,
> > then if there is not end-to-end IP transit in the tunnel path it will
> > trigger the backup link once the tunnel keepalive expires. This is
> > useful for situations like DSL where your local link to the DSL modem
> or
> > DSLAM does not indicate the end-to-end circuit status, where an
> > end-to-end GRE tunnel would.
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593 (R&S/SP)
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > mathew Fer
> > Sent: Friday, January 19, 2007 12:13 AM
> > To: ccielab@groupstudy.com
> > Subject: Static routes with tracking
> >
> > Hi GS / Brians,
> >
> > I have tested the below configuration successfully with IOS ver 12.4.
> > The default static route to null 0 is active when IP 1.1.1.1 is
> > reachable
> > via BGP so that any routes that are not matched in BGP routes
> (specific
> > routes) are dropped with null 0, without sending the traffic to WAN.
> >
> > When the WAN is down, 1.1.1.1 is not learned by BGP so the default
> route
> > to
> > Null 0 is removed from the routing table & install the default to
> dialer
> > 1
> > which kick in the ISDN dial out with Dialer configuration (with
> > intresting
> > traffic defined in the configuration) to other end router.
> >
> > My question is that what are other possible ways to do the same with
> an
> > IOS
> > ver 12.1 which does not have the support of Enhanced Tracking.
> >
> > One of the requirement here is to keep the dialer to use for testing
> > (with a
> > ping to 192.168.1.1) under normal condition (WAN UP). This prevent us
> > using
> > the command "backup interface dialer 1" in the configurations.
> >
> > !
> > interface FastEthernet0/0
> > .
> > !
> > interface Serial0/0
> > no ip address
> > encapsulation frame-relay
> > !
> > interface Serial0/0.1 point-to-point
> > ip address 6.1.1.2 255.255.255.252
> > no cdp enable
> > frame-relay interface-dlci 100
> > !
> > interface BRI0/0
> > .
> > dialer pool-member 1
> > !
> > interface Dialer1
> > ip address 192.168.1.2 255.255.255.0
> > dialer pool 1
> > dialer string 4444
> > dialer-group 1
> > .
> > !
> > track 2 ip route 1.1.1.1 255.255.255.255 reachability
> > !
> > ip route 0.0.0.0 0.0.0.0 null 0 track 2
> > ip route 0.0.0.0 0.0.0.0 Dialer 1 220
> > !
> > ip route 192.168.1.1 255.255.255.255 Dialer 1 <---- Dial out for
> testing
> > !
> > router bgp 1
> > .
> > .
> > !
> > access-list 105 permit ip 10.2.1.0 0.0.0.255 any
> > access-list 105 permit ip any host 192.168.1.1
> > !
> > dialer-list 1 protocol ip list 105
> > !
> >
> > Thank you for the reply.
> >
> > mathew
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
>
>
> --
> Thanks
>
> Mathew
> 

-- 
Thanks

Mathew

This archive was generated by hypermail 2.1.4 : Thu Feb 08 2007 - 23:46:57 ART