Jump to content
Калькуляторы

ip unnumbered - резервирование Подскажите как зарезервировать

А isis оно умеет?

Share this post


Link to post
Share on other sites

Не один раз уже писали, что настроили на микротике штук 20 зон OSPF и там что-то откуда-то не видится. Смысл-то какой так делать? Когда достаточно сделать одну зону и все будет отлично работать.

Share this post


Link to post
Share on other sites

I need more Mikrotik's!!!)))))))))))))))))))))

nu-pochemu_37973635_orig_.jpg

Share this post


Link to post
Share on other sites

Возвращаясь к теме. Накопали пару кошек,

настроили так:

 

R1:

interface GigabitEthernet0/1.3

encapsulation dot1Q 3

ip address 192.168.240.254 255.255.255.0

vrrp 2 ip 192.168.240.254

vrrp 2 timers advertise msec 200

no vrrp 2 preempt

!

interface GigabitEthernet0/1.3000

encapsulation dot1Q 3000

ip unnumbered GigabitEthernet0/1.3

 

R2:

interface GigabitEthernet0/1.3

encapsulation dot1Q 3

ip address 192.168.240.253 255.255.255.0

vrrp 2 ip 192.168.240.254

vrrp 2 timers advertise msec 200

no vrrp 2 preempt

!

interface GigabitEthernet0/1.3000

encapsulation dot1Q 3000

ip unnumbered GigabitEthernet0/1.3

 

 

 

show:

R1

GigabitEthernet0/1.3 - Group 2

State is Master

Virtual IP address is 192.168.240.254

Virtual MAC address is 0000.5e00.0102

Advertisement interval is 0.200 sec

Preemption disabled

Priority is 255

Master Router is 192.168.240.254 (local), priority is 255

Master Advertisement interval is 0.200 sec

Master Down interval is 0.603 sec

 

R2:

Router#sh vrrp

GigabitEthernet0/1.3 - Group 2

State is Backup

Virtual IP address is 192.168.240.254

Virtual MAC address is 0000.5e00.0102

Advertisement interval is 0.200 sec

Preemption disabled

Priority is 100

Master Router is 192.168.240.254, priority is 255

Master Advertisement interval is 1.000 sec

Master Down interval is 1.209 sec (expires in 1.073 sec)

 

 

 

Вроде все как работает!!!

основной вопрос который возник.

 

делаем трассировку до ya.ru

первым хопом нам показывается 192.168.240.254

Но вот когда все переходит на резерв нам отвечает 192.168.240.253

в ARP только 192.168.240.254 адрес 240.253 - нет

пинг до 192.168.240.254 - идет.

Хотелось бы, что бы резервная кошка отвечала не со своего адреса, все же с виртуального 192.168.240.254

 

что это? особенность протокола? особенность реализации на кошке? или чего -то не до крутили?

Edited by Renaissance87

Share this post


Link to post
Share on other sites

GLBP - это как бы не vrrp ))

 

Вопрос, кто у себя настраивал vrrp, у кого он реально сейчас работает, картина таже ??

Edited by Renaissance87

Share this post


Link to post
Share on other sites

Сделайте так, что бы vrrp ip не совпадал с физическим.

Share this post


Link to post
Share on other sites

Сделайте так, что бы vrrp ip не совпадал с физическим.

Если мне не изменяет память обратный ответ пойдёт от физического интерфейса.

VRRP, HSRP, GLBP резервируют шлюз - "Gateway Load Balancing Protocol (GLBP) protects data traffic from a failed router or circuit, like Hot Standby Router Protocol (HSRP) and Virtual Router Redundancy Protocol (VRRP), while allowing packet load sharing between a group of redundant routers."

Если шлюзами являются устройства cisco то использовать можно хоть HSRP хоть VRRP - они работают почти одинаково.

GLBP добавляет ещё возможность балансировки между шлюзами. Если использовать балансировку host depended то наверно можно и между брасами так нагрузку раскидывать(не помню правда что за host считается - source ip или source mac)

Применительно к резервированию брасов IPoE лично мне не понятно как роутер за брасами узнает на какой из брасов отправлять ответ конкретному абоненту?

