Два провайдера

Написал admin . Опубликовано в Cisco, Network просмотров 1 240

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

Часто бывает так, что локальная сеть имеет два выхода в Internet, то есть двух провайдеров. Пусть это будут ISP1 и ISP2. Эти два канала можно использовать следующим образом:

* одновременно использовать два канала для load-balancing
* один канал основной, второй backup’ный

второй канал можно использовать также двумя способами

* использовать его при падении основного
* при загрузке основного канала на Х% подключать backup’ный

Если рассматривать вырожденный случай, когда провайдер один и два канала, то тут все просто. Надо прописать два маршрута по умолчанию одинаковыми метриками

ip route 0.0.0.0 0.0.0.0 195.0.1.2
ip route 0.0.0.0 0.0.0.0 195.0.1.6

И соответственно если мы хотим сделать per-packet load-balancing, то на всех интерфейсах, которые соединяют нас с провайдером, ставим no ip route-cache, если же нужно per-destination, то на всех — ip route-cache. Заметьте, что если хотя бы на одном выходном интерфейсе используется NAT, то нельзя использовать per-packet, так как это приведет к пропаданию пакетов. Также применение policy routing выключает fast switching.

Если ваша циска поддерживает cef (cisco express forwarding), то тогда для per-packet

ip route-cache cef
ip cef per-packet

для per-destination

ip route-cache cef
ip cef per-destination

можно также договорится с провайдером, и объединить два канала в один логический, используя ppp multilink.

Если провайдеров — два, то они оба а общем случае, предоставляют вам по блоку адресов. Как их использовать? Разместить их за NAT’ом и скрыть топологию сети или использовать реальные адреса? Первое более просто реализовать и к томуже не будет потерян fast switching. Если рассматривать второе, то устройства, имеющие ip адреса первого провайдера, должны ходить через ISP1, а второго — через ISP2. Если упал канал второго провайдера, то устройства с ip адресами из блока второго провайдера не смогут выйти в Internet. Хорошо бы использовать первый канал, но ip адреса — не те. Надо использовать NAT. Если же выйдет из строя первый, то аналогично занатим и пустим через второго.

Так как имеем в сети два блока адресов, то надо применять source-routing. Так как нам нужно определить source ip-адрес пакета, и в зависимости от этого, отправить его либо ISP1 либо ISP два.

Если циска старая и ios ip only, то есть не поддерживает VLAN’ы на интерфейсе будет что-то типа

!
interface Ethernet0
ip address 195.0.1.1 255.255.255.0
ip address 195.0.2.1 255.255.255.0 secondary
ip nat inside
ip policy route-map ISP
!

если поддерживает ip plus и выше

!
interface Ethernet0/0.1
encapsulation dot1Q 1
ip address 195.0.1.1 255.255.255.0
ip nat inside
ip policy route-map ISP1
!
interface Ethernet0/0.2
encapsulation dot1Q 2
ip address 195.0.2.1 255.255.255.0
ip nat inside
ip policy route-map ISP
!

теперь разберемся с route-map’ами

если вы решили разместить их за NAT’ом и скрыть топологию сети, то эту часть можно пропустить. Надо только обязательно включить fast switching, иначе работать не будет. В случае же когда используются реальные адреса, то если внутренний интерфейс не поддерживает VLAN, пишем следующее

! если это пакет локальный пакет, то пусть циска сама роутит...
route-map ISP deny Local
match ip address 100
! если пакет с адресом из первого провайдера и канал up
! то отправляем его первому провайдеру
route-map ISP permit 20
match ip address ISP1
set ip next-hop 194.16.0.5
! если пакет с адресом из второго провайдера и канал up
! то отправляем его второму провайдеру
route-map ISP permit 30
match ip address ISP2
set ip next-hop 194.16.0.9
!

если внутренний интерфейс поддерживает VLAN или внутренних интерфейсов два, то

!
[skip]
!
route-map ISP1 permit 20
match ip address ISP1
set ip next-hop 194.16.0.5
!
[skip]
!
route-map ISP2 permit 20
match ip address ISP2
set ip next-hop 194.16.0.9
!

Local — это ACL, который ловит пакеты, source и destination адреса которых из блоков, предоставленных первым или вторым провайдером.
ISP1 — это ACL, который ловит пакеты с source-адресами из блока, предоставленного ISP1
ISP2 — это ACL, который ловит пакеты с source-адресами из блока, предоставленного ISP2
ISP — это ACL, который ловит пакеты с source-адресами из блоков, предоставленных ISP1 и ISP2

и так: разобрались. Пакеты будут посланы на нужные интерфейсы. Теперь разбираемся с NAT’ом.

Для NAT’а также нужно написать route-map.

!
route-map ISP2-NAT permit 10
match ip address ISP1
match interface Serial0/1
!
route-map ISP1-NAT permit 10
match ip address ISP2
match interface Serial0/0
!
! ISP1-pool - это пул ip-адресов, которые будут
! использованы при падении второго канала
ip nat inside source route-map ISP1-NAT pool ISP1-pool overload
!
! ISP2-pool - это пул ip-адресов, которые будут
! использованы при падении первого канала
ip nat inside source route-map ISP2-NAT pool ISP2-pool overload
!

Похожие статьи:

Метки: , , , , , , , , ,

Trackback from your site.

Comments (5)

  • Alex V

    |

    Вообще multihoming — довольно сложная штука и лично я бы подробнее рассмотрел эту тему. например BGP, route tracking + ip sla, soure-based routing.

    Reply

    • mik0z

      |

      Балансировка трафика с помощью BGP на Cisco

      Reply

  • gavru

    |

    Всё очень просто http://traffpro.ru позволяет иметь два провайдера и более, резервировать каналы, аварийно переключать при падении одно из них и так далее.

    Reply

    • admin

      |

      Так уж сложилось, но я не признаю любые виндовые поделки в этом направлении. Задачи винды — отрисовка окошек для ворда, но никак не управление трафиком.
      Хотя, есть люди, строят и на винде сети 🙂

      Reply

      • gavru

        |

        Будете смеятся, но это Linux софт роутер, со всякими наворотами типа файрвола, резервирования каналов, объединения каналов, учёта трафа, шейперов и прочего типа почтового сервера и учёта мини АТС. Так что на виндовую поделку как то не тянет. 😉

        Reply

Leave a comment