Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Появилось несколько вопросов.
1) как при такой схеме работает сбор Netflow?
2) не уверен, что директива log в ACL это хорошая идея. Роутер умрет на реальной загрузке.
3) в обоих sla у вас используется vrf isp1. Это ошибка?
4) почему в ip route vrf isp2 0.0.0.0 0.0.0.0 9.9.9.2 120 нет трекинга sla?
1) как при такой схеме работает сбор Netflow?
2) не уверен, что директива log в ACL это хорошая идея. Роутер умрет на реальной загрузке.
3) в обоих sla у вас используется vrf isp1. Это ошибка?
4) почему в ip route vrf isp2 0.0.0.0 0.0.0.0 9.9.9.2 120 нет трекинга sla?
Спасибо за замечания.
1. Так же, как всегда. Что конкретно смущает Вас в отношении совместной работы netflow и vrf?
2. Конкретно это правило ваш роутер не «нагнет», хотя все же убрал log из конфига, здесь он лишний.
3. Нет, все правильно. Хорошим тоном считается тестировать несколько адресов. Т.к. ходят слухи будто бы шлюз провайдера может отклонить icmp запросы к самому себе, что приведет к незаслуженному удалению маршрута из таблицы. Хотя на практике с такой ситуацией не встречался, привык использовать по два ip sla правила.
4. Добавить трекинг второго провайдера можно, но я посчитал это избыточным. В данной конфигурации если упадут оба ISP, в таблице маршрутизации lan vrf все равно будет маршрут шлюза второго провайдера. Если добавить трекинг, в такой ситуации она будет пустая.
P.S. Исправил опечатку с неверным шлюзом ip route vrf isp2 0.0.0.0 0.0.0.0 9.9.9.2 120
1. Так же, как всегда. Что конкретно смущает Вас в отношении совместной работы netflow и vrf?
2. Конкретно это правило ваш роутер не «нагнет», хотя все же убрал log из конфига, здесь он лишний.
3. Нет, все правильно. Хорошим тоном считается тестировать несколько адресов. Т.к. ходят слухи будто бы шлюз провайдера может отклонить icmp запросы к самому себе, что приведет к незаслуженному удалению маршрута из таблицы. Хотя на практике с такой ситуацией не встречался, привык использовать по два ip sla правила.
4. Добавить трекинг второго провайдера можно, но я посчитал это избыточным. В данной конфигурации если упадут оба ISP, в таблице маршрутизации lan vrf все равно будет маршрут шлюза второго провайдера. Если добавить трекинг, в такой ситуации она будет пустая.
P.S. Исправил опечатку с неверным шлюзом ip route vrf isp2 0.0.0.0 0.0.0.0 9.9.9.2 120
1) проблема может быть в том, что если снимать netflow с «внешнего» интерфейса при том, что он является nat outside, то в show ip ca flow будут видны адреса, в которые занатился пакет (адрес на интерфейсе isp1), что делает практически бесполезным сбор netflow, так как в нем нет необходимой информации. Покажите, как вы снимате netflow (конфигурация на интерфейсах) и вывод show ip ca flow
Не вижу ни одного преимущества перед стандартным решением без vrf. Только ненужное усложнение конфигурации.
Добрый день.
Мне нравится, что я всегда могу мониторить и имею доступ к своему оборудованию по публичным адресам из любой точки мира. В стандарном решении одноммоментно доступен толкьо один првайдер, с тем который не активен вы не можете провести полноценный icmp тест, что бы оценить качество канала или подлючится удаленно без включения специфических правил в таблицу маршрутизации.
Ох, знали бы Вы как классно стоить отказоустойчивые VPN туннели с данным решением. Full Mesh FlexVPN? Раз плюнуть!
Мне нравится, что я всегда могу мониторить и имею доступ к своему оборудованию по публичным адресам из любой точки мира. В стандарном решении одноммоментно доступен толкьо один првайдер, с тем который не активен вы не можете провести полноценный icmp тест, что бы оценить качество канала или подлючится удаленно без включения специфических правил в таблицу маршрутизации.
Ох, знали бы Вы как классно стоить отказоустойчивые VPN туннели с данным решением. Full Mesh FlexVPN? Раз плюнуть!
как классно стоить отказоустойчивые VPN туннели с данным решением, Full Mesh FlexVPN
поподробнее можно- в чем прелести вашего варианта? Чем он лучше- удобнее хорошо разжеванного Dual Hub DMVPN например?
я не говорил, что он лучше)) просто реализовано по-другому. Коротко мы держим 4 открытых туннеля и балансируем их с помощью eigrp:
Spoke ISP1 – HUB01
Spoke ISP2 – HUB01
Spoke ISP1 – HUB02
Spoke ISP2 – HUB02
Есть вариант для экономных с 2-одновременными туннелями
Spoke ISP1 – HUB01
Spoke ISP1 – HUB02
Остальные поднимаются по мере пропадания связи
Spoke ISP1 – HUB01
Spoke ISP2 – HUB01
Spoke ISP1 – HUB02
Spoke ISP2 – HUB02
Есть вариант для экономных с 2-одновременными туннелями
Spoke ISP1 – HUB01
Spoke ISP1 – HUB02
Остальные поднимаются по мере пропадания связи
Доступность второго адреса при живом первом можно сделать с помощью одного единственного route-map.
ip access-list standard Prov2
10 permit host <Router_IP_address_ISP2>
route-map MakeProv2Alive
match ip address Prov2
set ip next-hop <ISP2_gateway>
ip local route-map MakeProv2Alive
Тогда пакеты, которые роутер захочет отправить от source IP, принадлежащего 2 провайдеру, будут завёрнуты на соответствующий шлюз.
ip access-list standard Prov2
10 permit host <Router_IP_address_ISP2>
route-map MakeProv2Alive
match ip address Prov2
set ip next-hop <ISP2_gateway>
ip local route-map MakeProv2Alive
Тогда пакеты, которые роутер захочет отправить от source IP, принадлежащего 2 провайдеру, будут завёрнуты на соответствующий шлюз.
Вероятно, что прелесть в NAT внутри VRF. Таким образом при падении одного аплинка не надо ждать таймаутов NAT или делать clear ip nat tr *
Но нужно проверять.
Но нужно проверять.
А так да, идея постоянной доступности по двум каналам- полезная.
Еще вопрос: если нужно сделать ip nat inside source static 192.168.x.x 91.8.2.3 как быть в вашем варианте (в случае с sla просто меням правила с помощью скрипта- старое выбрасываем, для работающего канала прописываем)
Еще вопрос: если нужно сделать ip nat inside source static 192.168.x.x 91.8.2.3 как быть в вашем варианте (в случае с sla просто меням правила с помощью скрипта- старое выбрасываем, для работающего канала прописываем)
мне кажется, что track 123 list boolean or надо менять на track 123 list boolean and.
Далее, в этом трекинге нужно настроить соответсвующие delay up/down — очень часто встречается ситуация когда «восьмерки» выпадают на секундочку и трекинг туда-сюда переключаться начинает, что приводит к потере связи на ровном месте.
Далее, в этом трекинге нужно настроить соответсвующие delay up/down — очень часто встречается ситуация когда «восьмерки» выпадают на секундочку и трекинг туда-сюда переключаться начинает, что приводит к потере связи на ровном месте.
это не так. с xgu
track list boolean <and | or>
and:
комбинированный трек в UP, если все объекты внутри UP
комбинированный трек в DOWN, если один или более объектов внутри DOWN
or:
комбинированный трек в UP, если хотя бы один объект внутри UP
комбинированный трек в DOWN, если все объекты внутри DOWN
Кстати, на схеме с VRF можно сделать и двух одновременно работающих провайдеров.
Если интересно, могу вспомнить детали.
Если интересно, могу вспомнить детали.
Представленная схема работать не будет,
для того чтобы в vrf lan появились дефолтные маршруты этого кода недостаточно
требуется или там же дописать
redistribute static
или
дописывать ip route vrf lan 0.0.0.0 0.0.0.0 1.1.1.2 и ip route vrf lan 0.0.0.0 0.0.0.0 2.2.2.2
Пожалуйста, прежде чем оспаривать это сделайте лабу.
для того чтобы в vrf lan появились дефолтные маршруты этого кода недостаточно
address-family ipv4 vrf isp1
redistribute connected
default-information originate
exit-address-family
требуется или там же дописать
redistribute static
или
дописывать ip route vrf lan 0.0.0.0 0.0.0.0 1.1.1.2 и ip route vrf lan 0.0.0.0 0.0.0.0 2.2.2.2
Пожалуйста, прежде чем оспаривать это сделайте лабу.
да вы правы
я почему то был уверен что этой комманды достаточно default-information originate
я почему то был уверен что этой комманды достаточно default-information originate
Router# sh run | section route
route-target export 65000:1
route-target import 65000:99
route-target export 65000:2
route-target import 65000:99
route-target export 65000:99
route-target import 65000:1
route-target import 65000:2
router bgp 65000
bgp router-id 1.1.1.1
bgp log-neighbor-changes
!
address-family ipv4 vrf isp1
redistribute connected
redistribute static metric 100
default-information originate
exit-address-family
!
address-family ipv4 vrf isp2
redistribute connected
redistribute static metric 120
default-information originate
exit-address-family
!
address-family ipv4 vrf lan
redistribute connected
exit-address-family
ip route vrf isp1 0.0.0.0 0.0.0.0 1.1.1.2 100
ip route vrf isp2 0.0.0.0 0.0.0.0 2.2.2.2 120
И раз уж вы тут, чтобы НАТ начал работать реально одновременно через два провайдера, автоматически через BGP балансируя трафик,
надо:
— убрать метрики с дефолтных маршрутов
— дописать в bgp в разделе address-family ipv4 vrf lan
строчку maximum-paths 2
тогда потом трейс traceroute vrf lan 8.8.8.8 source 192.168.1.1 покажет что два НАТА начали работать одновременно
надо:
— убрать метрики с дефолтных маршрутов
— дописать в bgp в разделе address-family ipv4 vrf lan
строчку maximum-paths 2
тогда потом трейс traceroute vrf lan 8.8.8.8 source 192.168.1.1 покажет что два НАТА начали работать одновременно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Два провайдера одновременно или Dual ISP with VRF на Cisco