IFCONFIG_FORMAT

Eugene Grosbein написал(а) к Victor Sudakov в Nov 18 14:58:58 по местному времени:

07 нояб. 2018, среда, в 12:20 NOVT, Victor Sudakov написал(а):

VS>>>>> Если даже у мелкого оператора аллокейшен от RIPE не менее /32,
VS>>>>> то в этом /32 будет 65 тысяч блоков /48. Жалко, что ли?
EG>>>> 65 тысяч клиентов это не так много, с учетом мертвых душ,
EG>>>> из-за которых в IPv4 приходится с годами переиспользовать
EG>>>> адреса.
VS>>> Это конечно философский вопрос, что такое много или мало:
VS>>> https://youtu.be/sDRJhAWMRIM?t=20
EG>> Куча орехов это когда их можно сложить так, что их центры не лежат
EG>> в одной плоскости. То есть, до трёх орехов включительно это не куча,
EG>> а четыре уже можно попробовасть сложить кучей-пирамидкой:
EG>> три в основании и один сверху.
VS> Это если определять "кучу" геометрически по возможности сложить образующие её
VS> предметы горкой. Но определить более абстрактное понятие "много" уже не
VS> получится геометрически.

Зато получится аксиоматически, при помощи математической индукции:
один орех это не много, на один больше это не много, ещё на один больше
это не много, а дальше - много.

VS> 65 тысяч клиентов, каждому из которых ты дашь routable /24 - это тебе надо
VS> иметь IPv4 аллокейшен /8, это две тыщи стандартных /19-х аллокейшенов, если я
VS> правильно посчитал. По-моему это очень большой провайдер/LIR.
VS> И это я ещё не считал полосу, которая такому провайдеру понадобится. Ведь
VS> каждый клиент захочет никак не менее 100 Мбит/с, а скорее 1 Гбит/с. Даже с
VS> учетом oversubscription... боюсь считать. Да и не буду уводить разговор в
VS> сторону, речь всё-таки об адресации.

Я не имел в виду мультихом-клиентов с /24, вообще не понимаю откуда они взялись.
65 тысяч клиентов я имел виду любых.

VS>>> ЗЫ Пожалуй метод оценки Попугая самый правильный.
EG>> К сожалению, он эфемерный и субъективный :-)
VS> Э нет, попугай мудр и видимо знаком с тезисом Протагора.

Тезис Протагора - самопротиворечивый софизм, если даже не касаться
того очевидного факта, что это антропоцентризм, а почти любой
антропоцентризм ложен.

Eugene
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Alex Korchmar в Nov 18 00:34:05 по местному времени:

05 нояб. 2018, понедельник, в 11:47 NOVT, Alex Korchmar написал(а):

>> А те, что имеют, либо заказывают L2 vlan для соединения своих точек,
AK> да как будто у тебя в l2 мультикасты работают, ага, поверила бабка.

У меня - работают, и я не знаю причин, по которым в L2 мультикасты
могли бы не работать.

>> внутри своего VRF. Магистралы так вообще не поддерживают роутинг
>> мультикастов по дефолту, если не заказать услугу специально.
AK> магистралам оно реже прилетает, у них нет таких клиентов или они продаются
AK> как услуга.

Кстати, о магистралах. Заказали тут на днях у Ростелекома vlan
с правильным mtu до удалённой точки за пределами города,
с обоих сторон влана поставили каталисты и dotq-tunnel поверх влана -
свой транк прокинули. IP в своих вланах работает, включая DНCP
и мультикасты, а PPPoE-фреймы идут только в одну сторону - бродкасты
от удалённой точки через dotq-tunnel приходят, ответные юникасты
отправляются, как подтверждает зеркалирование физического порта стыка,
уходят с двумя тегами 802.1q, как положено - на ту сторону не приходят.

Как так можно сделать, не понятно. Только если специально, но зачем?

Eugene
--- slrn/1.0.3 (FreeBSD)

Evgeny Larionov написал(а) к Eugene Grosbein в Nov 18 10:37:52 по местному времени:


Нello Eugene!

09 Nov 18 00:34, you wrote to Alex Korchmar:

EG> Кстати, о магистралах. Заказали тут на днях у Ростелекома vlan
EG> с правильным mtu до удалённой точки за пределами города,
EG> с обоих сторон влана поставили каталисты и dotq-tunnel поверх влана -
EG> свой транк прокинули. IP в своих вланах работает, включая DНCP
EG> и мультикасты, а PPPoE-фреймы идут только в одну сторону - бродкасты
EG> от удалённой точки через dotq-tunnel приходят, ответные юникасты
EG> отправляются, как подтверждает зеркалирование физического порта стыка,
EG> уходят с двумя тегами 802.1q, как положено - на ту сторону не
EG> приходят.

EG> Как так можно сделать, не понятно. Только если специально, но зачем?


PPPoE snooping на коммуаторах доступа ?

/Evgeny


--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Evgeny Larionov в Nov 18 11:33:28 по местному времени:

09 нояб. 2018, пятница, в 10:37 NOVT, Evgeny Larionov написал(а):

EG>> Как так можно сделать, не понятно. Только если специально, но зачем?
EL> PPPoE snooping на коммуаторах доступа ?

Вероятно - про эту хрень я не подумал.

Eugene
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Evgeny Larionov в Nov 18 15:35:13 по местному времени:

09 нояб. 2018, пятница, в 10:37 NOVT, Evgeny Larionov написал(а):

EG>> Кстати, о магистралах. Заказали тут на днях у Ростелекома vlan
EG>> с правильным mtu до удалённой точки за пределами города,
EG>> с обоих сторон влана поставили каталисты и dotq-tunnel поверх влана -
EG>> свой транк прокинули. IP в своих вланах работает, включая DНCP
EG>> и мультикасты, а PPPoE-фреймы идут только в одну сторону - бродкасты
EG>> от удалённой точки через dotq-tunnel приходят, ответные юникасты
EG>> отправляются, как подтверждает зеркалирование физического порта стыка,
EG>> уходят с двумя тегами 802.1q, как положено - на ту сторону не
EG>> приходят.
EG>> Как так можно сделать, не понятно. Только если специально, но зачем?
EL> PPPoE snooping на коммуаторах доступа ?

Да, это было оно. Оказалось, что Ростелеком воткнул наш линк
в коммутатор, на котором в глобальном конфиге включен
PPPoE Intermediate Agent и он блочил серверные фреймы PPPoE,
несмотря на то, что не активирован на нашем влане - временное
отключение агента в глобальном контексте проблему сняло.
Это всё со слов местной техподдержки Ростелекома
и по результатам совместного тестирования.

Причём Ростелекому оказалось проще перевести влан на отдельное волокно
(и на том спасибо), чем оформить внутри себя установку отдельного свича.

Eugene
--
- Локапалы непобедимы, - сказал Кубера, а девочка подняла кубик
и долго-долго разглядывала его, прежде чем назвать.
--- slrn/1.0.3 (FreeBSD)