Может кто пояснить?

Share this post


Link to post
Share on other sites

Ну и почем железки доступа с поддержкой MPLS? Только, повторяюсь, не сохо поделки, которые виснут от любого пука на клиентском порту.

 

Если вести разговор про коммутаторы, то для транспортной сети используются коммутаторы L3, у них ценник от 90 тыс.р., что бы к этим коммутаторам влить L2, требуется поддержка EoMPLS, тут ценник уже поболее 150 тыс.р., к такому коммутатору, а на нем обычно от 16 оптических портов, подключают обычные L2 коммутаторы и передают трафик абонентов во вланах.

 

А какие L3 с EoMPLS вы ставите? Что у вас его в ядре разбирает?

Почему бы просто по L3 (OSPF) не догнать абонента, зачем засовывать его в MPLS?

 

Если это имеет значение - для двух сетей средняя и крупная.

Share this post


Link to post
Share on other sites

А какие L3 с EoMPLS вы ставите? Что у вас его в ядре разбирает?

 

Используем CCR1016 с оптическими портами, он легко пропускает 1-2 гигабита не напрягаясь, больше пока трафика на промежуточных узлах не набегает. Обслуживает 6-8-10 оконечных выносов, и имеет 1-2-3 магистральных канала. Один обычно в центр по топологии звезда, и один или два по топологии кольцо на соседние узлы, где есть возможность проложить оптику или можно составить некую обходную оптическую трассу. То есть почти каждый узловой CCR имеет как минимум 2 канала. Это позволяет без проблем балансировать трафик, т.к. настроив одинаковые веса маршрутов, можно заставить трафик бегать и напрямую в центр, и по веткам кольца. В ядре разбирает стопка микротиков с костылями.

 

Почему бы просто по L3 (OSPF) не догнать абонента, зачем засовывать его в MPLS?

 

Так можно, и примерно в половине случаев так и делается - на портах или вланах (в зависимости от возможности оконечного оборудования) устанавливаются абонентские IP адреса поштучно (при необходимости там же навешивается DHCP) и они уже идут через маршрутизацию в сеть. Но тут есть минус в том, что ограничение скорости не устанавливается на этих устройствах, и абоненты могут между собой передавать данные на любой скорости. Вешать же шейпера на промежуточных узлах или L3 устройствах не всегда возможно, т.к. удобнее всем этим рулить в центре. Естественно, по серым адресам можно просто заблокировать доступ и это решит проблему с ограничениями, но по белым просто так не сделать.

 

L2 интерфейс поверх MPLS выгоден тем, что его можно использовать уже без привязки в центре, то есть подавать туда разные услуги, и получить централизованное управление абонентскими портами, не важно что там на доступе установлено. Если на транспорте используется увеличенный размер MTU, то фрагментации данных в туннеле нет, и для абонента это совершенно не заметно. Так же некоторые порты сдаются в аренду другим операторам, и на стыке просто отдаются заранее согласованные вланы, либо, если у них тоже MPLS железка, то предоставляется доступ в сеть с фильтром по разрешенным туннелям, что бы ничего не напортачили в чужой сети.

 

Если это имеет значение - для двух сетей средняя и крупная.

 

Когда в сети мало устройств, например коммутаторов. То их можно легко обслуживать. А когда их 1000 и более, уже вопрос более сложный, т.к. один админ уже это все делать не может, и каждый отвечает за свою часть сети. И если разделить сеть на уровни транспорта, доступа и т.п., то снова становится легко всем управлять. И если те, кто занимаются коммутаторами, делают свои дела по замене сгоревших, даже на другую модель, то все, что им надо - только прописать те же вланы, что были ранее. И центр сети и транспорт трогать не надо. Аналогично на транспорте - сгорела железка - восстановили не трогая ничего другого. Ну а в центре, имея поверх L3 все L2 интерфейсы оконечных коммутаторов, можно подавать любые услуги, не оглядываясь на возможности оконечного коммутатора. При этом сами коммутаторы в домах, можно использовать максимально дешевые - учитывая то, что их много и они бывает сгорают, это сильно экономит средства оператора.

Share this post


