хотя это не заметно так как визде и так ip

если l2 транспорт был - оно вообще бы не работало

покажи ip mpls forw на там роутере где генерируется ответ что стоит в метках куда он ответ шлет

forwarding пустой! хотя ldp соседа видит, таблица с биндингами тоже нормальная

т.е. если был бы разрыв домена, то таблица с биндингами была бы пустая, так?

он не должен быть пустым

forwarding пустой! хотя ldp соседа видит, таблица с биндингами тоже нормальная

А глобально mpls вкыл ?

mpls ip ?

или там какой-то cef

Всем привет! кто-нить пытался запустить mpls на eve-ng? ldp работает, но в wireshark icmp пакеты ходят без инкапсуляции. кто виноват и что делать?) заранее спасибо

но зачем запускать mpls на убунту?

технически, конечно, возможно, но...

Мало кому нужно

А как же шило?

https://www.draw.io может?

спасибо!

но зачем запускать mpls на убунту?

в учебных целях? :)

понимаю. сам люблю поизвращаться

Есть еще одна софтина: Cisco Packet Tracer - очень просто, в стиле ХР ))

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

Есть еще одна софтина: Cisco Packet Tracer - очень просто, в стиле ХР ))

Да.. занятное предназначение)

Да.. занятное предназначение)

ну там иконки есть у оборудования, связи автоматом делаются (правда только по кратчайшему пути), легко все двигается с созранением связей, простенькие примечания можно делать

ну там иконки есть у оборудования, связи автоматом делаются (правда только по кратчайшему пути), легко все двигается с созранением связей, простенькие примечания можно делать

А visio? Или dia?))

Оказывается "прозрачная маршрутизация" это как раз с использованием NAT http://www.intuit.ru/studies/courses/4088/1286/lecture/24245

А visio? Или dia?))

Visio - не нравится. Там сложно и неудобно рисовать схемы. Особенно проблема с линиями связей

А visio? Или dia?))

я сейчас сравнил между собой draw.io и Edraw - в итоге draw.io оказался куда удобнее в работе

Edraw слишком похож на Visio - чуть получше, но тоже какой-то корявенький

Оказывается "прозрачная маршрутизация" это как раз с использованием NAT http://www.intuit.ru/studies/courses/4088/1286/lecture/24245

Ох уж эти термины, использование которых должно как бы упрощать долгое разжевывание, а по факту получается наоборот

Оказывается "прозрачная маршрутизация" это как раз с использованием NAT http://www.intuit.ru/studies/courses/4088/1286/lecture/24245

вот вам и открытый университет )

МММ... Чистейший прозрачнейший нат!

т.е. если был бы разрыв домена, то таблица с биндингами была бы пустая, так?

Трейс если делаешь, выдает метки в пути?

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

Телнет то включен?

короче, метки пропадают на роуетере, который на хоп раньше PHP идет. до этого label-advertisement крутил на ELSR, но сейчас этого нет в конфигах, хотя это бы объяснило для меня такое поведение

короче, метки пропадают на роуетере, который на хоп раньше PHP идет. до этого label-advertisement крутил на ELSR, но сейчас этого нет в конфигах, хотя это бы объяснило для меня такое поведение

Маски на loopback используемых в ldp /32?

по схеме видно, что /24

Маски на loopback используемых в ldp /32?

не везде 32 маска :( ща проверю и исправлю. спасибо)

не везде 32 маска :( ща проверю и исправлю. спасибо)

пожалуйста. напишите, помогло ли

Оказывается "прозрачная маршрутизация" это как раз с использованием NAT http://www.intuit.ru/studies/courses/4088/1286/lecture/24245

а "локальная маршрутизация" - это мемчик из этого чатика или из протелекома?

пожалуйста. напишите, помогло ли

фух, я разобрался. имело место все-таки PHP. НО это происходило из-за суммаризации маршрутов isis на R9, поэтому xrv13 считал что loopbacks R6 находятся на r9. вот так из-за забывчивости потратил 2 часа)

всем спасибо

Телнет то включен?

Да даже компьютер с которого трассировку делают включен.

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

ну может rst пакет вполне достаточен для tacertcp что бы указать его доступность

ну может rst пакет вполне достаточен для tacertcp что бы указать его доступность

Хм. Логично. Но, пара хопов до сервера наши и мы там ничего не фильтруем. Предполагал, что где-то на уровне прова проблемы, тогда, по идее, трастсп не смог бы обнаружить хопы за тем, кто кидается в клиента рст.

А он, гад, обнаружил) хотя, может, я не до конца понимаю принцип тсп трассировки

Хм. Логично. Но, пара хопов до сервера наши и мы там ничего не фильтруем. Предполагал, что где-то на уровне прова проблемы, тогда, по идее, трастсп не смог бы обнаружить хопы за тем, кто кидается в клиента рст.

Если порт открыт, не факт, что телнет сервер включен

Если порт открыт, не факт, что телнет сервер включен

Так мне и не надо чтоб он был включен, я просто порт щупаю. Там вообще, тлс висит на порту

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

Интересный доклад о маршрутизации трафика внутрироссийских AS в интернете: http://www.rans.ru/images/news/Traffic_30112017.pdf

действительно, интересно

средняя нагрузка на абонента - полмегабита

Вот это как раз не новость

я не знал, думал меньше :)

Всем привет! Если есть народ из Челябинска и окрестностей - милости просим на встречу сисадминов, сетевиков и девопсов в пятницу в ресторане Ланжерон https://sysadminka.timepad.ru/event/627512/

по каким причинам хост может принимать DHCP Offer, но не отправлять DHCP Request?

есть идейки?

кто-то с таким же маком в l2 сегменте?

нет свободных ip?)

