📜 ⬆️ ⬇️

Cisco Unequal Load Balancing with two providers, NAT and static gateways

The topic may be beaten. But the solution to the problem with the specified source data is not found. Poke your nose, if not right. I had to do some tricks ;-).

Formulation of the problem


In one city, N-ke has a small network with two providers connected to a Cisco router. IOS 12.2 (33). After the next expansion of the channels, we take 8 Mbit from the " First " provider, and 4 Mbit from the " Second ".

Dynamic routing with providers is not and is not expected.
Users NAT to provider-dependent IP addresses.
')
It is necessary to maximize both channels.

image



Initial configuration


interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.252

interface FastEthernet1/0
ip address 192.168.2.2 255.255.255.252

ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 0.0.0.0 0.0.0.0 192.168.2.1

route-map FirstNAT permit 10
match interface FastEthernet0/0
route-map SecondNAT permit 10
match interface FastEthernet1/0

ip nat source route-map FirstNAT interface FastEthernet0/0 overload
ip nat source route-map SecondNAT interface FastEthernet1/0 overload


Search solutions



Anyone who does not like this part, please immediately to the decision.

Having two equal gateways, the traffic is split in half between the providers. With heavy traffic (on the Second “shelf” of 4 Mbit), the First download does not rise above 5 Mbit.

After reading helpful documentation from cisco.com:

- How does load balancing work?
How does the Load Path Balancing (Variance) Work in IGRP and EIGRP?
- Troubleshooting Cisco Express Forwarding Load Balancing Over Parallel Links

We find an interesting show ip cef {prefix} internal command.
Router# sh ip cef 0.0.0.0 0.0.0.0 internal
!----cut----
Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 1)

Hash OK Interface Address Packets
1 Y FastEthernet1/0 192.168.2.1 0
2 Y FastEthernet0/0 192.168.1.1 0
3 Y FastEthernet1/0 192.168.2.1 0
4 Y FastEthernet0/0 192.168.1.1 0
5 Y FastEthernet1/0 192.168.2.1 0
6 Y FastEthernet0/0 192.168.1.1 0
7 Y FastEthernet1/0 192.168.2.1 0
8 Y FastEthernet0/0 192.168.1.1 0
9 Y FastEthernet1/0 192.168.2.1 0
10 Y FastEthernet0/0 192.168.1.1 0
11 Y FastEthernet1/0 192.168.2.1 0
12 Y FastEthernet0/0 192.168.1.1 0
13 Y FastEthernet1/0 192.168.2.1 0
14 Y FastEthernet0/0 192.168.1.1 0
15 Y FastEthernet1/0 192.168.2.1 0
16 Y FastEthernet0/0 192.168.1.1 0
!----cut----


It can be seen that in the CEF there are 16 buckets (seats / slots / buckets) that are filled with routes to the specified network from the Routing Table (RIB).

Here it is a tool with which you can control the proportion of outgoing traffic. And when using NAT to the addresses of the provider, and the incoming !

In our problem, the traffic ratio should be 2: 1. It is necessary that the First Provider was indicated by two routes, and the Second - by one. It is necessary, just to register a fictitious route on the First Provider.

Hint appeared here
blog.ioshints.info/2007/02/unequal-load-split-with-static-routes.html

In the prompt, the providers are connected via the Serial interface and one route is registered via the IP address, the second through the interface. In the version with FastEthernet, this focus does not work, the network is not point-to-point and needs next-hop IP.

I tried to cheat. I registered the default route to a non-existent address, plus added a route to this address through the First Provider:

ip route 0.0.0.0 0.0.0.0 172.16.1.1
ip route 172.16.1.1 255.255.255.255 192.168.1.1


Focus did not pass, cef figured out by recursion that it would still be sent to 192.168.1.1. The picture has not changed.

Decision


So, one route in the direction of each provider already exists. It is necessary to add one more fictitious route in the direction of the First Provider.

To do this, we configure a dummy subnet on the First Provider interface and a dummy gateway:

interface FastEthernet 0/0
ip address 172.16.1.2 255.255.255.252 secondary
ip route 0.0.0.0 0.0.0.0 172.16.1.1

The route will appear, but the traffic will go nowhere, since the First Provider does not have the address 172.16.1.1.

Now, attention , everyday cunning ;-). We look at the real MAC address of the gateway of the first provider and write it into the static ARP entry.

arp 172.16.1.1 XXXX.XXXX.XXXX arpa


That's it, the trick is over. The route is fictitious, but the real traffic goes to the real First Provider.

Router# sh ip cef 0.0.0.0 0.0.0.0 internal
!----cut----
Load distribution: 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 (refcount 1)

Hash OK Interface Address Packets
1 Y FastEthernet1/0 192.168.2.1 0
2 Y FastEthernet0/0 192.168.1.1 0
3 Y FastEthernet0/0 172.16.1.1 0
4 Y FastEthernet1/0 192.168.2.1 0
5 Y FastEthernet0/0 192.168.1.1 0
6 Y FastEthernet0/0 172.16.1.1 0
7 Y FastEthernet1/0 192.168.2.1 0
8 Y FastEthernet0/0 192.168.1.1 0
9 Y FastEthernet0/0 172.16.1.1 0
10 Y FastEthernet1/0 192.168.2.1 0
11 Y FastEthernet0/0 192.168.1.1 0
12 Y FastEthernet0/0 172.16.1.1 0
13 Y FastEthernet1/0 192.168.2.1 0
14 Y FastEthernet0/0 192.168.1.1 0
15 Y FastEthernet0/0 172.16.1.1 0
!----cut----

Same meaning but without tricks

Agree with the First provider about secondary addresses. Then it remains to register two routes for two provider IP addresses.

findings


In this way, you can control the proportion of incoming / outgoing traffic in the very ordinary way of connecting to several providers. And do not need BGP, AS, PI addresses.

The cons are also obvious:
- There are a few options for proportion.
- It is impossible to manage the traffic of connections established from the Internet.
- when changing the MAC on the provider's gateway, we get a blackhole.

PS Later I found an article blog.ronix.net.ua/2008/10/ciso.html with the same meaning, but without the trick with the ARP record.

UPD

Habrouser Fedia correctly noted that I was wrong. This way you can control the number of sessions (TCP in the main) in the direction of each provider, and not incoming traffic.

Fedia :
And due to the fact that cef with two routes will divide traffic in half - this is not quite true. It will divide the initialization of the sessions (either by packets, or by destination, or by the source-destination pair, it may even divide by ports), but not the traffic count itself. Those. It may be (by default, he divides NOT into packages), that the sessions are equal, and there is 2-3 times more traffic on one provider.

But I have a lot of users and each consumes a little. So the proportion by the number of sessions, in my case, practically corresponds to the projection of incoming traffic.

Source: https://habr.com/ru/post/77383/


All Articles