Link to post
Share on other sites

L2 интерфейс поверх MPLS выгоден тем, что его можно использовать уже без привязки в центре, то есть подавать туда разные услуги, и получить централизованное управление абонентскими портами, не важно что там на доступе установлено. Если на транспорте используется увеличенный размер MTU, то фрагментации данных в туннеле нет, и для абонента это совершенно не заметно. Так же некоторые порты сдаются в аренду другим операторам, и на стыке просто отдаются заранее согласованные вланы, либо, если у них тоже MPLS железка, то предоставляется доступ в сеть с фильтром по разрешенным туннелям, что бы ничего не напортачили в чужой сети.

 

Просмотр сообщенияiValera (07 июня 2017 - 15:09) писал:

Если это имеет значение - для двух сетей средняя и крупная.

 

 

Когда в сети мало устройств, например коммутаторов. То их можно легко обслуживать. А когда их 1000 и более, уже вопрос более сложный, т.к. один админ уже это все делать не может, и каждый отвечает за свою часть сети. И если разделить сеть на уровни транспорта, доступа и т.п., то снова становится легко всем управлять. И если те, кто занимаются коммутаторами, делают свои дела по замене сгоревших, даже на другую модель, то все, что им надо - только прописать те же вланы, что были ранее. И центр сети и транспорт трогать не надо. Аналогично на транспорте - сгорела железка - восстановили не трогая ничего другого. Ну а в центре, имея поверх L3 все L2 интерфейсы оконечных коммутаторов, можно подавать любые услуги, не оглядываясь на возможности оконечного коммутатора. При этом сами коммутаторы в домах, можно использовать максимально дешевые - учитывая то, что их много и они бывает сгорают, это сильно экономит средства оператора.

 

Все-равно не понятно в чем выигрыш прокидывать l2 через l3. Какие разные услуги? IPoE маршрутизируется, pppoe тоже, IPTV по PIM, в чем тут не справится OSPF?

Управление, возможно да, станет легче, но а в остальном?

Share this post


Link to post
Share on other sites

Я же уже писал - аренда L2 каналов. Их можно сделать только через L2 туннели. Второй вариант это когда для работы абонентов нужен L2 интерфейс на брасе - тут так же только проброс туннелей поверх L3.

Не все можно сделать напрямую с интерфейсов, установленных на маршрутизаторах рядом с абонентами. Так же нужно не забывать про внутрисетевой трафик, который тоже должен идти через центр, для возможности его ограничения. В случае с навешиванием OSPF на маршрутизаторах и там же терминации абонентов, потребуется создавать фильтры на каждом маршрутизаторе, и там же ограничивать скорость, что не всегда удобно.

Share this post


Link to post
Share on other sites

Я же уже писал - аренда L2 каналов. Их можно сделать только через L2 туннели.

Аренда l2 каналов решается пробрасыванием Vlan, минус только в отсутствии резерва и время инженера на прописку vlan, если это не автоматизировано.

 

Второй вариант это когда для работы абонентов нужен L2 интерфейс на брасе - тут так же только проброс туннелей поверх L3.

Так же проброс vlan.

Share this post


Link to post
Share on other sites

Аренда l2 каналов решается пробрасыванием Vlan, минус только в отсутствии резерва и время инженера на прописку vlan, если это не автоматизировано.

Так же проброс vlan.

 

Аренда L2 уже давно вланами не реализовывается, т.к. это очень опасно - клиент может напустить туда столько маков, что ляжет все оборудование оператора. Кроме всего, при старой схеме - требуется настройка всех коммутаторов на пропуск всех типов трафика (по умолчанию они не все пропускают), короче проблем выше крыши. А если прокинуть надо в соседний город, или соседнюю область - будет та еще веселуха.

 

Поэтому в современных реалиях только L3 на транспорте самая оптимальная технология, которая поддерживает и резервирование из коробки.

Share this post


Link to post
Share on other sites

Аренда l2 каналов решается пробрасыванием Vlan, минус только в отсутствии резерва и время инженера на прописку vlan, если это не автоматизировано.

Так же проброс vlan.

 

Аренда L2 уже давно вланами не реализовывается, т.к. это очень опасно - клиент может напустить туда столько маков, что ляжет все оборудование оператора. Кроме всего, при старой схеме - требуется настройка всех коммутаторов на пропуск всех типов трафика (по умолчанию они не все пропускают), короче проблем выше крыши. А если прокинуть надо в соседний город, или соседнюю область - будет та еще веселуха.

 

Поэтому в современных реалиях только L3 на транспорте самая оптимальная технология, которая поддерживает и резервирование из коробки.

конечно не реализовывается, никто вообще в стране больше вланы не использует.это устаревшая технология

Share this post


Link to post
Share on other sites

конечно не реализовывается, никто вообще в стране больше вланы не использует.это устаревшая технология

Не столько устаревшая, сколько малоэффективная в силу многочисленных ограничений. Сааба хоть и не любят, но иногда он все же выдает достаточно разумные мысли.

Операторы "покрупней" уже давно не гоняют вланы на транспорте; зачастую намного проще, удобней и надежней наладить l3 связность и гонять те же xconnect/vpls/vpws. Вланы остаются разве что на последней миле.

И он вполне реальны проблемы поднимает - если вы даете l2 как услугу, ожидать можно все что угодно. И когда в контракте будет рисоваться хорошая цена, вряд ли ваши коммерсанты станут дописывать в договор ограничения "не более 8 маков на порт, протоколы только ip, никакого мультикаста/броадкаста" чтоб огородить себя от возможных последствий от поспешных решений. А уж диагностировать чужой мультикаст через весь свой транспорт или почему какие-то pdu то ходят то не ходят и подавно. К тому же EoIP (EoMPLS) проще мониторить и документировать, потому как вам достаточно знать состояние только точек подключения (которых в большинстве случаев 2), и не ломать голову над тем "где там еще забыли прописать тот влан". И да, ваш спокойный сон более не потревожат TCN того же spanning-tree или дерганье колец.

Хотя, это больше актуально для тех, кто уже перешел за черту "оператор покрупней"; у небольших операторов такие услуги заказываются крайне редко, и в основном без извращений (например, просто для обвязки нескольких офисов в одну l2 сеть).

Share this post


Link to post
Share on other sites

Хотя, это больше актуально для тех, кто уже перешел за черту "оператор покрупней"; у небольших операторов такие услуги заказываются крайне редко, и в основном без извращений (например, просто для обвязки нескольких офисов в одну l2 сеть).

 

Операторы покрупней просто используют дорогое оборудование с поддержкой L3. А маленькие операторы могут использовать оборудование попроще, которое, без проблем выдает 1-2-3 гигабита на транзитном трафике.

 

Вообще от вланов сложно переучиваться. Особенно если много лет только с этой технологией и работали. Многие сети провайдеров, кроме как вланы - вообще ничего из технологий не используют. И вот раздувшись до размера в 10 и более тысяч абонентов, просто увеличивают количество портов, тянут в центр больше волокон, переходят на 10G и т.п. Но сама технология остается одна и та же.

 

конечно не реализовывается, никто вообще в стране больше вланы не использует.это устаревшая технология

 

С одной стороны это плюс. Т.к. помогает операторам, скажем так, работающих на более современных технологиях, перехватывать клиентов у крупных, которые не могут дать нужные услуги с высокой скоростью и в любом месте.

 

Яркий пример - абоненту требуется канал L2 из своего офиса в некий филиал на окраине города. Сам же абонент делать канал через интернет не хочет. Провайдер, практикующий вланы, не сможет предоставить ему канал, т.к. на окраине города у него своего подключения нет, а прогнать туннель поверх интернета потребует установки дополнительного маршрутизатора у абонента, и ответного в филиале (подключив канал, например от сотовых). Но абонент может заметить подвох. У оператора современного есть возможность прогнать L2 поверх L3 в центр и оттуда передать в филиал, через любого оператора. При этом к уже подключенному абоненту даже ехать не потребуется.

Share this post


Link to post
Share on other sites

Яркий пример - абоненту требуется канал L2 из своего офиса в некий филиал на окраине города. Сам же абонент делать канал через интернет не хочет. Провайдер, практикующий вланы, не сможет предоставить ему канал, т.к. на окраине города у него своего подключения нет, а прогнать туннель поверх интернета потребует установки дополнительного маршрутизатора у абонента, и ответного в филиале (подключив канал, например от сотовых). Но абонент может заметить подвох. У оператора современного есть возможность прогнать L2 поверх L3 в центр и оттуда передать в филиал, через любого оператора. При этом к уже подключенному абоненту даже ехать не потребуется.

а почему нельзя просто взять л2 у любого оператора? Мы так регулярно делаем.

 

И он вполне реальны проблемы поднимает - если вы даете l2 как услугу, ожидать можно все что угодно. И когда в контракте будет рисоваться хорошая цена, вряд ли ваши коммерсанты станут дописывать в договор ограничения "не более 8 маков на порт, протоколы только ip, никакого мультикаста/броадкаста" чтоб огородить себя от возможных последствий от поспешных решений. А уж диагностировать чужой мультикаст через весь свой транспорт или почему какие-то pdu то ходят то не ходят и подавно. К тому же EoIP (EoMPLS) проще мониторить и документировать, потому как вам достаточно знать состояние только точек подключения (которых в большинстве случаев 2), и не ломать голову над тем "где там еще забыли прописать тот влан". И да, ваш спокойный сон более не потревожат TCN того же spanning-tree или дерганье колец.

да, но опять же л2 оборудование развивается, появляются удобные фильтры, которые как раз помогают этого избежать.

Share this post


Link to post
Share on other sites

да, но опять же л2 оборудование развивается, появляются удобные фильтры, которые как раз помогают этого избежать.

Пока не видел port security > 32 мака ;) А вот случаи когда вдувают от 4-6к маков - видел. Видел в требованиях клиента LLC/SNAP, который чаще всего отказывается через l2 коммутаторы бегать.

Много чего видел, что проще завернуть в vpws тремя-пятью строчками команд в cli, чем ломать голову "да где ж ты скотина не пролезаешь то".

Share this post


Link to post
Share on other sites

а почему нельзя просто взять л2 у любого оператора? Мы так регулярно делаем.

 

Так по тем же причинам, по которым сами L2 через вланы не предоставляем - много проблем на пустом месте. Сколько не связывались с такими каналами (только мы все равно поверх передаем L3, и уже поверх EoIP или MPLS), так регулярно возникают проблемы с пропуском некоторого трафика, или попадания чужого трафика в канал. Например перестает бегать OSPF, т.к. заблокировался мультикаст, или залетают чужие данные в сеть. А как оператору доказать это, не имея микротика с дальнего конца линка? На нем можно через торч узнать номера вланов, IP адреса и сказать их оператору - на это они сильно удивляются, берут паузу на несколько часов, и потом все исправно работает еще месяц или два, потом все повторяется.

 

С тем же успехом можно просто интернет подключить и не заморачиваться с подобными проблемами, а для надежности подключить его от разных провайдеров.

Share this post


Link to post
Share on other sites

Вот вы так прекрасно поёте про EoIP, да круто конечно, но я пытаюсь приземлить к нашим реалиям. У нас сеть на длинках, на агрегации 3627/3620. О каком EoIP может идти речь? Менять 500 коммутаторов агрегации ради того что кому-то влом прокинуть влан с одного города в другой или из-за потенциального одного клиента которому может потребоваться 50 мак-адресов? Бизнес скорее откажется от такого клиента, чем согласовать бюджет на апгрейд агрегации ради mpls.

Я не прав?

 

ps: не хочу никого обидеть, EoIP конечно круто, но..

pss: DES-1210-28/ME:5# config port_security 2 max_learning_addr <max_lock_no 0-64> к вопросу о вливании маков в порт оператора и что не видел более 32.

psss: сорри что удалились от топика

Share this post


Link to post
Share on other sites

Так не нужно менять все коммутаторы, достаточно поменять на промежуточных узлах, оконечка может на вланах так и сидеть. Тогда сможете и резервирование сделать через L3 технологии, ведь все абонентские порты (вланы) будут в центре сети уже в MPLS идти.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this