форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Маршрутизаторы CISCO и др. оборудование. (Диагностика и решение проблем)
Изначальное сообщение		[ Отслеживать ]

"cisco + netflow + tcpdump"	+/–
Сообщение от alex shukur (ok) on 06-Дек-12, 17:05
Добрый день, коллеги. У меня такой интересный случай произошел. Имеется циска 3845 (провайдер) + циска 3750 (Внутрисетевой гетэвэй), сервер нетфлоу и еще несколько серверов в сети. циска отправляет в нетфлоу данные на сервер нетфлоу. Но я сделал tcpdump на других серверах в этой сети и обнаружил, что иногда, пакеты предназначенные для сервера нетфлоу транслируются на все адреса в этой сети, при этом пакеты маркируются как предназначенные для сервера нетфлоу. не пойму с чем это может быть связано. с других цисок тоже нетфлоу идет на все адреса в сети. Где искать корни проблемы?
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "cisco + netflow + tcpdump"	+/–
Сообщение от fantom (ok) on 06-Дек-12, 17:07
> Добрый день, коллеги. > У меня такой интересный случай произошел. > Имеется циска 3845 (провайдер) + циска 3750 (Внутрисетевой гетэвэй), сервер нетфлоу и > еще несколько серверов в сети. > циска отправляет в нетфлоу данные на сервер нетфлоу. Но я сделал tcpdump > на других серверах в этой сети и обнаружил, что иногда, пакеты > предназначенные для сервера нетфлоу транслируются на все адреса в этой сети, > при этом пакеты маркируются как предназначенные для сервера нетфлоу. > не пойму с чем это может быть связано. с других цисок тоже > нетфлоу идет на все адреса в сети. Где искать корни проблемы? Во времени жизни записи MAC-а в таблице коммутатора. И в протоколе ethernet :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 06-Дек-12, 17:12
	>[оверквотинг удален] >> Имеется циска 3845 (провайдер) + циска 3750 (Внутрисетевой гетэвэй), сервер нетфлоу и >> еще несколько серверов в сети. >> циска отправляет в нетфлоу данные на сервер нетфлоу. Но я сделал tcpdump >> на других серверах в этой сети и обнаружил, что иногда, пакеты >> предназначенные для сервера нетфлоу транслируются на все адреса в этой сети, >> при этом пакеты маркируются как предназначенные для сервера нетфлоу. >> не пойму с чем это может быть связано. с других цисок тоже >> нетфлоу идет на все адреса в сети. Где искать корни проблемы? > Во времени жизни записи MAC-а в таблице коммутатора. > И в протоколе ethernet :) тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе, а рассылается только в сети, в которой находится сервер нетфлоу
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 06-Дек-12, 17:32
	>[оверквотинг удален] >>> циска отправляет в нетфлоу данные на сервер нетфлоу. Но я сделал tcpdump >>> на других серверах в этой сети и обнаружил, что иногда, пакеты >>> предназначенные для сервера нетфлоу транслируются на все адреса в этой сети, >>> при этом пакеты маркируются как предназначенные для сервера нетфлоу. >>> не пойму с чем это может быть связано. с других цисок тоже >>> нетфлоу идет на все адреса в сети. Где искать корни проблемы? >> Во времени жизни записи MAC-а в таблице коммутатора. >> И в протоколе ethernet :) > тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе, > а рассылается только в сети, в которой находится сервер нетфлоу Расслка идет в одном vlan-е - только и всего...
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 06-Дек-12, 17:33
	>[оверквотинг удален] >>>> на других серверах в этой сети и обнаружил, что иногда, пакеты >>>> предназначенные для сервера нетфлоу транслируются на все адреса в этой сети, >>>> при этом пакеты маркируются как предназначенные для сервера нетфлоу. >>>> не пойму с чем это может быть связано. с других цисок тоже >>>> нетфлоу идет на все адреса в сети. Где искать корни проблемы? >>> Во времени жизни записи MAC-а в таблице коммутатора. >>> И в протоколе ethernet :) >> тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе, >> а рассылается только в сети, в которой находится сервер нетфлоу > Расслка идет в одном vlan-е - только и всего... Нормальные коммутаторы ведут таблицу port-vlan-mac.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 06-Дек-12, 17:50
	>[оверквотинг удален] >>>>> при этом пакеты маркируются как предназначенные для сервера нетфлоу. >>>>> не пойму с чем это может быть связано. с других цисок тоже >>>>> нетфлоу идет на все адреса в сети. Где искать корни проблемы? >>>> Во времени жизни записи MAC-а в таблице коммутатора. >>>> И в протоколе ethernet :) >>> тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе, >>> а рассылается только в сети, в которой находится сервер нетфлоу >> Расслка идет в одном vlan-е - только и всего... > Нормальные коммутаторы ведут таблицу > port-vlan-mac. ну например так, я посмотрел настройки, время жизни 4 минуты. возможно примерно с таким периодом иногда происходит широковещательная рассылка. но всё равно это же не нормально.. иногда это вешает сеть на несколько секунд.. я так понимаю что увеличение времени жизни арп не поможет полностью решить, поможет только время растянуть. а статическая запись арп исключено
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 06-Дек-12, 17:58
	>[оверквотинг удален] >>>> тогда бы я думаю рассылалось на все сети, которые имеются на гетэвэе, >>>> а рассылается только в сети, в которой находится сервер нетфлоу >>> Расслка идет в одном vlan-е - только и всего... >> Нормальные коммутаторы ведут таблицу >> port-vlan-mac. > ну например так, я посмотрел настройки, время жизни 4 минуты. возможно примерно > с таким периодом иногда происходит широковещательная рассылка. но всё равно это > же не нормально.. иногда это вешает сеть на несколько секунд.. я > так понимаю что увеличение времени жизни арп не поможет полностью решить, > поможет только время растянуть. а статическая запись арп исключено "иногда это вешает сеть на несколько секунд.. " ЭТО не может вешать сеть на несколько секунд, т.к. это НОРМАЛЬНОЕ ПОВЕДЕНИЕ ЛЮБОГО КОММУТАТОРА! Ищите причины зависона... Как вариант - с некоторыми длинками есть проблема "потери" MAC-ов. Еще как вариант - в вашей сети слишком много MAC-ов, и в таблицу коммутатора они просто не помещаются. Запустите tcpdump с ключем -e и посмотрите какие mac-и в этом фрейме...
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 06-Дек-12, 20:49
	>[оверквотинг удален] >> так понимаю что увеличение времени жизни арп не поможет полностью решить, >> поможет только время растянуть. а статическая запись арп исключено > "иногда это вешает сеть на несколько секунд.. " > ЭТО не может вешать сеть на несколько секунд, т.к. это НОРМАЛЬНОЕ ПОВЕДЕНИЕ > ЛЮБОГО КОММУТАТОРА! > Ищите причины зависона... > Как вариант - с некоторыми длинками есть проблема "потери" 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 включен
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	10. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 10:22
	>[оверквотинг удален] >> Как вариант - с некоторыми длинками есть проблема "потери" 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 включен - то в чем проблема?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	8. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 06-Дек-12, 23:35
	Кстати когда tcpdump делал, по макадресам видно, что пакет посылает не циска 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней 5- тому влану, в который и идет рассылка..
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 10:16
	> Кстати когда tcpdump делал, по макадресам видно, что пакет посылает не циска > 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней > 5- тому влану, в который и идет рассылка.. И что вас в этом настораживает??? Вот если бы MAC принадлежал 3845 - было бы удивительно...
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 10:43
	>> Кстати когда tcpdump делал, по макадресам видно, что пакет посылает не циска >> 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней >> 5- тому влану, в который и идет рассылка.. > И что вас в этом настораживает??? > Вот если бы MAC принадлежал 3845 - было бы удивительно... настораживает, что сеть падает, а причины не известны)) логов нет, а дебаг включить боюсь, так как cpu и так на пределе
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	12. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 11:10
	>>> Кстати когда tcpdump делал, по макадресам видно, что пакет посылает не циска >>> 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней >>> 5- тому влану, в который и идет рассылка.. >> И что вас в этом настораживает??? >> Вот если бы MAC принадлежал 3845 - было бы удивительно... > настораживает, что сеть падает, а причины не известны)) логов нет, а дебаг > включить боюсь, так как cpu и так на пределе СИМПТОМЫ ПАДЕНИЯ КАКИЕ?? что падает-то? вся сеть со всеми маршрутизаторами/коммутаторами? один VLAN? один сегмент? один сервак? Так может именно в этом и причина - в CPU на пределе??? И чем же он занят?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 11:25
	>[оверквотинг удален] >>>> 3845 на нетфлоу, гетэвейная циска 3750, мак адрес принадлежит на ней >>>> 5- тому влану, в который и идет рассылка.. >>> И что вас в этом настораживает??? >>> Вот если бы MAC принадлежал 3845 - было бы удивительно... >> настораживает, что сеть падает, а причины не известны)) логов нет, а дебаг >> включить боюсь, так как cpu и так на пределе > СИМПТОМЫ ПАДЕНИЯ КАКИЕ?? что падает-то? вся сеть со всеми маршрутизаторами/коммутаторами? > один VLAN? один сегмент? один сервак? > Так может именно в этом и причина - в CPU на пределе??? > И чем же он занят? симптомы, это то, что нагиос показывает, что не доступны все сетевые хосты в сети. со всеми маршрутизаторами и коммутаторами. врядли причина в CPU, тогда бы в логах была ошибка CPU. Этот 3750 является гетэвэейм для множества вланов
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 11:37
	>[оверквотинг удален] >>> включить боюсь, так как cpu и так на пределе >> СИМПТОМЫ ПАДЕНИЯ КАКИЕ?? что падает-то? вся сеть со всеми маршрутизаторами/коммутаторами? >> один VLAN? один сегмент? один сервак? >> Так может именно в этом и причина - в CPU на пределе??? >> И чем же он занят? > симптомы, это то, что нагиос показывает, что не доступны все сетевые хосты > в сети. > со всеми маршрутизаторами и коммутаторами. > врядли причина в CPU, тогда бы в логах была ошибка CPU. > Этот 3750 является гетэвэейм для множества вланов Дык нагиос - он работает-то на СЕРВАКЕ и я бы начал с диагностики сервака... например банально с другого сервака пингать шлюз+нагиос и посмотреть результат, если в момент "пропадания" с другого сервака шлюз пингуется, а нагиос нет - вывод будет однозначным :)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 12:59
	>[оверквотинг удален] >> симптомы, это то, что нагиос показывает, что не доступны все сетевые хосты >> в сети. >> со всеми маршрутизаторами и коммутаторами. >> врядли причина в CPU, тогда бы в логах была ошибка CPU. >> Этот 3750 является гетэвэейм для множества вланов > Дык нагиос - он работает-то на СЕРВАКЕ и я бы начал с > диагностики сервака... > например банально с другого сервака пингать шлюз+нагиос и посмотреть результат, если в > момент "пропадания" с другого сервака шлюз пингуется, а нагиос нет - > вывод будет однозначным :) Я конечно думал над этим, но дело в том, что когда это происходит, глючит не только нагиос, но и пакеты с других серверов теряются, и на циске 3750 sla отваливается) что то слишком часто идут эти широковещательные пакеты, что самое странное, то что не на все сервера доходят из этой сети.. И мне кажется, что широковещательные пакеты идут скорее всего не из за времени arp. так как идут в разнобой, не зависимо от текущих настроек 4 мин..
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 13:27
	>[оверквотинг удален] >> Дык нагиос - он работает-то на СЕРВАКЕ и я бы начал с >> диагностики сервака... >> например банально с другого сервака пингать шлюз+нагиос и посмотреть результат, если в >> момент "пропадания" с другого сервака шлюз пингуется, а нагиос нет - >> вывод будет однозначным :) > Я конечно думал над этим, но дело в том, что когда это > происходит, глючит не только нагиос, но и пакеты с других серверов > теряются, и на циске 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
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 13:36
	>[оверквотинг удален] > 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     1254233324332222442522455532212223213332234222233993242144222461243734     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 хостов. Если включить дебаг, то сиська вешается, уже пробовали.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 14:02
	как порекамендовали выше, поставил arp-timeout 3 в тспдамп пропали эти эти ошибки, но редко стало появляться такое 13:59:14.451401 arp who-has 192.168.5.113 tell gateway
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 14:19
	> как порекамендовали выше, поставил 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-му интерфейсу.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	20. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 14:31
	>[оверквотинг удален] > Теперь 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 по виртуалкам
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	21. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 14:40
	Поставил arp timeout 300 на пятый влан. Ни одного пакета за 10 минут не проскочило, надеюсь на этом проблема будет решена =) еще помониторю Результат мониторинга показал, что иногда этот сбой происходит раньше 5 минут, и пакеты начинают сыпаться пока не обнулится снова таблица. В таблице 400 мак адресов, а циска гарантирует работоспособность таблицы с 4000 макадресов
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	23. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 15:17
	> Поставил arp timeout 300 на пятый влан. Ни одного пакета за 10 > минут не проскочило, надеюсь на этом проблема будет решена =) еще > помониторю > Результат мониторинга показал, что иногда этот сбой происходит раньше 5 минут, и > пакеты начинают сыпаться пока не обнулится снова таблица. > В таблице 400 мак адресов, а циска гарантирует работоспособность таблицы с 4000 > макадресов Так а чем вас, например 3 минуты для arp не устраивает??как часто сервер 192.168.5.113 посылает со своего IP-а что-то в сеть? Может банально запихнуть в cron что-то типа ping -c 2 gateway > /dev/null с периодичностью 2 минуты?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	24. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 15:19
	>[оверквотинг удален] >> помониторю >> Результат мониторинга показал, что иногда этот сбой происходит раньше 5 минут, и >> пакеты начинают сыпаться пока не обнулится снова таблица. >> В таблице 400 мак адресов, а циска гарантирует работоспособность таблицы с 4000 >> макадресов > Так а чем вас, например 3 минуты для arp не устраивает??как часто > сервер 192.168.5.113 посылает со своего IP-а что-то в сеть? > Может банально запихнуть в cron что-то типа > ping -n 2 gateway > с периодичностью 2 минуты? попробую запихнуть в крон. а так от него вообще ничего в сеть не выходит
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 15:21
	>[оверквотинг удален] >>> пакеты начинают сыпаться пока не обнулится снова таблица. >>> В таблице 400 мак адресов, а циска гарантирует работоспособность таблицы с 4000 >>> макадресов >> Так а чем вас, например 3 минуты для arp не устраивает??как часто >> сервер 192.168.5.113 посылает со своего IP-а что-то в сеть? >> Может банально запихнуть в cron что-то типа >> ping -n 2 gateway >> с периодичностью 2 минуты? > попробую запихнуть в крон. а так от него вообще ничего в сеть > не выходит Ну вот вам и причина - свич-то мак сам не спрашивает, а выуживает из фрейма посланного сервером, сервер ничо не послал... таймаут истек... свич мак "забыл", та же самая история и с arp....
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	22. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 15:13
	>[оверквотинг удален] > тспдамп молчал везде ровно 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 свич может быть для виртуалок - зависит от организации сети....
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	26. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 15:21
	>[оверквотинг удален] >> попробую поставить arp timeout 300 >> только не понятно, что ровно через 5 минут происходит, что гетэвый забывает >> куда слать пакет, при этом запись в sh ip arp присутствует >> на 192.168.5.113 один интерфейс. >> Свитч L2 отсутствует в сети. Если только конечно в роли L2 не >> выступает xen сервер, распределяющий vlan по виртуалкам > Капец... там оказывается еще и xen с виртуалками.... > А как вы думаете - трафик к виртуалкам дух святой переносит?? > Сервер от и как L2 и как L3 свич может быть для > виртуалок - зависит от организации сети.... не совсем понял про виртуалки. там схема такая: **3845**-------**3750**---------**3750x**----trunk----**xen**----**netflow**
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	27. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 15:26
	>[оверквотинг удален] >>> куда слать пакет, при этом запись в 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...
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	28. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 15:35
	>[оверквотинг удален] >>> Капец... там оказывается еще и xen с виртуалками.... >>> А как вы думаете - трафик к виртуалкам дух святой переносит?? >>> Сервер от и как L2 и как L3 свич может быть для >>> виртуалок - зависит от организации сети.... >> не совсем понял про виртуалки. там схема такая: >> **3845**-------**3750**---------**3750x**----trunk----**xen**----**netflow** > Xen может быть как L2 свич (если виртуалки прилеплены к какому-нибудь bridge > интерфейсу) или как L3 свич. > Более того - там может быть несколько виртуальных свичей... как L3 так > и L2... в моем случае на xen созданы 2 бонд интерфейса  и подключены к 3750х по транку в портчанел, доступ по всем vlan. А в xen уже в gui настраивается на какую виртуалку какой vlan выдать
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	29. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 07-Дек-12, 15:45
	>[оверквотинг удален] >>> не совсем понял про виртуалки. там схема такая: >>> **3845**-------**3750**---------**3750x**----trunk----**xen**----**netflow** >> Xen может быть как L2 свич (если виртуалки прилеплены к какому-нибудь bridge >> интерфейсу) или как L3 свич. >> Более того - там может быть несколько виртуальных свичей... как L3 так >> и L2... > в моем случае на xen созданы 2 бонд интерфейса  и подключены > к 3750х по транку в портчанел, доступ по всем vlan. А > в xen уже в gui настраивается на какую виртуалку какой vlan > выдать Значит xen выполняет роль L2 коммутатора. так сказать виртуальный свич для виртуальных окружений. Вобщем мониторьте - помог пинг или нет.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	30. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 07-Дек-12, 15:48
	>[оверквотинг удален] >>> интерфейсу) или как L3 свич. >>> Более того - там может быть несколько виртуальных свичей... как L3 так >>> и L2... >> в моем случае на xen созданы 2 бонд интерфейса  и подключены >> к 3750х по транку в портчанел, доступ по всем vlan. А >> в xen уже в gui настраивается на какую виртуалку какой vlan >> выдать > Значит xen выполняет роль L2 коммутатора. так сказать виртуальный свич для виртуальных > окружений. > Вобщем мониторьте - помог пинг или нет. Хорошо =) спасибо, буду мониторить, позже отпишусь
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "cisco + netflow + tcpdump"	+/–
	Сообщение от fantom (ok) on 11-Дек-12, 17:02
	>[оверквотинг удален] >>> интерфейсу) или как L3 свич. >>> Более того - там может быть несколько виртуальных свичей... как L3 так >>> и L2... >> в моем случае на xen созданы 2 бонд интерфейса  и подключены >> к 3750х по транку в портчанел, доступ по всем vlan. А >> в xen уже в gui настраивается на какую виртуалку какой vlan >> выдать > Значит xen выполняет роль L2 коммутатора. так сказать виртуальный свич для виртуальных > окружений. > Вобщем мониторьте - помог пинг или нет. судя по отсутствию жалоб - таки пинг помог :)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	32. "cisco + netflow + tcpdump"	+/–
	Сообщение от alex shukur (ok) on 11-Дек-12, 17:46
	>[оверквотинг удален] >>>> Более того - там может быть несколько виртуальных свичей... как L3 так >>>> и L2... >>> в моем случае на xen созданы 2 бонд интерфейса  и подключены >>> к 3750х по транку в портчанел, доступ по всем vlan. А >>> в xen уже в gui настраивается на какую виртуалку какой vlan >>> выдать >> Значит xen выполняет роль L2 коммутатора. так сказать виртуальный свич для виртуальных >> окружений. >> Вобщем мониторьте - помог пинг или нет. > судя по отсутствию жалоб - таки пинг помог :) Слежу до сих пор) проблема всё равно возникает, но намного реже и короче чем раньше =) сеть больше не падала. Спасибо за помощь, надеюсь ничего не изменится)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема