Sergey Romanov Опубликовано 10 апреля, 2010 · Жалоба Приветствую всех! Есть проблема с QINQ. почему то работает только один влан. Внешний оператор дает нам канал, один vlan с тегом 502. С двух сторон порты оператора стоят в режиме trunk. C нашей стороны с одного конца стоит 3750 . Конфиг портов : interface GigabitEthernet1/0/11 на этом порту висят вланы, он замкнут на Gi1/0/12 switchport trunk encapsulation dot1q switchport trunk allowed vlan 50,300-304 switchport mode trunk ! interface GigabitEthernet1/0/12 на этом порту упаковываем пачку вланов в QINQ с тегом 502 description Q-in-Q switchport access vlan 502 switchport mode dot1q-tunnel switchport nonegotiate no mdix auto no cdp enable ! interface GigabitEthernet1/0/14 этот порт смотрит в сторону оператора switchport trunk encapsulation dot1q switchport trunk allowed vlan 502 switchport mode trunk на соответствующих интерфейсах vlan прописаны ip адреса C другой стороны стоит zyxel 4012 , для упаковки-распаковки qinq vlan 1 name 1 normal "" fixed "" forbidden 1-12 untagged 1-12 inactive exit vlan 50 name devices normal "" fixed 2-11 forbidden 1,12 untagged 1,12 ip address 10.166.253.15 255.255.252.0 ip address default-gateway 10.166.252.1 exit vlan 502 name test normal "" fixed 1,12 forbidden 2-11 untagged 2-12 exit interface port-channel 1 pvid 502 name PTST_PUSH vlan-stacking role tunnel vlan-stacking SPVID 502 exit interface port-channel 2 vlan-stacking role normal exit interface port-channel 3 vlan-stacking role normal exit interface port-channel 4 vlan-stacking role normal exit interface port-channel 5 vlan-stacking role normal exit interface port-channel 6 vlan-stacking role normal exit interface port-channel 7 vlan-stacking role normal exit interface port-channel 8 vlan-stacking role normal exit interface port-channel 9 vlan-stacking role normal exit interface port-channel 10 vlan-stacking role normal exit interface port-channel 11 name UP_3326 vlan-stacking role normal exit interface port-channel 12 pvid 502 name TUNN_in_out vlan-stacking SPVID 502 exit 1 порт смотрит в сторону провайдера 12 смотрит в сторону L2 коммутатора, на котором подняты вланы 50, 300 - 30, все порты в теге. коммутатор играет роль узловых. после идет абонентский коммутатор принимает абонентский влан 300 и влан управления 50 Проблема в том, что влан управления 50 работает нормально, а по абонентскому влану пакеты не проходят. В чем может быть проблема? mtu подняли до 1526 - ничего не дало. Может кто в курсе куда смотреть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimasbu Опубликовано 10 апреля, 2010 · Жалоба Приветствую всех! Есть проблема с QINQ. почему то работает только один влан.Внешний оператор дает нам канал, один vlan с тегом 502. С двух сторон порты оператора стоят в режиме trunk. C нашей стороны с одного конца стоит 3750 . Конфиг портов : interface GigabitEthernet1/0/11 на этом порту висят вланы, он замкнут на Gi1/0/12 switchport trunk encapsulation dot1q switchport trunk allowed vlan 50,300-304 switchport mode trunk ! interface GigabitEthernet1/0/12 на этом порту упаковываем пачку вланов в QINQ с тегом 502 description Q-in-Q switchport access vlan 502 switchport mode dot1q-tunnel switchport nonegotiate no mdix auto no cdp enable ! interface GigabitEthernet1/0/14 этот порт смотрит в сторону оператора switchport trunk encapsulation dot1q switchport trunk allowed vlan 502 switchport mode trunk на соответствующих интерфейсах vlan прописаны ip адреса C другой стороны стоит zyxel 4012 , для упаковки-распаковки qinq vlan 1 name 1 normal "" fixed "" forbidden 1-12 untagged 1-12 inactive exit vlan 50 name devices normal "" fixed 2-11 forbidden 1,12 untagged 1,12 ip address 10.166.253.15 255.255.252.0 ip address default-gateway 10.166.252.1 exit vlan 502 name test normal "" fixed 1,12 forbidden 2-11 untagged 2-12 exit interface port-channel 1 pvid 502 name PTST_PUSH vlan-stacking role tunnel vlan-stacking SPVID 502 exit interface port-channel 2 vlan-stacking role normal exit interface port-channel 3 vlan-stacking role normal exit interface port-channel 4 vlan-stacking role normal exit interface port-channel 5 vlan-stacking role normal exit interface port-channel 6 vlan-stacking role normal exit interface port-channel 7 vlan-stacking role normal exit interface port-channel 8 vlan-stacking role normal exit interface port-channel 9 vlan-stacking role normal exit interface port-channel 10 vlan-stacking role normal exit interface port-channel 11 name UP_3326 vlan-stacking role normal exit interface port-channel 12 pvid 502 name TUNN_in_out vlan-stacking SPVID 502 exit 1 порт смотрит в сторону провайдера 12 смотрит в сторону L2 коммутатора, на котором подняты вланы 50, 300 - 30, все порты в теге. коммутатор играет роль узловых. после идет абонентский коммутатор принимает абонентский влан 300 и влан управления 50 Проблема в том, что влан управления 50 работает нормально, а по абонентскому влану пакеты не проходят. В чем может быть проблема? mtu подняли до 1526 - ничего не дало. Может кто в курсе куда смотреть? на циске вроде все правильно, мб в zyxel? (не умею его готовить, в куске конфига влан 300 не видать) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Romanov Опубликовано 11 апреля, 2010 · Жалоба 300 влан поднят на L2 коммутаторе за zyxel и выходит в теге в 12 порт zyxel . причем 50 влан управления приходит на zyxel также с L2 коммутатора в 11 порт. Таким образом получается, что 50 влан упаковывается в qinq и распаковывается нормально. Большие пакеты проходят нормально. Вэбки коммутаторов открываются. Сегодня попробовал сделать влан управления не 50 а 300. То есть просто теги поменял и соответственно интерфейсы поднял в этом влане - нифига не работает.(( Такое чувство. что 50 влан какой-то волшебный!)) Но чудес то не бывает! Есть какие-нибудь еще идеи? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Romanov Опубликовано 12 апреля, 2010 · Жалоба Ну что, нет совсем ни у кого идей? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OlegStr Опубликовано 13 апреля, 2010 · Жалоба хмм .. какие TPID (tag protocol ID) у провайдера и у Вас на коммутаторах ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Romanov Опубликовано 14 апреля, 2010 · Жалоба TPID и у нас и у провайдера 0x8100 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OlegStr Опубликовано 14 апреля, 2010 · Жалоба а что будет , если поставить у Вас на обоих коммутаторах TPID 9100 например ? А у провайдера будет 8100 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 14 апреля, 2010 · Жалоба А накой вы вообще навертели такое чудо чудное? На мой взгляд, dot1q-tunnel должен прописать у себя провайдер с обоих сторон, с вашей стороны эти порты будут видны как просто транк, без всяких туннелей. По моему косяк как раз где-то тут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Romanov Опубликовано 15 апреля, 2010 · Жалоба а что будет , если поставить у Вас на обоих коммутаторах TPID 9100 например ? А у провайдера будет 8100 делали такое на тестовом стенде, в качестве оператора использовали несколько L2 свитчей, не работала такая схема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey Romanov Опубликовано 15 апреля, 2010 · Жалоба А накой вы вообще навертели такое чудо чудное?На мой взгляд, dot1q-tunnel должен прописать у себя провайдер с обоих сторон, с вашей стороны эти порты будут видны как просто транк, без всяких туннелей. По моему косяк как раз где-то тут. Провайдер не хочет такого делать, да и не совсем получится, с одной стороны мы от этого прова получаем 2 влана на их порту, в одном из которых инет, в другом канал. Вланы идут по одному волокну и приходят в один порт нашей циски. Сейчас решили пока забить на qinq. подняли L3 и замаршрутизировали удаленные вланы. Просто сроки горят. Надо было срочно запускать удаленную площадку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 16 апреля, 2010 (изменено) · Жалоба Что-то вы забавного нагородили. Поясните, как вы хотели без провайдера QinQ организовать-то? Завернуть свой трафик через один порт в QinQ, и потом все это отправить уже в провайдера? Без поддержки провайдером такой картины, думается мне не обойтись... Странно что вообще что-то работало. Может native было управление? Если нужны именно прозрачные вланы, да железо и оператор (по MTU) позволяет - то L2oMPLS может помочь, а так L3 было правильным решением. Изменено 16 апреля, 2010 пользователем SergeiK Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
virusu Опубликовано 19 апреля, 2010 (изменено) · Жалоба Любой порядочный девайс сейчас проверяет кол-во тегов во избежание VLAN hopping. Если порт access - ожидается фрейм без 802.1q тегов, любой тегированный будет отброшен. Если порт - dot1q tunnel, то пришедший фрейм с 2 тегами тоже не пройдёт. Зы. Территориально распределенные объекты лучше объединять по L3, тут на вас работает маршрутизация => масштабируемость, резервирование. Изменено 19 апреля, 2010 пользователем virusu Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...