Developers Club geek daily blog

1 year ago
At the classical scheme of connection of two ISP to one router, there is an opportunity to use at once two channels for Natirovaniya of internal clients with balancing of loading, and not just for a feylover at failure of one of providers.

It is performed as follows:
c use of vrf:
the description of vrf for the first provider:
we export our tag "100:0",
we import a tag from vrf of the second 100:1 provider

ip vrf ISPA
 rd 100:0
 route-target export 100:0
 route-target import 100:1

the description of vrf for the second provider:
we export our tag "100:1",
we import a tag from vrf of the first 100:0 provider

ip vrf ISPB
 rd 100:1
 route-target export 100:1
 route-target import 100:0

the description of vrf for a client network:
we import both tags from vrf of two providers "100:0" and "100:1"

ip vrf LAN
 rd 100:100
 route-target import 100:0
 route-target import 100:1


Setup of interfaces:
to the first provider:
we configure the correct vrf
ip vrf forwarding ISPA

we include nat
ip nat outside


interface FastEthernet0/0
 ip vrf forwarding ISPA
 ip address 50.0.0.1 255.0.0.0
 ip nat outside

to the second provider:
we configure the correct vrf
ip vrf forwarding ISPB

we include nat
ip nat outside


interface FastEthernet1/0
 ip vrf forwarding ISPB
 ip address 60.0.0.1 255.0.0.0
 ip nat outside

the interface looking in a local area network:
we configure the correct vrf
ip vrf forwarding LAN

we include nat
 ip nat inside


interface FastEthernet1/1
 ip vrf forwarding LAN
 ip address 192.168.0.1 255.255.255.0
 ip nat inside


Routes by default to providers:
with indication of vrf for each route

ip route vrf ISPA 0.0.0.0 0.0.0.0 50.0.0.2
ip route vrf ISPB 0.0.0.0 0.0.0.0 60.0.0.2


The BGP setup for a mutual redistribyyution of routes between vrf:
we extend the connected networks from interfaces:
redistribute connected

we extend static default routes to providers:
  redistribute static
  default-information originate

in client vrf we permit load distribution:
maximum-paths 2


router bgp 65000
 address-family ipv4 vrf ISPA
  redistribute connected
  redistribute static
  default-information originate

 address-family ipv4 vrf ISPB
  redistribute connected
  redistribute static
  default-information originate

 address-family ipv4 vrf LAN
  redistribute connected
  maximum-paths 2


Rules for NAT:
we include NAT on both external interfaces in client vrf

ip nat inside source route-map A interface FastEthernet0/0 vrf LAN overload
ip nat inside source route-map B interface FastEthernet1/0 vrf LAN overload


Access list and route-map for the rules Natirovaniya:
we use route-map for two purposes:
— IOS would not allow to create two different rules NAT for one access-list
— identification on the outgoing interface

route-map A permit 10
 match ip address 1
 match interface FastEthernet0/0

route-map B permit 10
 match ip address 1
 match interface FastEthernet1/0

access-list 1 permit 192.168.0.0 0.0.0.255


For check that balancing of routes happened, we will use the traceroute command:
R1#traceroute vrf  LAN 8.8.8.8 source fa 1/1
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
  1 50.0.0.2 132 msec
    60.0.0.2 44 msec
    50.0.0.2 24 msec

apparently from the coming answers two providers answer.

The table NAT after these answers confirms the created compliances:
R1#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
udp 50.0.0.1:49162     192.168.0.1:49162  8.8.8.8:33434      8.8.8.8:33434
udp 60.0.0.1:49163     192.168.0.1:49163  8.8.8.8:33435      8.8.8.8:33435
udp 50.0.0.1:49164     192.168.0.1:49164  8.8.8.8:33436      8.8.8.8:33436


The routing table for client vrf looks as follows:
R1#show ip route vrf LAN

B*    0.0.0.0/0 [20/0] via 60.0.0.2 (ISPB), 00:00:20
                [20/0] via 50.0.0.2 (ISPA), 00:00:20
      50.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B        50.0.0.0/8 is directly connected (ISPA), 00:00:22, FastEthernet0/0
L        50.0.0.1/32 is directly connected, FastEthernet0/0
      60.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B        60.0.0.0/8 is directly connected (ISPB), 00:00:20, FastEthernet1/0
L        60.0.0.1/32 is directly connected, FastEthernet1/0
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, FastEthernet1/1
L        192.168.0.1/32 is directly connected, FastEthernet1/1


without use of vrf:
#интерфейс к первому провайдеру
interface FastEthernet0/0
 ip address 50.0.0.1 255.0.0.0
 ip nat outside

#интерфейс ко второму провайдеру
interface FastEthernet1/0
 ip address 60.0.0.1 255.0.0.0
 ip nat outside

#интерфейс к клиентской сети
interface FastEthernet1/1
 ip address 192.168.0.1 255.255.255.0
 ip nat inside

#PBR для того чтобы при запросах снаружи наш роутер не путался куда отдавать пакеты
ip local policy route-map PBR

#NAT правила и маршруты по умолчанию с одинаковыми метриками
ip nat inside source route-map A interface FastEthernet0/0 overload
ip nat inside source route-map B interface FastEthernet1/0 overload
ip route 0.0.0.0 0.0.0.0 50.0.0.2
ip route 0.0.0.0 0.0.0.0 60.0.0.2

#PBR если пакеты должны уйти через первый провайдер
route-map PBR permit 10
 match ip address 10
 set ip next-hop 50.0.0.2

#PBR если пакеты должны уйти через второй провайдер
route-map PBR permit 20
 match ip address 11
 set ip next-hop 60.0.0.2

#для NAT через первого провайдера
route-map A permit 10
 match ip address 1
 match interface FastEthernet0/0

#для NAT через второго провайдера
route-map B permit 10
 match ip address 1
 match interface FastEthernet1/0

#сопутствующие acl
access-list 1 permit 192.168.0.0 0.0.0.255
access-list 10 permit 50.0.0.1
access-list 11 permit 60.0.0.1

All thanks for attention, I wait for your comments.

This article is a translation of the original post at habrahabr.ru/post/273813/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: sysmagazine.com@gmail.com.

We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.
Best wishes.

comments powered by Disqus