[ifndx]

Приветствую знатоки!

 

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

 

Есть распределенная сеть с филиалами. В каждом филиале стоит шлюз который поднимает 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.

 

Если нужно могу показать необходимые выводы из консоли.

[zi_rus]

Router6 видел сети Router10 через Router9

Вот это абсолютно естественно

 

трафик не ходил.

а это - нет. даже при всей кривости, был бы асимметричный рутинг и трафик бы ходил

 

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

[artmc]

А линк между r6 и r7 в какой зоне был?

[ifndx]

в 0.

Позже скину выводы для лучшего понимания.

[artmc]

Если в ноль , то "Router6 видел сети Router10 через Router9" это правильно с точки зрения OSPF :-) Так как всегда будет выбираться маршрут внутри зоны.

[helpdesk]

Как R6 видит R10 через R9, если R7-R9 линк погашен?

[zi_rus]

Как R6 видит R10 через R9, если R7-R9 линк погашен?

пакет трейсер, там и не такое может быть

[ifndx]

Добрался до консольки

 

вот результаты

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 не очень как мне кажется...

[Smoke]

У вас дожна работать без всяких костылей такая схема. 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 между ними

[SABRE]

Можно ли как-то сделать так чтобы все бранчи были в одной area1?

Можно - результат Вы видите. Фактически оно ничем не отличается от того что было раньше.

Решением может быть

Если вы хотите чтоб и с ASR трафик шел на SRX-HUB то подните сабинтефейс еще и в Area 1 между ними

Но все-же подумайте, какие цели Вы преследуете добавляя Area? Вполне логично засунуть каждый бранч в свою Area, а так вполне может получится 2/3/4 и т.д отдельных Area1 соединенных через 0 со всеми вытекающими.

[zi_rus]

И еще откуда появилась tottaly stub? Тут нужна просто stub area.

total stub фильтрует почти все lsa, обычный стаб ничего не даст, если там нет external маршрутов

 

А проблем там несколько

1) Почему Srx_165 продолжает использовать маршрут через ASR

2) Почему трафик не проходит через srx_162

3) Да, надо поднимать еще один саб в ареа 1

[Smoke]

И еще откуда появилась tottaly stub? Тут нужна просто stub area.

total stub фильтрует почти все lsa, обычный стаб ничего не даст, если там нет external маршрутов

 

эээ вы не заметили что у него 2 ABR ? Totally stub фильтрует LSA3 в area вместе с LSA4 и LSA5 и отдает дефолт. Получится что spoke роутер выберет исходящий ABR на основании коста дефолта, хотя очевидно что это будет не всегда оптимально для данной топологии. В этом случае можно использовать суммаризацию на ABR в сторону area 0. Хотя если то через какой ABR выходить пофиг то канеш так тоже должно работать.

[ifndx]

1) хотим именно totally stub чтоб присутствовал только дефолт+маршруты своей зоны.

 

 

2) получается мы для каждой такой area должны поднимать перемычку между хабами? тогда тоже не хорошо, тк хотели ограничивать кол-во роутеров в арии до 50.

в итоге будет 4-5 арий и столько же перемычек.

 

Придется каждый бранч в свою зону...есть ли какие-то рекомендации что не стоит поднимать больше 100 area? :)

[Smoke]

1) хотим именно totally stub чтоб присутствовал только дефолт+маршруты своей зоны.

 

 

2) получается мы для каждой такой area должны поднимать перемычку между хабами? тогда тоже не хорошо, тк хотели ограничивать кол-во роутеров в арии до 50.

в итоге будет 4-5 арий и столько же перемычек.

 

Придется каждый бранч в свою зону...есть ли какие-то рекомендации что не стоит поднимать больше 100 area? :)

Кроме самой area никто не знает о ее существовании. Информация о ней внутри LSA не распространяется. Речь скорее идет об ограничении area per abr - но здесь вы вряди получить какие-то рекомендации. 100 влюбом случае не проблема кмк

[zi_rus]

эээ вы не заметили что у него 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

[ifndx]

а вот iBGP это вариант.

Сделать ASR и SRX - RouteReflector, бранчи - клиенты.

 

Только придется делать сессии на лупбеках и они всё равно попадут все в OSPF...

[zi_rus]

Только придется делать сессии на лупбеках и они всё равно попадут все в OSPF...

Совершенно необязатально, более того, не обязательно именно именно iBGP использовать, ebgp тоже вариант. Тут вопрос только дизайна сети