[fox_m]

Всем привет. Интересует следующий вопрос. На всех физических интерфейсах внутри AS используются "серые" ip адреса. В сети сосуществуют между собой EIGRP и BGP. Через EIGRP расходятся по сети loopback адреса для настройки сессий BGP. Все работает. Но при трасировке "белого" ip адреса из внешней AS, в ответе traceroute появляются мои "серые" ip адреса, что в общем логично. Вопрос, как быть:

 

1. Оставить все как есть

2. Перейти на глобальную адресацию внутри сети

3. Может есть какие-то средства?

[GrandPr1de]

а чем вам мешают серые хопы?

как по мне ничего "криминального", особенно в условиях нехватки IPv4 более чем приемлимо

[cvb]

Ещё один довод переходить на IPv6 :)

[fox_m]

а чем вам мешают серые хопы?

как по мне ничего "криминального", особенно в условиях нехватки IPv4 более чем приемлимо

 

Да даже не знаю. Насколько это с точки зрения безопасности приемлемо?

[mikezzzz]

тоже не вижу ничего плохого,

мегафон, видимо, тоже )

[orlik]

Всем привет. Интересует следующий вопрос. На всех физических интерфейсах внутри AS используются "серые" ip адреса. В сети сосуществуют между собой EIGRP и BGP. Через EIGRP расходятся по сети loopback адреса для настройки сессий BGP. Все работает. Но при трасировке "белого" ip адреса из внешней AS, в ответе traceroute появляются мои "серые" ip адреса, что в общем логично. Вопрос, как быть:

 

1. Оставить все как есть

2. Перейти на глобальную адресацию внутри сети

3. Может есть какие-то средства?

 

Под другим я вижу только no-propagate-ttl

[fox_m]

тоже не вижу ничего плохого,

мегафон, видимо, тоже )

 

Да, у коллег и МФ такое часто встречается.

[mixae1]

3. Может есть какие-то средства?

Завести белый loopback и назначить его ответственным за ответ, если конечно железка так может. Вообще ничего криминального в серых адресах нет, единственное неудобство обратное имя, наверное, не резолвится.

[fox_m]

3. Может есть какие-то средства?

Завести белый loopback и назначить его ответственным за ответ, если конечно железка так может. Вообще ничего криминального в серых адресах нет, единственное неудобство обратное имя, наверное, не резолвится.

 

Такой loopback есть. Интересно, cisco умеет такое делать?

[Megas]

а по jun напомните как это делается, чтобы ответ шел с loopback?

Изменено 12 января, 2016 пользователем Megas

[vlad11]

Всем привет. Интересует следующий вопрос. На всех физических интерфейсах внутри AS используются "серые" ip адреса. В сети сосуществуют между собой EIGRP и BGP. Через EIGRP расходятся по сети loopback адреса для настройки сессий BGP. Все работает. Но при трасировке "белого" ip адреса из внешней AS, в ответе traceroute появляются мои "серые" ip адреса, что в общем логично. Вопрос, как быть:

 

1. Оставить все как есть

2. Перейти на глобальную адресацию внутри сети

3. Может есть какие-то средства?

 

Пункт 2.

Маршрутизация через серые сети влияет на окна TCP. Визуально это выглядит, как медленная скорость загрузки-аплоуда в однопоточном режиме.

 

Ну и не забыть про внедрение Ipv6.

Дойче Телеком в свое время было дешевле построить опорную сеть на IPv6.

Подозреваю, что крупные операторы в Европе (Orange, Free.fr, OVH) уже перешли на магистраль в IPv6.

[GrandPr1de]

Всем привет. Интересует следующий вопрос. На всех физических интерфейсах внутри AS используются "серые" ip адреса. В сети сосуществуют между собой EIGRP и BGP. Через EIGRP расходятся по сети loopback адреса для настройки сессий BGP. Все работает. Но при трасировке "белого" ip адреса из внешней AS, в ответе traceroute появляются мои "серые" ip адреса, что в общем логично. Вопрос, как быть:

 

1. Оставить все как есть

2. Перейти на глобальную адресацию внутри сети

3. Может есть какие-то средства?

 

Пункт 2.

Маршрутизация через серые сети влияет на окна TCP. Визуально это выглядит, как медленная скорость загрузки-аплоуда в однопоточном режиме.

 

Ну и не забыть про внедрение Ipv6.

Дойче Телеком в свое время было дешевле построить опорную сеть на IPv6.

Подозреваю, что крупные операторы в Европе (Orange, Free.fr, OVH) уже перешли на магистраль в IPv6.

 

ска, какой-то поток сознания

[s.lobanov]

Всем привет. Интересует следующий вопрос. На всех физических интерфейсах внутри AS используются "серые" ip адреса. В сети сосуществуют между собой EIGRP и BGP. Через EIGRP расходятся по сети loopback адреса для настройки сессий BGP. Все работает. Но при трасировке "белого" ip адреса из внешней AS, в ответе traceroute появляются мои "серые" ip адреса, что в общем логично. Вопрос, как быть:

 

1. Оставить все как есть

2. Перейти на глобальную адресацию внутри сети

3. Может есть какие-то средства?

 

Пункт 2.

Маршрутизация через серые сети влияет на окна TCP. Визуально это выглядит, как медленная скорость загрузки-аплоуда в однопоточном режиме.

 

Ну и не забыть про внедрение Ipv6.

Дойче Телеком в свое время было дешевле построить опорную сеть на IPv6.

Подозреваю, что крупные операторы в Европе (Orange, Free.fr, OVH) уже перешли на магистраль в IPv6.

 

После такого можно смело удалять аккаунт с нага. Я чуть не блеванул увидев это позорище

[tehmeh]

С точки зрения безопасности - ничего страшного, даже наоборот, как минимум никто по ssh/telnet/snmp на эти маршрутизаторы не попадет.

Правилом хорошего тона считается фильтровать или echo на эти адреса, или echo-reply с них, чтобы скрывать такие хопы.

 

Но серые адреса на P-t-P линках нарушают RFC 1918. Если кто-то фильтрует SRC IP на входе в сеть с таких адресов, как минимум, может не работать Path MTU discovery, и такие адреса у них будут выпадать из traceroute.

 

Вот, например, здоровская нить на эту тему http://www.gossamer-threads.com/lists/cisco/nsp/26987

[pppoetest]

Влад11 или пьян был, или троллил, или кто-то угнал аккаунт.

[GrandPr1de]

Влад11 или пьян был, или троллил, или кто-то угнал аккаунт.

 

Да нет, он часто чушь несет.

[pppoetest]

Не замечал.

[rdntw]

Маршрутизация через серые сети влияет на окна TCP

 

ясно

[fox_m]

Всем привет. Интересует следующий вопрос. На всех физических интерфейсах внутри AS используются "серые" ip адреса. В сети сосуществуют между собой EIGRP и BGP. Через EIGRP расходятся по сети loopback адреса для настройки сессий BGP. Все работает. Но при трасировке "белого" ip адреса из внешней AS, в ответе traceroute появляются мои "серые" ip адреса, что в общем логично. Вопрос, как быть:

 

1. Оставить все как есть

2. Перейти на глобальную адресацию внутри сети

3. Может есть какие-то средства?

 

Пункт 2.

Маршрутизация через серые сети влияет на окна TCP. Визуально это выглядит, как медленная скорость загрузки-аплоуда в однопоточном режиме.

 

Ну и не забыть про внедрение Ipv6.

Дойче Телеком в свое время было дешевле построить опорную сеть на IPv6.

Подозреваю, что крупные операторы в Европе (Orange, Free.fr, OVH) уже перешли на магистраль в IPv6.

 

Это как?! Причем тут серые ip и окно tcp?!

[dmvy]

Если есть на железе MPLS, то сделать mpls next-hop. Тогда L3 коммутация будет только на LER и только они будут светиться в трейсе.

[uxcr]

Это как?! Причем тут серые ip и окно tcp?!

path mtu discovery похоже имеется в виду, потенциально большинство tcp-соединений будут устанавливаться с минимальным mtu. Для фряхи это например net.inet.tcp.mssdflt (дефолт 536).

[GrandPr1de]

похоже это актуально с оборудованием использующем мту отличное от 1500

т.е. проблемы с тунелями только могут возникнуть

смотрю у себя ваершакром

хожу через один серый хоп - иду к хосту, к которому нужно пройти ещё два серых хопа внутри его сети - мсс 1460

 

для винды - Typically, an end system uses the "outgoing interface MTU" minus 40 as its reported MSS

 

но ниразу не видел проблем "медленный однопоточный аплоад"

однопоточные тесты типо спидтеста показывают скорость (если шейпер вырубить) на скорости порта

на гепоне через ону прокачивается порядка 700 мегабит с учетом двух серых хопов

так что ИМХО сломаный PMTU в мире с MTU=1500 не актуально, а кому надо - сам на тунелях MSS поправит

поэтому считаю бредом то что говорит влад11

Изменено 13 января, 2016 пользователем GrandPr1de

[fox_m]

похоже это актуально с оборудованием использующем мту отличное от 1500

т.е. проблемы с тунелями только могут возникнуть

смотрю у себя ваершакром

хожу через один серый хоп - иду к хосту, к которому нужно пройти ещё два серых хопа внутри его сети - мсс 1460

 

для винды - Typically, an end system uses the "outgoing interface MTU" minus 40 as its reported MSS

 

но ниразу не видел проблем "медленный однопоточный аплоад"

однопоточные тесты типо спидтеста показывают скорость (если шейпер вырубить) на скорости порта

на гепоне через ону прокачивается порядка 700 мегабит с учетом двух серых хопов

так что ИМХО сломаный PMTU в мире с MTU=1500 не актуально, а кому надо - сам на тунелях MSS поправит

поэтому считаю бредом то что говорит влад11

 

Да, походу так и есть. Если у оператора на сети везде MTU=1500, то опасаться наверно нечего.

[dr Tr0jan]

Хм, даже RFC 6752 (Issues with Private IP Addressing in the Internet) на эту тему есть.

[GrandPr1de]

похоже это актуально с оборудованием использующем мту отличное от 1500

т.е. проблемы с тунелями только могут возникнуть

смотрю у себя ваершакром

хожу через один серый хоп - иду к хосту, к которому нужно пройти ещё два серых хопа внутри его сети - мсс 1460

 

для винды - Typically, an end system uses the "outgoing interface MTU" minus 40 as its reported MSS

 

но ниразу не видел проблем "медленный однопоточный аплоад"

однопоточные тесты типо спидтеста показывают скорость (если шейпер вырубить) на скорости порта

на гепоне через ону прокачивается порядка 700 мегабит с учетом двух серых хопов

так что ИМХО сломаный PMTU в мире с MTU=1500 не актуально, а кому надо - сам на тунелях MSS поправит

поэтому считаю бредом то что говорит влад11

 

Да, походу так и есть. Если у оператора на сети везде MTU=1500, то опасаться наверно нечего.

 

мне очень сложно представить в 201х году мту меньше чем 1500 на промежуточном оборудовании