[c-nsp] cisco 1721 & load sharing across unequal paths.

Tue Nov 23 11:38:28 EST 2004

On Tue, Nov 23, 2004 at 05:13:05PM +0100, Tantsura, Jeff wrote:
> 
> Rodney,
> 
> See inline
> 
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com]
> Sent: Tuesday, November 23, 2004 4:40 PM
> To: Tantsura, Jeff
> Cc: ege iyioglu; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] cisco 1721 & load sharing across unequal paths.
> 
> > Where are you suggesting he use EIGRP?
> 
> Just a general suggestion -  EIGRP as routing protocol versus IGRP.
> 
> >If he is using NAT to overload on the egress ISP interfaces the return
> traffic from the ISP's will come back to the correct link.
> 
> Agreed
> 
> >If he uses two static default routes you shouldn't need any floating
> routes.  He wants them both up always as long as the path is there.  If
> one goes away traffic would take the other path.  I didn't interpret it
> >  >to mean backup as in a "dial backup" scenario.
> 
> How would you load balance with 2 defaults 1 -> 1Mb, 2-> 8mb ? Using 8Mb
> link as primary could be more than feasible scenario.

We shouldn't use load balance but rather load share.  Balance
means you try and get in a state of equilibrium and with two equal
cost paths that isn't possible.

You can't load share with static routes unless you put in more specifics.
That really isn't feasible for an internet connection scneario.
We don't support a variance concept for static routes.

The load sharing would be driven by the CEF distribution of
src/dst hashes over the two paths.  It would not be proportional
to the BW but it would be load shared to some degree.

That's where OER would kick in an attempt to load balance traffic
over the links based on the policy defined in the mater controller.

> 
> >I do agree with you on the Object tracking part to detect when the ISP
> link is up or down.
> 
> >The one problem here is that he will have a 1Mbps leased line and a
> 8Mbps wireless connection.  With two static defaults the router doesn't
> know the difference and most likely you will overload the 1Mbps >serial
> before getting close to the 8Mbps speed.
> 
> Exactly my point
> 
> >I think the most optimal solution here would be static routes with
> object tracking to make sure the ISP connections are up.
> 
> >Then to get the load balancing proportional to the link speeds use OER.
> The only gotcha here that I'm not sure about is how OER interacts with
> NAT.
> 
> >Rodney
> 
>  OER seems to do the job, would be very interesting to know how it
> interacts with NAT.

http://www.cisco.com/en/US/netsol/ns471/netqa0900aecd800f5584.html

says it's not affectecd by NAT.  Now that I think about it
given the fact that netflow is enabled on the ingress interfaces
to learn egress data flows and then inject routes based on that
data it may not affect it in any way.  With OER is there is
a BGP learned prefix that covers the traffic flow OER inserts
a BGP prefix.  If there is a static that covers the prefix
it will inserts a static route.

So in this scenario two default routes would work and allow
OER to insert more specific static routes to try and balance
the egress load.

Rodney

