Re: Static routes with tracking

From: Mathew (mathewfer@gmail.com)
Date: Thu Jan 25 2007 - 10:30:05 ART

Hi Brian,

Thank you for the reply.

As I do not have the GRE on the otherside, I know I have to disable
the keepalive. In the IOS ver I tested, keepalive was not there. Also
I had to replace the default with the below to cover most of the
supernets except the very first few supernets including 1.0.0.0/8,
otherwise, I noticed the tunnel start flapping when 1.1.1.1/32 is NOT
in the routing table but trying to reach with the default with dialer
1 - result is UP/DOWN toggling.

Do you think the above config with the below static will be a stable
alternative to replace the newer IOS's way of doing it (I mean with
newer TRACK options)?

!
ip route 4.0.0.0 252.0.0.0 Tunnel1
ip route 8.0.0.0 248.0.0.0 Tunnel1
ip route 16.0.0.0 240.0.0.0 Tunnel1
ip route 32.0.0.0 224.0.0.0 Tunnel1
ip route 64.0.0.0 192.0.0.0 Tunnel1
ip route 128.0.0.0 128.0.0.0 Tunnel1
!
ip route 4.0.0.0 252.0.0.0 Dialer1 250
ip route 8.0.0.0 248.0.0.0 Dialer1 250
ip route 16.0.0.0 240.0.0.0 Dialer1 250
ip route 32.0.0.0 224.0.0.0 Dialer1 250
ip route 64.0.0.0 192.0.0.0 Dialer1 250
ip route 128.0.0.0 128.0.0.0 Dialer1 250
!

Thanks for your reply.

mathew

On 1/23/07, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
> Policy routing applied to an interface is for inbound traffic.
> AFAIK GRE tunnels are not an exception to this. Are you sure keepalives
> are on the tunnel though? If the other side isn't running GRE the
> tunnel shouldn't be up/up.
>
>
> 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: Mathew [mailto:mathewfer@gmail.com]
> Sent: Sunday, January 21, 2007 2:04 PM
> To: Brian McGahan
> Cc: ccielab@groupstudy.com
> Subject: Re: Static routes with tracking
>
> 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
> 

-- 
Thanks

Mathew

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