кто-то с таким же маком в l2 сегменте?

вряд ли, это телефоны , и только на 3х такая проблема

нет свободных ip?)

Он в оффере не предлагался тогда бы, не?

Он в оффере не предлагался тогда бы, не?

DORA, упс. забыл порядок.

dora the explora

давайте ей поможем найти реквесты

по каким причинам хост может принимать DHCP Offer, но не отправлять DHCP Request?

А он действительно его принимает, или это в логе dhcp-сервера discover-offer-discover-offer?

А он действительно его принимает, или это в логе dhcp-сервера discover-offer-discover-offer?

в логе.

Ну, может он и не принимает офферы, но почему?

acl deny boots? :)

acl deny? по маку?

для конкретных устройств?

по udp порту

ERROR: S client not available

А есть вариант, что IP пришедший в offer-е уже занят и проверка на уникальность IP не проходит?

я просто предположил. Включите дамп на телефоне, проверьте, доходят ли. :)

А есть вариант, что IP пришедший в offer-е уже занят и проверка на уникальность IP не проходит?

сервер перед отправкой проверяет адрес же

1) физика 2) acl на коммутаторах

А есть вариант, что IP пришедший в offer-е уже занят и проверка на уникальность IP не проходит?

в логах бы видел как они их получают. Но нет

не все серверы делают проверку. и клиент на своей стороне тоже делает это

1) физика 2) acl на коммутаторах

1) Если бы физика - дискавер бы не прилетал от них 2) ацл на коммутаторах отсутствуют как таковые

А есть вариант, что IP пришедший в offer-е уже занят и проверка на уникальность IP не проходит?

Был бы decline, не?

Был бы decline, не?

верно) не проснулся я, видать

1) Если бы физика - дискавер бы не прилетал от них 2) ацл на коммутаторах отсутствуют как таковые

1) запросто прилетал бы. В провайдинге офферы -верный знак вначале проверить физику, вечно какая-нибудь жила перебита оказывается, таких ситуаций множество 2) коммутаторы какой марки? Или они тупые?

1) запросто прилетал бы. В провайдинге офферы -верный знак вначале проверить физику, вечно какая-нибудь жила перебита оказывается, таких ситуаций множество 2) коммутаторы какой марки? Или они тупые?

1) там вифи точки, а люди с мобилами передвигаются, если бы где-то сигнал проседал и он не получал айпишник из-за этого - ладно. Где-то бы - получал. 2) сиско сустемс

вероятность каких-то глобальных проблем вроде физики или сбоев на л2 транспорте стремится к минимальной, потому что там еще около 30 устройств с которыми всё ок.

А, ну так надо было начинать с того что это вифи... А то телефоны бывают voip-шные...

2 из 3 - шиндовс фоны, поназначили себе автоайпишники 169.254 и сидят

а третий - редмишка какая-то , на ней ничего

А что общего у не подключающихся? Операционка/SoC/...? Роуминг (11r) и прочие подобные фичи в сети используются? На ум приходит какая-нибудь несовместимость...

Да вот у меня тоже на ум какая-то несовместимость приходит, ток не знаю какая.

Роуминг, band steering, сюрпризы реализации wpa-enterprise, причуды 11ac с 20/40/80 мгц

ну, это между точками и контроллером реализуется всё, так?

ну, это между точками и контроллером реализуется всё, так?

А у вас схема на контроллере построена ?

А у вас схема на контроллере построена ?

хз, контроллер и точки уже не наши

только транспорт авторизация и dhcp

Если это отдельный контроллер и для этих клиентов выделен отдельный влан и они все в нем, а сервер в другом влане, тогда на интервлане может блокировать ацл на адрес 255.255.255.255 и порт юдп bootps, или банально забыли интерфейс для этого влана создать или хелпер прописать.

Другие пользователи у которых все работает в таких де группах и вланах как и те у которых проблема ?

ну я его отправил тишутить вот это всё - пусть делает че хочет

там всякий треш происходит, и фейковые точки студентики создают, и что только не творится

а SSID скорее всего там один, это общественное место какое-то

забей.

Друзья, какие есть способы(готовые решения) в linux балансировки трафика по нескольким каналам per connection(что-то типа round-robin)? Задача размазать исходящие соединения по нескольким каналам. Нат используется. Цель в том, чтобы обеспечить доступ к внешему ресурсу с разных ip адресов во имя избежания блокировки

Слушайте. Тут такой вопрос в плане обучения. Вот есть протокол IPv4&6. Вокруг них (если так можно выразиться) вертятся другие протоколы, такие как ICMPV4&6, IGMP, NDP, MLD прочие тонкости multicast и anycast тем. Вопрос заключается в следующем: В какой последовательностьи усе этот стоит изучать и на что обращать внимание. Хочется структурировать такой набор технологий, чтобы не возникало путаницы. Понятно, что походу изучения многое из этого само по себе попадается под руку и все же, переодически натыкаешься на что-то, когда думал что тебя уже закрыта. Или это все какие-то необоснованные заебы и придирки?

Слушайте. Тут такой вопрос в плане обучения. Вот есть протокол IPv4&6. Вокруг них (если так можно выразиться) вертятся другие протоколы, такие как ICMPV4&6, IGMP, NDP, MLD прочие тонкости multicast и anycast тем. Вопрос заключается в следующем: В какой последовательностьи усе этот стоит изучать и на что обращать внимание. Хочется структурировать такой набор технологий, чтобы не возникало путаницы. Понятно, что походу изучения многое из этого само по себе попадается под руку и все же, переодически натыкаешься на что-то, когда думал что тебя уже закрыта. Или это все какие-то необоснованные заебы и придирки?

есть шикарная книга ipv6 fundamentals мне очень помогла именно в плане структуры