> 
> Jeff
> 
> 
> On Tue, Nov 23, 2004 at 04:18:08PM +0100, Tantsura, Jeff wrote:
> >
> > Hi,
> >
> > You should definitely go for EIGRP as it supports unequal load sharing
> 
> > and VLSM.
> > Second option would be 1 primary and 1 backup path with floating
> > default
> > - in this example wireless is the primary ip route 0.0.0.0 0.0.0.0
> > <next hop IP wireless> 100 ip route 0.0.0.0 0.0.0.0 <next hop IP
> > serial> 200
> >
> > In this case you could also use Reliable Static Routing Backup Using
> > Object Tracking
> > http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5413/product
> > s_
> > feature_guide09186a00801d862d.html
> > because if IP next hop is unreachable  but ethernet link is UP backup
> > wont kick in.
> >
> > Hope this helps,
> > Jeff
> >
> > With kind regards/ met vriendelijke groeten,
> > --------------------------------------------------------
> > Jeff Tantsura
> > CCIE #11416
> > Senior Consultant
> > Capgemini Nederland BV
> > Tel: +31(0)30 689 2866
> > Mob:+31(0)6 4588 6858
> > Fax: +31(0)30 689 6565
> > --------------------------------------------------------
> >
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of ege iyioglu
> > Sent: Tuesday, November 23, 2004 3:15 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] cisco 1721 & load sharing across unequal paths.
> >
> > Hi there
> > We have a Cisco 1721 router with a serial interface and an ethernet
> > interface.. You can find the run and ver info below.
> > The serial interface is connected to an ISP through a 1mbit leased
> > line connection. The ethernet interface is connected to the inside
> network.
> > We do NAT.
> > We'd like to add another ethernet interface and connect it to a
> > wireless access point that will receive an 8mbit connection from
> another ISP.
> > Both connections will provide access to the internet.
> > We also would like to implement load sharing and redundancy between
> > those 2 interfaces (the serial interface and the 2nd ethernet
> > interface..) our router has 32 MB of ram. I'm planning to run IGRP or
> > EIGRP with the maximum-paths 2 command.
> > First of all, do you think this is a feasible scenario that would
> > provide load sharing and redundancy? And if it is, would our router's
> > cpu and memory be enough for all of this or do we need an upgrade? I'm
> 
> > open to suggestions since this is the first time I will be doing this.
> >
> > Deep Regards
> > Ege
> >
> > ------- sh run --------
> > Building configuration...
> >
> > Current configuration : 1230 bytes
> > !
> > ! No configuration change since last restart !
> > version 12.2
> > service timestamps debug uptime
> > service timestamps log uptime
> > no service password-encryption
> > !
> > hostname #####
> > !
> > logging buffered 16380 debugging
> > no logging console
> > enable password #####
> > !
> > username ##### callback-dialstring ##### password 0 ##### ip
> > subnet-zero ! !
> > ! ! chat-script callback ABORT ERROR ABORT BUSY "" "ATDT\T" TIMEOUT 30
> 
> > "CONNECT" \c modemcap entry usrmodem:MSC=&FS0=1&C1&D3&H1&R2&B1
> > !
> > !
> > !
> > interface FastEthernet0
> >  ip address 212.58.x.x 255.255.255.240  speed auto !
> > interface Serial0
> >  description #####
> >  bandwidth 1024
> >  ip address 212.2.x.x 255.255.255.252
> >  no ip route-cache
> >  no ip mroute-cache
> > !
> > interface Async5
> >  ip address 192.168.x.x 255.255.255.0
> >  encapsulation ppp
> >  async default routing
> >  async mode interactive
> >  ppp callback accept
> >  ppp authentication pap
> > !
> > ip classless
> > ip classless
> > no ip http server
> > ip pim bidir-enable
> > !
> > !
> > !
> > !
> > line con 0
> > line aux 0
> >  script callback callback
> >  login local
> >  modem InOut
> >  modem autoconfigure type usrmodem
> >  transport input all
> >  autoselect during-login
> >  speed 300
> >  flowcontrol hardware
> > line vty 0 4
> >  password #####
> >  login
> > !
> > no scheduler allocate
> > end
> >
> > --------- sh ver -----------
> >
> > Cisco Internetwork Operating System Software IOS (tm) C1700 Software
> > (C1700-SY-M), Version 12.2(8)YJ, EARLY DEPLOYMENT RELEAS E SOFTWARE
> > (fc1) Synched to technology version 12.2(8.5)T TAC
> > Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by cisco
> > Systems, Inc. Compiled Fri 21-Jun-02 15:38 by ealyon Image text-base:
> > 0x80008124,
> > data-base: 0x80B64A38
> >
> > ROM: System Bootstrap, Version 12.2(7r)XM1, RELEASE SOFTWARE (fc1)
> > ROM: C1700 Software (C1700-SY-M), Version 12.2(8)YJ, EARLY DEPLOYMENT
> > RELEASE SO FTWARE (fc1)
> >
> > bilfenrtr uptime is 1 day, 2 hours, 31 minutes System returned to ROM
> > by power-on System restarted at 16:27:54 UTC Fri Nov 5 2004 System
> > image file is "flash:c1700-sy-mz.122-8.YJ.bin"
> >
> > cisco 1721 (MPC860P) processor (revision 0x100) with 29492K/3276K
> > bytes of memor y. Processor board ID FOC06330050 (1457551649), with
> > hardware revision 0000 MPC860P processor: part number 5, mask 2
> > Bridging software. X.25 software, Version 3.0.0. 1 FastEthernet/IEEE
> > 802.3
> > interface(s) 1
> > Serial(sync/async) network interface(s) 32K bytes of non-volatile
> > configuration memory. 16384K bytes of processor board System flash
> > (Read/Write)
> >
> > Configuration register is 0x2102
> >
> >
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> > This message contains information that may be privileged or
> confidential and is the property of the Capgemini Group. It is intended
> only for the person to whom it is addressed. If you are not the intended
> recipient,  you are not authorized to read, print, retain, copy,
> disseminate,  distribute, or use this message or any part thereof. If
> you receive this  message in error, please notify the sender immediately
> and delete all  copies of this message.
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.
> 