ifndx Posted November 26, 2014 · Report post Приветствую знатоки! Помогите разобраться с казалось бы тривиальной задачей. Есть распределенная сеть с филиалами. В каждом филиале стоит шлюз который поднимает GREoIPSEC + OSPF с двумя центральными хабами. Хочется разделить это всё на area. Можно ли каждый филиал (транзитные линки от хабов+сети филиалов) засунуть допустим в area1 ( totally stub), а хабы и оставить в area0? При попытке поднять это получилось так что филиалы в area1 перестали видеть сети удаленных офисов из area0 ( пока еще не переведенных). Было нечно похожее что Router6 видел сети Router10 через Router9, судя по выводам show route и естественно трафик не ходил. Если не ошибаюсь в RFC есть что-то подобное на тему анонсов обратно в зону 0 из non-backnone area. Summary link advertisements are originated by area border routers. The precise summary routes to advertise into an area are determined by examining the routing table structure (see Section 11) in accordance with the algorithm described below. Note that only intra-area routes are advertised into the backbone, while both intra-area and inter-area routes are advertised into the other areas. Если нужно могу показать необходимые выводы из консоли. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted November 26, 2014 · Report post Router6 видел сети Router10 через Router9 Вот это абсолютно естественно трафик не ходил. а это - нет. даже при всей кривости, был бы асимметричный рутинг и трафик бы ходил Даввайте остановимся на чем-то одном, или кривую схему из пакет трейсера разбирать или таки про реальную сеть поговорим (ее отрисовать сложнее, но зато глюков меньше чем в этом симуляторе) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
artmc Posted November 27, 2014 · Report post А линк между r6 и r7 в какой зоне был? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ifndx Posted November 27, 2014 · Report post в 0. Позже скину выводы для лучшего понимания. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
artmc Posted November 27, 2014 · Report post Если в ноль , то "Router6 видел сети Router10 через Router9" это правильно с точки зрения OSPF :-) Так как всегда будет выбираться маршрут внутри зоны. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
helpdesk Posted November 27, 2014 · Report post Как R6 видит R10 через R9, если R7-R9 линк погашен? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted November 27, 2014 · Report post Как R6 видит R10 через R9, если R7-R9 линк погашен? пакет трейсер, там и не такое может быть Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ifndx Posted December 1, 2014 · Report post Добрался до консольки вот результаты SRX_162> show ospf neighbor Address Interface State ID Pri Dead 10.0.3.65 st0.1 Full 10.0.1.50 1 38 10.0.4.145 st0.2 Full 10.11.220.249 128 33 SRX_215> show ospf neighbor Address Interface State ID Pri Dead 10.0.4.153 st0.1 Full 10.0.1.50 1 32 10.0.4.149 st0.2 Full 10.11.220.249 128 35 SRX_162> show configuration protocols ospf area 0.0.0.1 { stub; interface vlan.101; interface st0.1; interface lo0.0; interface st0.2; } SRX_215> show configuration protocols ospf area 0.0.0.1 { stub; interface vlan.101 interface st0.1; interface lo0.0; interface st0.2; } ASR1002#sh run int tun41 Building configuration... Current configuration : 275 bytes ! interface Tunnel41 description To_SRX_162 ip address 10.0.3.65 255.255.255.252 ip mtu 1350 ip flow ingress ip flow egress tunnel source XXXXX tunnel mode ipsec ipv4 tunnel destination XXXXX tunnel protection ipsec profile Juniper end ASR1002#sh run int tun105 Building configuration... Current configuration : 284 bytes ! interface Tunnel105 description TO_SRX_215 ip address 10.0.4.153 255.255.255.252 ip mtu 1350 ip flow ingress ip flow egress tunnel source XXXXXXXXXX tunnel mode ipsec ipv4 tunnel destination XXXXXXXXXXX tunnel protection ipsec profile Juniper end ASR1002#sh ip route 10.162.101.254 Routing entry for 10.162.101.0/24 Known via "ospf 1", distance 110, metric 1001, type intra area Last update from 10.0.3.66 on Tunnel41, 2d16h ago Routing Descriptor Blocks: * 10.0.3.66, from 10.0.1.65, 2d16h ago, via Tunnel41 Route metric is 1001, traffic share count is 1 ASR1002#sh ip route 10.215.101.254 Routing entry for 10.215.101.0/24 Known via "ospf 1", distance 110, metric 1000, type intra area Last update from 10.0.4.154 on Tunnel105, 2d20h ago Routing Descriptor Blocks: * 10.0.4.154, from 10.0.1.131, 2d20h ago, via Tunnel105 Route metric is 1000, traffic share count is 1 ASR1002# SRX_HUB> show route 10.162.101.254 inet.0: 510 destinations, 530 routes (510 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.162.101.0/24 *[OSPF/10] 00:28:14, metric 2 > via st0.19 SRX_HUB> show route 10.215.101.254 inet.0: 510 destinations, 530 routes (510 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.215.101.0/24 *[OSPF/10] 00:28:17, metric 1 > via st0.20 SRX_HUB> На этом этапе от двух бранчей поставлено по 2 туннеля до 2х хабов. SRX_165> traceroute 10.215.101.254 source 10.165.101.254 traceroute to 10.215.101.254 (10.215.101.254) from 10.165.101.254, 30 hops max, 40 byte packets 1 10.0.3.85 (10.0.3.85) 9.302 ms 10.318 ms 8.775 ms 2 10.215.101.254 (10.215.101.254) 18.006 ms 20.016 ms 16.712 ms SRX_165> ping 10.215.101.254 source 10.165.101.254 PING 10.215.101.254 (10.215.101.254): 56 data bytes 64 bytes from 10.215.101.254: icmp_seq=0 ttl=63 time=16.284 ms 64 bytes from 10.215.101.254: icmp_seq=1 ttl=63 time=28.916 ms ^C --- 10.215.101.254 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 16.284/22.600/28.916/6.316 ms Кладем туннель от SRX-215 до ASR ( выделено на рисунке стрелочкой) interface Tunnel105 description TO_SRX_215 ip address 10.0.4.153 255.255.255.252 ip mtu 1350 ip flow ingress ip flow egress shutdown tunnel source XXXXXXXXXX tunnel mode ipsec ipv4 tunnel destination XXXXXXXXXXX tunnel protection ipsec profile Juniper end Пинги рвутся и затыкается всё на ASR, куда приходит туннель от SRX_165 ( area0) SRX_165> ping 10.215.101.254 source 10.165.101.254 PING 10.215.101.254 (10.215.101.254): 56 data bytes 64 bytes from 10.215.101.254: icmp_seq=0 ttl=62 time=46.934 ms 64 bytes from 10.215.101.254: icmp_seq=1 ttl=62 time=15.033 ms 64 bytes from 10.215.101.254: icmp_seq=2 ttl=62 time=14.748 ms 64 bytes from 10.215.101.254: icmp_seq=3 ttl=62 time=25.383 ms ^C --- 10.215.101.254 ping statistics --- 8 packets transmitted, 4 packets received, 50% packet loss round-trip min/avg/max/stddev = 14.748/25.524/46.934/13.082 ms SRX_165> traceroute 10.215.101.254 source 10.165.101.254 traceroute to 10.215.101.254 (10.215.101.254) from 10.165.101.254, 30 hops max, 40 byte packets 1 10.0.3.85 (10.0.3.85) 19.646 ms 10.346 ms 11.801 ms ^C SRX_165> на ASR выбирается маршрут на SRX_162 тк это intra-area маршрут из AREA1. Хотя нужно идти транзитом через SRX-HUB (AREA0>AREA1) ASR1002#sh ip route 10.215.101.254 Routing entry for 10.215.101.254/24 Known via "ospf 1", distance 110, metric 1002, type intra area Last update from 10.0.3.66 on Tunnel41, 00:00:28 ago Routing Descriptor Blocks: * 10.0.3.66, from 10.0.1.131, 00:00:28 ago, via Tunnel41 Route metric is 1002, traffic share count is 1 ASR1002# interface Tunnel41 description To_SRX_162 ip address 10.0.3.65 255.255.255.252 ip mtu 1350 ip flow ingress ip flow egress tunnel source XXXXX tunnel mode ipsec ipv4 tunnel destination XXXXX tunnel protection ipsec profile Juniper end Можно ли как-то сделать так чтобы все бранчи были в одной area1? решение засовывать каждый бранч в свою area не очень как мне кажется... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Smoke Posted December 1, 2014 · Report post У вас дожна работать без всяких костылей такая схема. SRX165 выбирает маршрут к 10.215.101.254 на основании суммарной метрики cost from SRX165 to ABR + cost from ABR to 10.215.101.254. Отсюда вывод нужно смотреть как видит SRX165 LSA3 10.215.101.254 до аварии и после. show ospf database netsummary X.X.X.X. И еще откуда появилась tottaly stub? Тут нужна просто stub area. Если вы хотите чтоб и с ASR трафик шел на SRX-HUB то подните сабинтефейс еще и в Area 1 между ними Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SABRE Posted December 1, 2014 · Report post Можно ли как-то сделать так чтобы все бранчи были в одной area1? Можно - результат Вы видите. Фактически оно ничем не отличается от того что было раньше. Решением может быть Если вы хотите чтоб и с ASR трафик шел на SRX-HUB то подните сабинтефейс еще и в Area 1 между ними Но все-же подумайте, какие цели Вы преследуете добавляя Area? Вполне логично засунуть каждый бранч в свою Area, а так вполне может получится 2/3/4 и т.д отдельных Area1 соединенных через 0 со всеми вытекающими. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted December 1, 2014 · Report post И еще откуда появилась tottaly stub? Тут нужна просто stub area. total stub фильтрует почти все lsa, обычный стаб ничего не даст, если там нет external маршрутов А проблем там несколько 1) Почему Srx_165 продолжает использовать маршрут через ASR 2) Почему трафик не проходит через srx_162 3) Да, надо поднимать еще один саб в ареа 1 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Smoke Posted December 1, 2014 · Report post И еще откуда появилась tottaly stub? Тут нужна просто stub area. total stub фильтрует почти все lsa, обычный стаб ничего не даст, если там нет external маршрутов эээ вы не заметили что у него 2 ABR ? Totally stub фильтрует LSA3 в area вместе с LSA4 и LSA5 и отдает дефолт. Получится что spoke роутер выберет исходящий ABR на основании коста дефолта, хотя очевидно что это будет не всегда оптимально для данной топологии. В этом случае можно использовать суммаризацию на ABR в сторону area 0. Хотя если то через какой ABR выходить пофиг то канеш так тоже должно работать. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ifndx Posted December 1, 2014 · Report post 1) хотим именно totally stub чтоб присутствовал только дефолт+маршруты своей зоны. 2) получается мы для каждой такой area должны поднимать перемычку между хабами? тогда тоже не хорошо, тк хотели ограничивать кол-во роутеров в арии до 50. в итоге будет 4-5 арий и столько же перемычек. Придется каждый бранч в свою зону...есть ли какие-то рекомендации что не стоит поднимать больше 100 area? :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Smoke Posted December 1, 2014 · Report post 1) хотим именно totally stub чтоб присутствовал только дефолт+маршруты своей зоны. 2) получается мы для каждой такой area должны поднимать перемычку между хабами? тогда тоже не хорошо, тк хотели ограничивать кол-во роутеров в арии до 50. в итоге будет 4-5 арий и столько же перемычек. Придется каждый бранч в свою зону...есть ли какие-то рекомендации что не стоит поднимать больше 100 area? :) Кроме самой area никто не знает о ее существовании. Информация о ней внутри LSA не распространяется. Речь скорее идет об ограничении area per abr - но здесь вы вряди получить какие-то рекомендации. 100 влюбом случае не проблема кмк Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted December 1, 2014 · Report post эээ вы не заметили что у него 2 ABR ? Totally stub фильтрует LSA3 в area вместе с LSA4 и LSA5 и отдает дефолт. Получится что spoke роутер выберет исходящий ABR на основании коста дефолта, хотя очевидно что это будет не всегда оптимально для данной топологии. В этом случае можно использовать суммаризацию на ABR в сторону area 0. Хотя если то через какой ABR выходить пофиг то канеш так тоже должно работать. если метрики настроены симметрично, то и трафик будет ходить симметрично, все остальное не проблема, оптимальное движение трафика определется метриками есть ли какие-то рекомендации что не стоит поднимать больше 100 area? каждая зона это дополнительный расход памяти, LSA 1/2 из одной зоны будут копироваться в другие зоны как LSA 3 (но в случае totally stub все будет дублироваться только в А0, так что не такая большая проблема, вот без стаба каждая LSA2 создавала бы в базе сотню LSA3, а это расход памяти и цпу), количество зон это проблема только АБР 1) хотим именно totally stub чтоб присутствовал только дефолт+маршруты своей зоны. 2) получается мы для каждой такой area должны поднимать перемычку между хабами? тогда тоже не хорошо, тк хотели ограничивать кол-во роутеров в арии до 50. в итоге будет 4-5 арий и столько же перемычек. ну можно еще подумать про IS-IS, там лучше условия по количеству маршрутизаторов в зоне, или BGP Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ifndx Posted December 2, 2014 · Report post а вот iBGP это вариант. Сделать ASR и SRX - RouteReflector, бранчи - клиенты. Только придется делать сессии на лупбеках и они всё равно попадут все в OSPF... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted December 2, 2014 · Report post Только придется делать сессии на лупбеках и они всё равно попадут все в OSPF... Совершенно необязатально, более того, не обязательно именно именно iBGP использовать, ebgp тоже вариант. Тут вопрос только дизайна сети Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...