cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
678
Views
5
Helpful
11
Replies

Load Balancing Router 1811

Mehdi Talei
Level 1
Level 1

Hello,

I have a Cisco 1811 with two WAN connections. I am using Track to detect down state of principal WAN interface. Everything works fine and the backup line will be up as soon as the principal line goes down.

The problem that I have is that, even when the principal line is up and running, I have data transfer on the backup interface! This data transfer costs money, because the data transfer on backup line is limited.

How can I prevent this data transfer when the first line is up?

Thanks,

Mehdi

11 Replies 11

Edison Ortiz
Hall of Fame
Hall of Fame

Please post config and the routing table output to determine what routes may be preferred via the backup connection.

You can potentially have a problem as routes coming into your network via the backup connection, not leaving your network. In that case, you need to troubleshoot the remote device for routing preference.

__

Edison.

ip sla 10

icmp-echo xxx.xxx.xxx.xxx source-interface FastEthernet0

timeout 4000

threshold 10

frequency 4

ip sla schedule 10 life forever start-time now

!

!

interface FastEthernet0

ip address dhcp client-id FastEthernet0

no ip redirects

no ip unreachables

ip nat outside

ip virtual-reassembly

no ip route-cache cef

no ip route-cache

no ip mroute-cache

duplex auto

speed auto

no cdp enable

crypto ipsec client ezvpn NAME

!

interface FastEthernet1

ip address dhcp client-id FastEthernet1

no ip redirects

no ip unreachables

ip nat outside

ip virtual-reassembly

no ip route-cache cef

no ip route-cache

no ip mroute-cache

duplex auto

speed auto

no cdp enable

crypto ipsec client ezvpn BACKUP

!

ip route 0.0.0.0 0.0.0.0 FastEthernet0 track 1

ip route xxx.xxx.xxx.xxx 255.255.255.255 FastEthernet0

ip route 0.0.0.0 0.0.0.0 FastEthernet1 dhcp 10

sh ip int br

Interface IP-Address OK? Method Status Protocol

FastEthernet0 AAA.BBB.CCC.DDD YES DHCP up up

FastEthernet1 EEE.FFF.GGG.HHH YES DHCP up up

sh ip route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

xxx.0.0.0/32 is subnetted, 1 subnets

S xxx.xxx.xxx.xxx is directly connected, FastEthernet0

AAA.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S yyy.yyy.yyy.yyy/32 [254/0] via AAA.BBB.CCC.1, FastEthernet0

C AAA.BBB.CCC.0/24 is directly connected, FastEthernet0

10.0.0.0/25 is subnetted, 1 subnets

C 10.132.29.0 is directly connected, Vlan1

EEE.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C EEE.FFF.GGG.0/24 is directly connected, FastEthernet1

S EEE.FFF.GGG.HHH/32 [254/0] via EEE.FFF.GGG.HHH, FastEthernet1

S* 0.0.0.0/0 is directly connected, FastEthernet0

Fa0 is the principal line and Fa1 is the backup one.

There isn't any routes pointing Fa1 other than the peer route /32 and the /24 from the subnet.

It's odd the subnet on that interface is /24 instead of /30. Perhaps broadcast traffic from the remote /24 is being sent/recvd on this interface hence causing some traffic over this link.

You also have a dhcp client running on the interface so some packets will be transmitted over this link.

If you want to determine what kind of traffic is entering/leaving the interface, I recommend configuring NetFlow.

http://www.cisco.com/en/US/docs/ios/netflow/configuration/guide/cfg_nflow_data_expt_ps6350_TSD_Products_Configuration_Guide_Chapter.html

__

Edison.

Edison,

Thanks a lot for the reply.

Yes, the traffic should be verified to see where is it coming from.

My another question was how to monitor the traffic on WAN interface that you answered by your suggestion using Netflow.

I will do it and will let you know the result.

Thanks.

Edison,

I configured Netflow on my backup interface, but nothing appears when I do sh ip cache flow. Here is the result:

sh ip cache flow

IP packet size distribution (0 total packets):

1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480

.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608

.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes

0 active, 4096 inactive, 0 added

0 ager polls, 0 flow alloc failures

Active flows timeout in 30 minutes

Inactive flows timeout in 15 seconds

IP Sub Flow Cache, 34056 bytes

0 active, 1024 inactive, 0 added, 0 added to flow

0 alloc failures, 0 force free

1 chunk, 1 chunk added

last clearing of statistics never

Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)

-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts

I configured simply ip flow ingress and

ip flow egress under interface Fa1.

Am I missing something?

PS : I configured netflow on Fa0 as well, but still nothing appears. I believe that I am doing something wrong, but I don't know what it is!!!

You need to enable mroute-cache, route-cache and route-cache cef on the interfaces.

I'm not sure why you are disabling those features since they help on the router performance. Disabling those features cause the traffic to be process-switched instead of cef-switched.

HTH,

__

Edison.

I had enabled them, but still getting nothing on Fa1.

I get the flow on Fa0 (the principal line) though.

Mehdi

Good, it seems Fa1 traffic flow isn't constant.

Do you see input/output increasing on the interface and the NetFlow counter isn't showing anything? If so, it can be the router's control traffic like keepalive, dhcp client - among other things.

I also noticed you have a crypto session on the interface, is that session active the whole time?

__

Edison.

input/output are increasing non-stop on the interface. Netflow counter is increasing also. But they seem to be irrelevant according to the two following results :

sh int fa1:

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

9 packets input, 570 bytes

Received 4 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog

0 input packets with dribble condition detected

180 packets output, 10800 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 unknown protocol drops

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

sh ip cache flow

IP packet size distribution (4 total packets):

1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480

.000 1.00 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608

.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes

1 active, 4095 inactive, 4 added

58 ager polls, 0 flow alloc failures

Active flows timeout in 30 minutes

Inactive flows timeout in 15 seconds

IP Sub Flow Cache, 34056 bytes

0 active, 1024 inactive, 0 added, 0 added to flow

0 alloc failures, 0 force free

1 chunk, 0 chunks added

last clearing of statistics 00:24:23

Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)

-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow

TCP-other 3 0.0 1 52 0.0 0.0 15.2

Total: 3 0.0 1 52 0.0 0.0 15.2

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts

Fa1 74.198.AAA.BBB Local 74.198.CCC.DDD 06 CEBC 01BD 1

(IP address 74.198.CCC.DDD is the one on my interface)

In Netflow the traffic which is showed is ingress one, but on the interface is the packets output which are increasing.

I do agree with you about router control traffic. This traffic might be that, but i need to eliminate them though.

The crypto session will stay inactive until when the interface comes up. I even removed it from the interface, but the result is the same!

dgroscost
Level 4
Level 4

Simplest way - Use floating static routes.

ISP1 - Preferred path - say your default route is 10.10.10.1.

ISP2 - Backup route, costs $ - say your default route is 20.20.20.1

Change your routes to:

ip route 0.0.0.0 0.0.0.0 10.10.10.1 10

ip route 0.0.0.0 0.0.0.0 20.20.20.1 20

This way all traffic will route over ISP#1 until that route disappears from the routing table (link goes down), then traffic will route over ISP #2.

You could still use the track functionality in those statements if you want - just attach a 'track tracking#' to the end of the route statements.

Be sure to remove any other route statements in there that were previously used.

Peter010101
Level 1
Level 1

You have a few options.

post your config.

Are you using a routing protocol or static routes?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco