[artplanet]

Пришла пора менять наш Nexus 5010 на Nexus 3064, в итоге сейчас вот такая схема:

http://owncloud.su/index.php/s/4IVWJd31XJ0pk4E

на точке обмена трафика стоит Arista 7124 - оттуда уходит несколько 10ок в сторону нашего Nexus 5010 в портчанеле

на аристе конфиг

interface Port-Channel5
  description Nexus
  switchport trunk allowed vlan 400,500,600
  switchport mode trunk

и физические порты

interface Ethernet22
  description VO.1490-1590
  load-interval 30
  channel-group 5 mode active

на нексусе 5010 тоже самое.

 

Дальше с nexus 5010 уходит портчанел(другой номер N1) с 2 из трех вланов в сторону 6500

 

Теперь собственно вопрос. На 6500 прописываем этот же портчанел с номером 1 и прописываем его в сторону Nexus 3064.

На самом Nexus 3064 создаем теже вланы, создаем тоже портчанел N1 и настраиваем его на порту который смотрит в сторону 6500

То есть создаем линк 4.

 

Линка N3 еще нету.

Собственно вопрос - в этот момент ничего не сломается? не начнет ли 6500 слать часть трафика в теже вланы в сторону Nexus 3064?

разумеется везде стоит rapid-pvst

 

И если ничего не сломается - дальше в планах сделать линк N3 с тем же портчанелом N5 и с теми же вланами. Что случиться когда все линки поднимуться, как пойдет трафик? равномерно через обе железки или нет?

 

Ну и последний вопрос - если после всего этого мы опустим линк N1 и N2 - заметят ли это клиенты - или там время перенастройки spanning-tree в микросекундах ?

Изменено 9 января, 2017 пользователем artplanet

[artplanet]

разумеется все вланы L2. С одной стороны int vlan терминируется у нас на 6500, а вторая сторона - уже у наших аплинков на их оборудовании.

[artplanet]

решили сделать тест с ненужным номером влана

теперь на 6500 появилось:

Po1          Nexus              connected    trunk      a-full    10G 
Po1A                            connected    trunk      a-full    10G 

но вроде все работает и не падает.

 

хотя на сколько я понимаю:

VO.bb#show spanning-tree vlan 8 

VLAN0008
 Spanning tree enabled protocol rstp
 Root ID    Priority    32776
            Address     0005.9b20.697c
            Cost        1
            Port        1665 (Port-channel1)
            Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

 Bridge ID  Priority    32776  (priority 32768 sys-id-ext 8)
            Address     001d.7172.5840
            Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
            Aging Time 480

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po1                 Root FWD 1         128.1665 P2p 
Po1A                Desg FWD 2         128.1673 P2p 

стоит изменить вес на физическом порту - где PO1a - так всё сломается.

[Saab95]

Проще залить копию конфига и физически поменять оборудование, так будет и быстрее, и проще. Простой в пару секунд не страшен. С подобными настройками можно что-то логически закольцевать в сети и простой услуги будет уже в пределах 10 и более секунд.

[SergeiK]

Если перерыв сервиса критичен - хорошо бы в лабе откатать, конечно.

 

По rstp можно приоритеты правильные выставить заранее, но причин, почему должно все поломаться мне не видно.

[artplanet]

Ну вот тоже думаю о лабе - или о варианте с тестовым вланом. Спасибо тем кто откликнулся. Просто думал тут есть люди которые меняли свитчи.

А перерыв делать нельзя. У нас 60-70% клиентов - игровые сервера - где лаг на 1-2 секунды просто критичен до не узнаваемости.

[SergeiK]

Ну вот тоже думаю о лабе - или о варианте с тестовым вланом. Спасибо тем кто откликнулся. Просто думал тут есть люди которые меняли свитчи.

А перерыв делать нельзя. У нас 60-70% клиентов - игровые сервера - где лаг на 1-2 секунды просто критичен до не узнаваемости.

1-2 секунды вы вполне по rstp можете получить, миллисекунды для L2 - пожалуй, это утопия. Да и для L3 тоже.

А объявить работы на сети и плановый перерыв на 5-10 минут - не-е? Не катит? Заодно все проверить, и ему возможность откатиться назад без ущерба для SLA.

[vlad11]

Выбирается промежуток времени с наименьшей нагрузкой и делается пробная миграция.

[applx]

на 3064 меняем STP priority для тестового влана ниже чем на 5010 и ждем перестройку корня дерева что довольно быстро но измеряется в секундах

[YuryD]

А объявить работы на сети и плановый перерыв на 5-10 минут - не-е? Не катит? Заодно все проверить, и ему возможность откатиться назад без ущерба для SLA.

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

 

на 3064 меняем STP priority для тестового влана ниже чем на 5010 и ждем перестройку корня дерева что довольно быстро но измеряется в секундах

Для pvst от киско - первое построение дерева - пара секунд, с тупежом даже управления. Когда все маки разлетелись по всем - миллисекунды при ломании какого-либо линка. Пинги - не выпадают, просто могут пара подпрыгнуть до 10мсек. Но или я неправильно курил pvst, паразитный трафик в сильно многосвязном кольце - около мбита на 1Г портах, даже если кольцо не перестраивается...

[applx]

у нашего товарища колечко, тестировать можно с определенным тестовым VLAN. как только в влане будет LOOP один из линков (в случае с PVST+ VLAN) заблочится на 6500, надо вывести ROOT на 3064 чтоб заблочился VLAN на порту к 5010. при отвале линка RSTP очень быстр, а тут замена (election) ROOT'a

Изменено 10 января, 2017 пользователем applx

[Asco]

А просто кольцо порвать? Не?

[artplanet]

я думаю пойдем более простым способом - на нексус 3064 создаем нужные портчанелы но без вланов нужных, поднимаем все линки.

Далее кладем плавно BGP сессию с одним аплинком - ждем минут 10ть. Потом этот влан убираем на 5010 - и переносим на 3064. И поднимаем bgp сессию.

И так 7м раз. В ночное время.