Добрый день, коллеги.
У меня такой интересный случай произошел.
Имеется циска 3845 (провайдер) + циска 3750 (Внутрисетевой гетэвэй), сервер нетфлоу и еще несколько серверов в сети.
циска отправляет в нетфлоу данные на сервер нетфлоу. Но я сделал tcpdump на других серверах в этой сети и обнаружил, что иногда, пакеты предназначенные для сервера нетфлоу транслируются на все адреса в этой сети, при этом пакеты маркируются как предназначенные для сервера нетфлоу.
не пойму с чем это может быть связано. с других цисок тоже нетфлоу идет на все адреса в сети. Где искать корни проблемы?
> Добрый день, коллеги.
> У меня такой интересный случай произошел.
> Имеется циска 3845 (провайдер) + циска 3750 (Внутрисетевой гетэвэй), сервер нетфлоу и
> еще несколько серверов в сети.
> циска отправляет в нетфлоу данные на сервер нетфлоу. Но я сделал tcpdump
> на других серверах в этой сети и обнаружил, что иногда, пакеты
> предназначенные для сервера нетфлоу транслируются на все адреса в этой сети,
> при этом пакеты маркируются как предназначенные для сервера нетфлоу.
> не пойму с чем это может быть связано. с других цисок тоже
> нетфлоу идет на все адреса в сети. Где искать корни проблемы?Во времени жизни записи MAC-а в таблице коммутатора.
И в протоколе ethernet :)
>[оверквотинг удален]
>> Имеется циска 3845 (провайдер) + циска 3750 (Внутрисетевой гетэвэй), сервер нетфлоу и
>> еще несколько серверов в сети.
>> циска отправляет в нетфлоу данные на сервер нетфлоу. Но я сделал tcpdump
>> на других серверах в этой сети и обнаружил, что иногда, пакеты
>> предназначенные для сервера нетфлоу транслируются на все адреса в этой сети,
>> при этом пакеты маркируются как предназначенные для сервера нетфлоу.
>> не пойму с чем это может быть связано. с других цисок тоже
>> нетфлоу идет на все адреса в сети. Где искать корни проблемы?
> Во времени жизни записи MAC-а в таблице коммутатора.
> И в протоколе ethernet :)тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе, а рассылается только в сети, в которой находится сервер нетфлоу
>[оверквотинг удален]
>>> циска отправляет в нетфлоу данные на сервер нетфлоу. Но я сделал tcpdump
>>> на других серверах в этой сети и обнаружил, что иногда, пакеты
>>> предназначенные для сервера нетфлоу транслируются на все адреса в этой сети,
>>> при этом пакеты маркируются как предназначенные для сервера нетфлоу.
>>> не пойму с чем это может быть связано. с других цисок тоже
>>> нетфлоу идет на все адреса в сети. Где искать корни проблемы?
>> Во времени жизни записи MAC-а в таблице коммутатора.
>> И в протоколе ethernet :)
> тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе,
> а рассылается только в сети, в которой находится сервер нетфлоуРасслка идет в одном vlan-е - только и всего...
>[оверквотинг удален]
>>>> на других серверах в этой сети и обнаружил, что иногда, пакеты
>>>> предназначенные для сервера нетфлоу транслируются на все адреса в этой сети,
>>>> при этом пакеты маркируются как предназначенные для сервера нетфлоу.
>>>> не пойму с чем это может быть связано. с других цисок тоже
>>>> нетфлоу идет на все адреса в сети. Где искать корни проблемы?
>>> Во времени жизни записи MAC-а в таблице коммутатора.
>>> И в протоколе ethernet :)
>> тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе,
>> а рассылается только в сети, в которой находится сервер нетфлоу
> Расслка идет в одном vlan-е - только и всего...Нормальные коммутаторы ведут таблицу
port-vlan-mac.
>[оверквотинг удален]
>>>>> при этом пакеты маркируются как предназначенные для сервера нетфлоу.
>>>>> не пойму с чем это может быть связано. с других цисок тоже
>>>>> нетфлоу идет на все адреса в сети. Где искать корни проблемы?
>>>> Во времени жизни записи MAC-а в таблице коммутатора.
>>>> И в протоколе ethernet :)
>>> тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе,
>>> а рассылается только в сети, в которой находится сервер нетфлоу
>> Расслка идет в одном vlan-е - только и всего...
> Нормальные коммутаторы ведут таблицу
> port-vlan-mac.ну например так, я посмотрел настройки, время жизни 4 минуты. возможно примерно с таким периодом иногда происходит широковещательная рассылка. но всё равно это же не нормально.. иногда это вешает сеть на несколько секунд.. я так понимаю что увеличение времени жизни арп не поможет полностью решить, поможет только время растянуть. а статическая запись арп исключено
>[оверквотинг удален]
>>>> тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе,
>>>> а рассылается только в сети, в которой находится сервер нетфлоу
>>> Расслка идет в одном vlan-е - только и всего...
>> Нормальные коммутаторы ведут таблицу
>> port-vlan-mac.
> ну например так, я посмотрел настройки, время жизни 4 минуты. возможно примерно
> с таким периодом иногда происходит широковещательная рассылка. но всё равно это
> же не нормально.. иногда это вешает сеть на несколько секунд.. я
> так понимаю что увеличение времени жизни арп не поможет полностью решить,
> поможет только время растянуть. а статическая запись арп исключено"иногда это вешает сеть на несколько секунд.. "
ЭТО не может вешать сеть на несколько секунд, т.к. это НОРМАЛЬНОЕ ПОВЕДЕНИЕ ЛЮБОГО КОММУТАТОРА!
Ищите причины зависона...
Как вариант - с некоторыми длинками есть проблема "потери" MAC-ов.
Еще как вариант - в вашей сети слишком много MAC-ов, и в таблицу коммутатора они просто не помещаются.Запустите tcpdump с ключем -e и посмотрите какие mac-и в этом фрейме...
>[оверквотинг удален]
>> так понимаю что увеличение времени жизни арп не поможет полностью решить,
>> поможет только время растянуть. а статическая запись арп исключено
> "иногда это вешает сеть на несколько секунд.. "
> ЭТО не может вешать сеть на несколько секунд, т.к. это НОРМАЛЬНОЕ ПОВЕДЕНИЕ
> ЛЮБОГО КОММУТАТОРА!
> Ищите причины зависона...
> Как вариант - с некоторыми длинками есть проблема "потери" MAC-ов.
> Еще как вариант - в вашей сети слишком много MAC-ов, и в
> таблицу коммутатора они просто не помещаются.
> Запустите tcpdump с ключем -e и посмотрите какие mac-и в этом фрейме...Посмотрел, mac-адреса соответствуют хостам. Но все равно пакеты вещаются на другие сервера в сети, и даже судя по всему не на все сразу. Сейчас смотрел, в tcpdump появляются еще другие пакеты с других серверов предназначенные для других серверов, не пойму в чем дело..
20:39:01.691962 00:13:c4:86:39:c4 (oui Unknown) > 32:36:af:69:a1:82 (oui Unknown), ethertype IPv4 (0x0800), length 1506: 172.17.17.1.54679 > 192.168.5.113.palace-5: UDP, length 1464
Еще частенько выпадает такая:
20:48:44.068809 00:13:c4:86:92:11 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3, length 60: LLC, dsap STP (0x42), ssap STP (0x42), cmd 0x03: 802.1d unknown version
stp на свитчах L3 включен
>[оверквотинг удален]
>> Как вариант - с некоторыми длинками есть проблема "потери" MAC-ов.
>> Еще как вариант - в вашей сети слишком много MAC-ов, и в
>> таблицу коммутатора они просто не помещаются.
>> Запустите tcpdump с ключем -e и посмотрите какие mac-и в этом фрейме...
> Посмотрел, mac-адреса соответствуют хостам. Но все равно пакеты вещаются на другие сервера
> в сети, и даже судя по всему не на все сразу.
> Сейчас смотрел, в tcpdump появляются еще другие пакеты с других серверов
> предназначенные для других серверов, не пойму в чем дело..
> 20:39:01.691962 00:13:c4:86:39:c4 (oui Unknown) > 32:36:af:69:a1:82 (oui Unknown), ethertype
> IPv4 (0x0800), length 1506: 172.17.17.1.54679 > 192.168.5.113.palace-5: UDP, length 1464схемку нарисуйте!
сервер - [свич]-[свич]-[L3 свич] - желательно с моделями и т.д.
а вообще АБСОЛЮЬНО НОРМАЛЬНОЕ ПОВЕДЕНИЕ СЕТИ.
Если есть зависоны на несколько секунд - то нужно локализовать проблему...
Зависоны на уровне vlan-а? свича? нескольких свичей? одного сервера?Пока все что вы изложили - абсолютно нормальное поведение ethernet сети и не должно вызывать простоев/зависонов.
> Еще частенько выпадает такая:
> 20:48:44.068809 00:13:c4:86:92:11 (oui Unknown) > 01:80:c2:00:00:00 (oui Unknown), 802.3,
> length 60: LLC, dsap STP (0x42), ssap STP (0x42), cmd 0x03:
> 802.1d unknown version
> stp на свитчах L3 включенНу так если stp включен - то в чем проблема?
Кстати когда tcpdump делал, по макадресам видно, что пакет посылает не циска 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней 5- тому влану, в который и идет рассылка..
> Кстати когда tcpdump делал, по макадресам видно, что пакет посылает не циска
> 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней
> 5- тому влану, в который и идет рассылка..И что вас в этом настораживает???
Вот если бы MAC принадлежал 3845 - было бы удивительно...
>> Кстати когда tcpdump делал, по макадресам видно, что пакет посылает не циска
>> 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней
>> 5- тому влану, в который и идет рассылка..
> И что вас в этом настораживает???
> Вот если бы MAC принадлежал 3845 - было бы удивительно...настораживает, что сеть падает, а причины не известны)) логов нет, а дебаг включить боюсь, так как cpu и так на пределе
>>> Кстати когда tcpdump делал, по макадресам видно, что пакет посылает не циска
>>> 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней
>>> 5- тому влану, в который и идет рассылка..
>> И что вас в этом настораживает???
>> Вот если бы MAC принадлежал 3845 - было бы удивительно...
> настораживает, что сеть падает, а причины не известны)) логов нет, а дебаг
> включить боюсь, так как cpu и так на пределеСИМПТОМЫ ПАДЕНИЯ КАКИЕ?? что падает-то? вся сеть со всеми маршрутизаторами/коммутаторами? один VLAN? один сегмент? один сервак?
Так может именно в этом и причина - в CPU на пределе???
И чем же он занят?
>[оверквотинг удален]
>>>> 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней
>>>> 5- тому влану, в который и идет рассылка..
>>> И что вас в этом настораживает???
>>> Вот если бы MAC принадлежал 3845 - было бы удивительно...
>> настораживает, что сеть падает, а причины не известны)) логов нет, а дебаг
>> включить боюсь, так как cpu и так на пределе
> СИМПТОМЫ ПАДЕНИЯ КАКИЕ?? что падает-то? вся сеть со всеми маршрутизаторами/коммутаторами?
> один VLAN? один сегмент? один сервак?
> Так может именно в этом и причина - в CPU на пределе???
> И чем же он занят?симптомы, это то, что нагиос показывает, что не доступны все сетевые хосты в сети.
со всеми маршрутизаторами и коммутаторами.
врядли причина в CPU, тогда бы в логах была ошибка CPU.
Этот 3750 является гетэвэейм для множества вланов
>[оверквотинг удален]
>>> включить боюсь, так как cpu и так на пределе
>> СИМПТОМЫ ПАДЕНИЯ КАКИЕ?? что падает-то? вся сеть со всеми маршрутизаторами/коммутаторами?
>> один VLAN? один сегмент? один сервак?
>> Так может именно в этом и причина - в CPU на пределе???
>> И чем же он занят?
> симптомы, это то, что нагиос показывает, что не доступны все сетевые хосты
> в сети.
> со всеми маршрутизаторами и коммутаторами.
> врядли причина в CPU, тогда бы в логах была ошибка CPU.
> Этот 3750 является гетэвэейм для множества влановДык нагиос - он работает-то на СЕРВАКЕ и я бы начал с диагностики сервака...
например банально с другого сервака пингать шлюз+нагиос и посмотреть результат, если в момент "пропадания" с другого сервака шлюз пингуется, а нагиос нет - вывод будет однозначным :)
>[оверквотинг удален]
>> симптомы, это то, что нагиос показывает, что не доступны все сетевые хосты
>> в сети.
>> со всеми маршрутизаторами и коммутаторами.
>> врядли причина в CPU, тогда бы в логах была ошибка CPU.
>> Этот 3750 является гетэвэейм для множества вланов
> Дык нагиос - он работает-то на СЕРВАКЕ и я бы начал с
> диагностики сервака...
> например банально с другого сервака пингать шлюз+нагиос и посмотреть результат, если в
> момент "пропадания" с другого сервака шлюз пингуется, а нагиос нет -
> вывод будет однозначным :)Я конечно думал над этим, но дело в том, что когда это происходит, глючит не только нагиос, но и пакеты с других серверов теряются, и на циске 3750 sla отваливается)
что то слишком часто идут эти широковещательные пакеты, что самое странное, то что не на все сервера доходят из этой сети..
И мне кажется, что широковещательные пакеты идут скорее всего не из за времени arp.
так как идут в разнобой, не зависимо от текущих настроек 4 мин..
>[оверквотинг удален]
>> Дык нагиос - он работает-то на СЕРВАКЕ и я бы начал с
>> диагностики сервака...
>> например банально с другого сервака пингать шлюз+нагиос и посмотреть результат, если в
>> момент "пропадания" с другого сервака шлюз пингуется, а нагиос нет -
>> вывод будет однозначным :)
> Я конечно думал над этим, но дело в том, что когда это
> происходит, глючит не только нагиос, но и пакеты с других серверов
> теряются, и на циске 3750 sla отваливается)
> что то слишком часто идут эти широковещательные пакеты, что самое странное, то
> что не на все сервера доходят из этой сети..Схема сети какая? какие железки где стоят? или все воткнуто в 3750??
как один из вариантов:
These are the IP limitations:•(Catalyst 3750 or 3560 switches) The switch does not create an adjacent table entry when the ARP timeout value is 15 seconds and the ARP request times out. The workaround is to not set an ARP timeout value lower than 120 seconds. (CSCea21674)
или
This is an Address Resolution Protocol limitation:
•The switch might place a port in an error-disabled state due to an Address Resolution Protocol (ARP) rate limit exception even when the ARP traffic on the port is not exceeding the configured limit. This could happen when the burst interval setting is 1 second, the default.
The workaround is to set the burst interval to more than 1 second. We recommend setting the burst interval to 3 seconds even if you are not experiencing this problem.(CSCse06827))
Но это все тыканье пальцем в небо.
Если CPU сильно нагружен - чем??? и сильно - это насколько??
sh proc cpu hist
>[оверквотинг удален]
> an Address Resolution Protocol (ARP) rate limit exception even when the
> ARP traffic on the port is not exceeding the configured limit.
> This could happen when the burst interval setting is 1 second,
> the default.
> The workaround is to set the burst interval to more than 1
> second. We recommend setting the burst interval to 3 seconds even
> if you are not experiencing this problem.(CSCse06827))
> Но это все тыканье пальцем в небо.
> Если CPU сильно нагружен - чем??? и сильно - это насколько??
> sh proc cpu hist1254233324332222442522455532212223213332234222233993242144222461243734
9435750634976287119965063412076857898294764866949990558877932018325814
100 **
90 **
80 ** *
70 ** *
60 * * ** * *
50 ** * *** ** * ** * *
40 ** * * *** ** * **** * * * ** *** * ** ** *** *
30 ****** **** ************* ***** *** *************** *** ** *****
20 **********************************************************************
10 ######################################################################
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%Схема такая:
______ ______ |----- Vlan2
| 3845 |----------| 3750 |---------|----- Vlan...
Provider Gateway |----- Vlan5 (Куда идут широковещательные пакеты)Так же в 3750 втыкаются xen-серверы. И Vlan5 распределяется по виртуалкам. Нетфлоу тоже виртуальный сервер. Но рассылка идет как на виртуальные, так и на физические машины
Описание проблемы очень похоже на статью http://ru.wikipedia.org/wiki/Широковещательный_шторм
Через этот 3750 идет вся внутренняя сеть ~около 700-1000 хостов. Если включить дебаг, то сиська вешается, уже пробовали.
как порекамендовали выше, поставил arp-timeout 3
в тспдамп пропали эти эти ошибки, но редко стало появляться такое
13:59:14.451401 arp who-has 192.168.5.113 tell gateway
> как порекамендовали выше, поставил arp-timeout 3
> в тспдамп пропали эти эти ошибки, но редко стало появляться такое
> 13:59:14.451401 arp who-has 192.168.5.113 tell gatewayКороче в 2-х словах:
свич ведет 2 таблицы, для arp(IP+mac), и mac (port+vlan+mac), у каждой есть свой таймаут, у вас был для arp скорее всего таймаут больше, чем для mac, в результате l3 част ь свича mac нужный еще помнит, а L2 уже нет. поэтому свич вел себя совершенно нормально, когда L2 "забывал" мас вашего сервака - он выпуливал фреймы во все порты с разрешенным vlan-ом 5, как только в таблице снова появлялся mac сервера - все снова становилось на место.
Теперь L3 "забывает" mac быстрее, чем L2, и спрашивает егоarp who-has 192.168.5.113 tell gateway
А ответ сервера вызывает обновление времени жизни MAC-а в L2 таблице...
Вполне логично, что
arp who-has 192.168.5.113 tell gateway
посылается на бродкаст, и он попадает НА ВСЕ УЗЛЫ в vlan 5.
просто ваш 192.168.5.113 очень редко выпуливает от себя что-то наружу, вот и получается такая ерунда.
Как вариант у сервака с ip-ом 192.168.5.113 2 интерфейса, и основное взаимодействие с ним происходит по 2-му интерфейсу.
>[оверквотинг удален]
> Теперь L3 "забывает" mac быстрее, чем L2, и спрашивает его
> arp who-has 192.168.5.113 tell gateway
> А ответ сервера вызывает обновление времени жизни MAC-а в L2 таблице...
> Вполне логично, что
> arp who-has 192.168.5.113 tell gateway
> посылается на бродкаст, и он попадает НА ВСЕ УЗЛЫ в vlan 5.
> просто ваш 192.168.5.113 очень редко выпуливает от себя что-то наружу, вот и
> получается такая ерунда.
> Как вариант у сервака с ip-ом 192.168.5.113 2 интерфейса, и основное взаимодействие
> с ним происходит по 2-му интерфейсу.В принципе логично, попробую промониторить.
вот еще.
сделал clear arp-cache interface vlan 5
тспдамп молчал везде ровно 5 минут
потом снова посыпались пакеты.
сделал опять clear arp-cache interface vlan 5
пакеты остановились. переодичность повторилась два раза.
попробую поставить arp timeout 300
только не понятно, что ровно через 5 минут происходит, что гетэвый забывает куда слать пакет, при этом запись в sh ip arp присутствуетна 192.168.5.113 один интерфейс.
Свитч L2 отсутствует в сети. Если только конечно в роли L2 не выступает xen сервер, распределяющий vlan по виртуалкам
Поставил arp timeout 300 на пятый влан. Ни одного пакета за 10 минут не проскочило, надеюсь на этом проблема будет решена =) еще помониторюРезультат мониторинга показал, что иногда этот сбой происходит раньше 5 минут, и пакеты начинают сыпаться пока не обнулится снова таблица.
В таблице 400 мак адресов, а циска гарантирует работоспособность таблицы с 4000 макадресов
> Поставил arp timeout 300 на пятый влан. Ни одного пакета за 10
> минут не проскочило, надеюсь на этом проблема будет решена =) еще
> помониторю
> Результат мониторинга показал, что иногда этот сбой происходит раньше 5 минут, и
> пакеты начинают сыпаться пока не обнулится снова таблица.
> В таблице 400 мак адресов, а циска гарантирует работоспособность таблицы с 4000
> макадресовТак а чем вас, например 3 минуты для arp не устраивает??как часто сервер 192.168.5.113 посылает со своего IP-а что-то в сеть?
Может банально запихнуть в cron что-то типаping -c 2 gateway > /dev/null
с периодичностью 2 минуты?
>[оверквотинг удален]
>> помониторю
>> Результат мониторинга показал, что иногда этот сбой происходит раньше 5 минут, и
>> пакеты начинают сыпаться пока не обнулится снова таблица.
>> В таблице 400 мак адресов, а циска гарантирует работоспособность таблицы с 4000
>> макадресов
> Так а чем вас, например 3 минуты для arp не устраивает??как часто
> сервер 192.168.5.113 посылает со своего IP-а что-то в сеть?
> Может банально запихнуть в cron что-то типа
> ping -n 2 gateway
> с периодичностью 2 минуты?попробую запихнуть в крон. а так от него вообще ничего в сеть не выходит
>[оверквотинг удален]
>>> пакеты начинают сыпаться пока не обнулится снова таблица.
>>> В таблице 400 мак адресов, а циска гарантирует работоспособность таблицы с 4000
>>> макадресов
>> Так а чем вас, например 3 минуты для arp не устраивает??как часто
>> сервер 192.168.5.113 посылает со своего IP-а что-то в сеть?
>> Может банально запихнуть в cron что-то типа
>> ping -n 2 gateway
>> с периодичностью 2 минуты?
> попробую запихнуть в крон. а так от него вообще ничего в сеть
> не выходитНу вот вам и причина - свич-то мак сам не спрашивает, а выуживает из фрейма посланного сервером, сервер ничо не послал... таймаут истек... свич мак "забыл", та же самая история и с arp....
>[оверквотинг удален]
> тспдамп молчал везде ровно 5 минут
> потом снова посыпались пакеты.
> сделал опять clear arp-cache interface vlan 5
> пакеты остановились. переодичность повторилась два раза.
> попробую поставить arp timeout 300
> только не понятно, что ровно через 5 минут происходит, что гетэвый забывает
> куда слать пакет, при этом запись в sh ip arp присутствует
> на 192.168.5.113 один интерфейс.
> Свитч L2 отсутствует в сети. Если только конечно в роли L2 не
> выступает xen сервер, распределяющий vlan по виртуалкамКапец... там оказывается еще и xen с виртуалками....
А как вы думаете - трафик к виртуалкам дух святой переносит??
Сервер от и как L2 и как L3 свич может быть для виртуалок - зависит от организации сети....
>[оверквотинг удален]
>> попробую поставить arp timeout 300
>> только не понятно, что ровно через 5 минут происходит, что гетэвый забывает
>> куда слать пакет, при этом запись в sh ip arp присутствует
>> на 192.168.5.113 один интерфейс.
>> Свитч L2 отсутствует в сети. Если только конечно в роли L2 не
>> выступает xen сервер, распределяющий vlan по виртуалкам
> Капец... там оказывается еще и xen с виртуалками....
> А как вы думаете - трафик к виртуалкам дух святой переносит??
> Сервер от и как L2 и как L3 свич может быть для
> виртуалок - зависит от организации сети....не совсем понял про виртуалки. там схема такая:
**3845**-------**3750**---------**3750x**----trunk----**xen**----**netflow**
>[оверквотинг удален]
>>> куда слать пакет, при этом запись в sh ip arp присутствует
>>> на 192.168.5.113 один интерфейс.
>>> Свитч L2 отсутствует в сети. Если только конечно в роли L2 не
>>> выступает xen сервер, распределяющий vlan по виртуалкам
>> Капец... там оказывается еще и xen с виртуалками....
>> А как вы думаете - трафик к виртуалкам дух святой переносит??
>> Сервер от и как L2 и как L3 свич может быть для
>> виртуалок - зависит от организации сети....
> не совсем понял про виртуалки. там схема такая:
> **3845**-------**3750**---------**3750x**----trunk----**xen**----**netflow**Xen может быть как L2 свич (если виртуалки прилеплены к какому-нибудь bridge интерфейсу) или как L3 свич.
Более того - там может быть несколько виртуальных свичей... как L3 так и L2...
>[оверквотинг удален]
>>> Капец... там оказывается еще и xen с виртуалками....
>>> А как вы думаете - трафик к виртуалкам дух святой переносит??
>>> Сервер от и как L2 и как L3 свич может быть для
>>> виртуалок - зависит от организации сети....
>> не совсем понял про виртуалки. там схема такая:
>> **3845**-------**3750**---------**3750x**----trunk----**xen**----**netflow**
> Xen может быть как L2 свич (если виртуалки прилеплены к какому-нибудь bridge
> интерфейсу) или как L3 свич.
> Более того - там может быть несколько виртуальных свичей... как L3 так
> и L2...в моем случае на xen созданы 2 бонд интерфейса и подключены к 3750х по транку в портчанел, доступ по всем vlan. А в xen уже в gui настраивается на какую виртуалку какой vlan выдать
>[оверквотинг удален]
>>> не совсем понял про виртуалки. там схема такая:
>>> **3845**-------**3750**---------**3750x**----trunk----**xen**----**netflow**
>> Xen может быть как L2 свич (если виртуалки прилеплены к какому-нибудь bridge
>> интерфейсу) или как L3 свич.
>> Более того - там может быть несколько виртуальных свичей... как L3 так
>> и L2...
> в моем случае на xen созданы 2 бонд интерфейса и подключены
> к 3750х по транку в портчанел, доступ по всем vlan. А
> в xen уже в gui настраивается на какую виртуалку какой vlan
> выдатьЗначит xen выполняет роль L2 коммутатора. так сказать виртуальный свич для виртуальных окружений.
Вобщем мониторьте - помог пинг или нет.
>[оверквотинг удален]
>>> интерфейсу) или как L3 свич.
>>> Более того - там может быть несколько виртуальных свичей... как L3 так
>>> и L2...
>> в моем случае на xen созданы 2 бонд интерфейса и подключены
>> к 3750х по транку в портчанел, доступ по всем vlan. А
>> в xen уже в gui настраивается на какую виртуалку какой vlan
>> выдать
> Значит xen выполняет роль L2 коммутатора. так сказать виртуальный свич для виртуальных
> окружений.
> Вобщем мониторьте - помог пинг или нет.Хорошо =) спасибо, буду мониторить, позже отпишусь
>[оверквотинг удален]
>>> интерфейсу) или как L3 свич.
>>> Более того - там может быть несколько виртуальных свичей... как L3 так
>>> и L2...
>> в моем случае на xen созданы 2 бонд интерфейса и подключены
>> к 3750х по транку в портчанел, доступ по всем vlan. А
>> в xen уже в gui настраивается на какую виртуалку какой vlan
>> выдать
> Значит xen выполняет роль L2 коммутатора. так сказать виртуальный свич для виртуальных
> окружений.
> Вобщем мониторьте - помог пинг или нет.судя по отсутствию жалоб - таки пинг помог :)
>[оверквотинг удален]
>>>> Более того - там может быть несколько виртуальных свичей... как L3 так
>>>> и L2...
>>> в моем случае на xen созданы 2 бонд интерфейса и подключены
>>> к 3750х по транку в портчанел, доступ по всем vlan. А
>>> в xen уже в gui настраивается на какую виртуалку какой vlan
>>> выдать
>> Значит xen выполняет роль L2 коммутатора. так сказать виртуальный свич для виртуальных
>> окружений.
>> Вобщем мониторьте - помог пинг или нет.
> судя по отсутствию жалоб - таки пинг помог :)Слежу до сих пор) проблема всё равно возникает, но намного реже и короче чем раньше =)
сеть больше не падала. Спасибо за помощь, надеюсь ничего не изменится)