From: Joe Smith (j333smith@hotmail.com)
Date: Tue Jan 18 2005 - 16:27:10 GMT-3
Couldn't you just set your next hop addresses as X.X.X.X and Y.Y.Y.Y,
instead of A.A.A.A and B.B.B.B? Make your track IPs the next hop addresses;
they are already defined by static routes through each of the dialer
interfaces.
J3
>From: "Geert Nijs" <geert.nijs@simac.be>
>Reply-To: "Geert Nijs" <geert.nijs@simac.be>
>To: <fferrer10@vodafone.es>, <ccielab@groupstudy.com>
>Subject: RE: RE: conditional NAT
>Date: Fri, 14 Jan 2005 12:32:16 +0100
>
>Ok. You are right. You will need the special NAT configuration. But i think
>your NAT config is correct.
>You match the same group (access group 100, which is your internal LAN
>subnet, i presume) and translate to dialer2 if it leaves dialer2
>and to dialer1 if it leaves dialer1.
>
>This is all perfect. Basically, your problem is routing. NAT does not care
>about routing. it just sees a packet leaving an outside interface and
>translates
>according to the rules. HOW that packet arrived at THAT outside interface
>is really routing, not NAT.
>
>So you should 'force' 'some' traffic to dialer1 and some traffic to
>dialer2.
>
>The problem is, you cant see when adsl is down, because your dialer stays
>up. Default routes won't switch.
>
>So if we would define defaults like:
>
>ip route 0.0.0.0 0.0.0.0 Dialer1 10
>ip route 0.0.0.0 0.0.0.0 Dialer2 20
>
>This would not work, since dialer1 would always remain up, even if your
>adsl is down.
>So we must track something else, like an ip address.
>
>An extra problem is that your dialer interfaces are /32 'hosts', basically,
>you don't know the ip address of the other side. This makes it hard to test
>the line ip addresses with a ping to the other side. We need something
>else.
>I suggest that you ALWAYS FORCE some traffic to a certain ip adres to
>dialer1 and always force traffic to a different ip adres to dialer2, like:
>
>ip route x.x.x.x 255.255.255.255 Dialer1
>ip route y.y.y.y 255.255.255.255 Dialer2
>
>The purpose is that when dialer1 fails, connectivity to x.x.x.x is lost and
>vice versa. So make sure there is no default route (!!) and that you can
>miss x.x.x.x
>and y.y.y.y is case of a failure.
>
>You then use tracking objects to track the ICMP reachability like:
>
> >rtr 1
> > type echo protocol ipIcmpEcho Y.Y.Y.Y
> > rtr schedule 1 start-time now life forever
> >
> > track 123 rtr 1 reachability
> >
> > rtr 2
> > type echo protocol ipIcmpEcho X.X.X.X
> > rtr schedule 2 start-time now life forever
> >
> > track 321 rtr 2 reachability
>
>
>You then use PBR to force half traffic to dialer1 and the other half to
>dialer2:
>
> > route-map salidaeth permit 10
> > match ip prefix-list FIRST_HALF
> > set ip next hop verify-availability A.A.A.A 10 track 321
> > set ip next hop verify-availability B.B.B.B 20 track 123
> > !
> >
> > route-map salidaeth permit 20
> > match ip prefix-list SECOND_HALF
> > set ip next hop verify-availability B.B.B.B 20 track 123
> > set ip next hop verify-availability A.A.A.A 10 track 321
>
>A MAJOR problem here is that you don't know the next-hop address of your
>dialer interfaces.....mmm....you should be able to use set ip interface
>instead of set ip next hop. I don't think this is a valid command. Kind of
>a problem here............
>
> > set ip interface verify-availability Dialer1 10 track 321
> > set ip interface verify-availability Dialer2 20 track 123
>
>
>The idea is that you force some traffic to Dialer1 when x.x.x.x is
>reachable. Once it gets to Dialer1, your NAT config will automatically
>translate to
>the Dialer1 ip address, regardless of the state of Dialer2.
>
>For destination load splitting you could split (appoximatly) half of the ip
>adressing space using ip prefix lists (matching on the first ip bit):
>
>ip prefix list FIRST_HALF permit 0.0.0.0/1 ge 1 le 32
>ip prefix list SECOND_HALF permit 128.0.0.0/1 ge 1 le 32
>
>The only remaining problem is forcing it out of Dialer1, based on
>reachability, without knowing the next-hop address.........
>
>
>Regards,
>
>Geert
>CCIE #13729
>
>
>________________________________
>
>From: nobody@groupstudy.com on behalf of fferrer10@vodafone.es
>Sent: Mon 1/10/2005 10:48
>To: Geert Nijs; ccielab@groupstudy.com
>Subject: Re: RE: conditional NAT
>
>
>
>Hi Geert:
>
>
>Maybe i have not properly explained my working scenario:
>
>I only have 1 router with 2 adsl interfaces and 2 public ip addresses.
>These public ip address are negotiated with the other end, and both
>are /32 (i only have one isp provider, but i would like to load balance
>between these 2 adsls having the security that if one of these 2 go
>down, all the traffic will go trough the another one).
>
>Solution for load balancing is not difficult using PBR, for example,
>however you must consider that in case one adsl goes down, 2 thinghs
>must me done: (correct if i am wrong)
>
>-Move all this traffic (previously going out through the adsl 1) to the
>other adsl. This is a "problem" easy to solve using PBR.
>-Nat all this traffic (previously natted with the ip address of the
>adsl 1, that now is down) to the ip address of the other adsl (adsl 2).
>Here, i think you need some type of route-map on the NAT to acomodote
>all this.
>
>Then, i think you need to apply to the NAT a ROUTE-MAP matching each
>output interface (to achieve the traffic be natted properly) like this
>one:
>
>route-map NATTING1 permit 10
> match interface dialer1
> match access-group 100
>
>route-map NATTING2 permit 10
> match interface dialer2
> match access-group 100
>
>ip nat inside source route-map NATTING1 interface dialer1 overload
>ip nat inside source route-map NATTING2 interface dialer2 overload
>
>I see weel your suggestion about "how to track the output interface is
>alive" (however it seems a bit difficult on my case because maybe the
>remote end of both adsls is the same ip address, i need to talk with
>our isp provider, but (correct if i am wrong), i think you need a route-
>map on the nat to be able to change the ip address you are translating
>to).
>
>The problem on my case, where i am using dialer interfaces , is that
>the route map used on the nat ever match, no matters the adsl is up or
>down, because the dialer will be eve up/up (spooofing).
>
>Comments? Maybe all this is impossible if i use dialer interfaces...
>
>Regards
>
>
>----- Mensaje Original -----
>De: "Geert Nijs" <geert.nijs@simac.be>
>Fecha: Viernes, Enero 7, 2005 3:03 pm
>Asunto: RE: conditional NAT
>
> > Hi,
> >
> > Good news: what you need is conditional policy based routing :-)
> > So, load up the latest IOS release, and unleash the power of IOS !:
> >
> > Using SAA, track an ip address on the other side of each ISP
> > connection(other side of the point-to-point
> > connection is great)
> >
> > rtr 1
> > type echo protocol ipIcmpEcho Y.Y.Y.Y (default router other side ISP1)
> > rtr schedule 1 start-time now life forever
> >
> > track 123 rtr 1 reachability
> >
> > rtr 2
> > type echo protocol ipIcmpEcho X.X.X.X (default router other side ISP2)
> > rtr schedule 2 start-time now life forever
> >
> > track 321 rtr 2 reachability
> >
> >
> >
> >
> > Then take your policy-based routing config and change to:
> >
> > route-map salidaeth permit 10
> > match ip address 101
> > set ip next hop verify-availability X.X.X.X 10 track 321
> > set ip next hop verify-availability Y.Y.Y.Y 20 track 123
> > !
> >
> > route-map salidaeth permit 20
> > match ip address 102
> > set ip next hop verify-availability Y.Y.Y.Y 20 track 123
> > set ip next hop verify-availability X.X.X.X 10 track 321
> >
> >
> > Maybe you need to experiment a bit with the ip adresses you track, but
> > you should be able to get
> > it working with this. No need for a special NAT config.
> >
> >
> > Regards,
> > Geert
> > CCIE #13729
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > Behalf Of
> > fferrer10@vodafone.es
> > Sent: vrijdag 7 januari 2005 12:06
> > To: Matt Mullen; ccielab@groupstudy.com
> > Subject: Re: conditional NAT
> >
> > Matt:
> >
> > Firstly, thank you very much for the info.
> >
> > The sample you provided is good if you aren't using DIALER
> > interfaces to
> > control the internet access (ADSL on mi case, as i have said on my
> > previous mail).
> >
> > Our provider uses some way of ppp over atm on these adsl, and the
> > tipical config at the adsl router is like this one:
> >
> >
> > interface ATM0/0
> > no ip address
> > no atm ilmi-keepalive
> > dsl operating-mode auto
> > pvc 8/35
> > encapsulation aal5mux ppp dialer
> > dialer pool-member 1
> >
> > interface Dialer1
> > ip address negotiated
> > ip nat outside
> > encapsulation ppp
> > dialer pool 1
> > ppp chap hostname PA281XI1
> > ppp chap password 7 032B032A2C5C157E7A
> >
> > As you can suppose, the problem i have is that a DIALER interfaz
> > is
> > always UP/UP (spoofing), no matters how the access line (adsl) is
> > up or
> > down. Then, if one of the 2 adsl i have to go out fails, i can't
> > access
> > to internet via the another one.
> >
> > I have tried to configure this adsl with a virtual-template
> > interface,
> > instead the dialer interface, but i can't achieve that the remote
> > end
> > gives me the ip public address to work with this config...
> >
> > Have anyone seen a problem like this and knows a solution?
> >
> > Regards
> >
> > ----- Mensaje Original -----
> > De: Matt Mullen <mullenm@gmail.com>
> > Fecha: Martes, Enero 4, 2005 10:17 pm
> > Asunto: Re: conditional NAT
> >
> > > Hi,
> > >
> > > Here is a configuration that will allow traffic to be port address
> > > translated to the public IP address on the interface which the
> > traffic> is leaving. The key is the 'match interface' command on the
> > > route-map which causes the traffic to be translated based on the
> > > interface that it is passing through. If one interface goes
> > > down,
> > > traffic will always leave the other one that is up and will be
> > > translated to the public IP of that interface.
> > >
> > > interface Serial0
> > > Description ISP-A
> > > ip address 88.88.88.88 255.255.255.252
> > > ip nat outside
> > >
> > > interface Serial1
> > > Description ISP-B
> > > ip address 99.99.99.99 255.255.255.252
> > > ip nat outside
> > >
> > > interface Ethernet0
> > > Description Inside
> > > ip address 10.1.1.1 255.255.255.0
> > >
> > > ip nat inside source route-map ISP-A interface Serial0 overload
> > > ip nat inside source route-map ISP-B interface Serial1 overload
> > >
> > > route-map ISP-A permit 10
> > > match interface Serial0
> > > match access-group 100
> > >
> > > route-map ISP-B permit 10
> > > match interface Serial1
> > > match access-group 100
> > >
> > > access-list 100 permit ip 10.1.1.0 0.0.0.255 any
> > >
> > >
> > > HTH,
> > > Matt
> > >
> > >
> > >
> > >
> > > On Tue, 04 Jan 2005 19:44:59 +0100, fferrer10@vodafone.es
> > > <fferrer10@vodafone.es> wrote:
> > > > Hi group:
> > > >
> > > > Anyone knows a way to configure some form of "conditional
> > natting"?> > This is, i have 1 router with 2 adsl interfaces to
> > connect to
> > > internet,> and i want to load balance the traffic using both the
> > > interfaces...then> i thought: well, maybe using policy based
> > > routing i could redirect a
> > > > group of internal subnets to one interface and the another
> > group
> > > to the
> > > > other configuring a route-map like this one:
> > > >
> > > > route-map salidaeth permit 10
> > > > match ip address 101
> > > > set default interface atm0/0 atm0/1
> > > > !
> > > > route-map salidaeth permit 20
> > > > description toINTERNET
> > > > match ip address 102
> > > > set default interface atm0/1 atm0/0
> > > >
> > > > Where 101, 102 are ACL matching the subnets i said...
> > > >
> > > > However, this router must also do the natting, and i only have
> > > the 2
> > > > public ip addresses of the adsl interfaces to use, and i must
> > assure> > that if one adsl interface goes down, all the traffic
> > use the
> > > other adsl
> > > > interface to go to internet. Also i can't use BGP on this router.
> > > >
> > > > Then, i'm wondering if there is any way to nat the subnets
> > > matching 101
> > > > acl to the ip of atm0/0 if this atm0/0 is up, and to nat them
> > to
> > > the ip
> > > > of the atm0/1 if that it is down (and similarly with the other
> > > group of
> > > > subnets).
> > > >
> > > > Regards
> > > >
> > > >
> > >
> >
>_______________________________________________________________________>
> > 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
> >
>########################################################################
>#############
> > This e-mail and any attached files are confidential and may be
> > legally privileged.
> > If you are not the addressee, any disclosure, reproduction,
> > copying, distribution,
> > or other dissemination or use of this communication is strictly
> > prohibited.
> > If you have received this transmission in error please notify
> > Simac immediately
> > and then delete this e-mail.
> >
> > Simac has taken all reasonable precautions to avoid virusses in
> > this email.
> > Simac does not accept liability for damage by virusses, for the
> > correct and complete
> > transmission of the information, nor for any delay or interruption
> > of the transmission,
> > nor for damages arising from the use of or reliance on the
> > information.
> > All e-mail messages addressed to, received or sent by Simac or
> > Simac employees
> > are deemed to be professional in nature. Accordingly, the sender
> > or recipient of
> > these messages agrees that they may be read by other Simac
> > employees than the official
> > recipient or sender in order to ensure the continuity of work-
> > related activities
> > and allow supervision thereof.
> >
>########################################################################
>#############
> >
> >
>_______________________________________________________________________
> > 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
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 02 2005 - 22:10:23 GMT-3