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

[Tantsura, Jeff]

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.

>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.

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.