QinQ a normalny access
QinQ a normalny access
Witam,
Chciał bym się poradzić bardziej doświadczonych kolegów.
Robie sobie tutaj rożne wersje konfiguracji i zauważyłem że jak na jednym porcie mam trunk z VLAN id 100 który jest podpięty pod router na który mam VLANid 100 a w nim VLAN id 20
To jak pod inny port w trybie access dodam VLAN id 100 i podłączę kompa na którym zrobie VLAN id 20 to switch sam ściągnie/doda mi dodatkowego taga 100 na tym porcie access z kompem i potem przepuści na port TRUNK pakiet 100(20) do routera.
No i tutaj moje pytanie, skoro swith sam nadpisuje dodatkowy znacznik vlan w trybie access niezależnie czy ramka ma już znacznik 802.1q to do czego może się przydać tryb dot1q-tunnel ?
Chciał bym się poradzić bardziej doświadczonych kolegów.
Robie sobie tutaj rożne wersje konfiguracji i zauważyłem że jak na jednym porcie mam trunk z VLAN id 100 który jest podpięty pod router na który mam VLANid 100 a w nim VLAN id 20
To jak pod inny port w trybie access dodam VLAN id 100 i podłączę kompa na którym zrobie VLAN id 20 to switch sam ściągnie/doda mi dodatkowego taga 100 na tym porcie access z kompem i potem przepuści na port TRUNK pakiet 100(20) do routera.
No i tutaj moje pytanie, skoro swith sam nadpisuje dodatkowy znacznik vlan w trybie access niezależnie czy ramka ma już znacznik 802.1q to do czego może się przydać tryb dot1q-tunnel ?
Re: QinQ a normalny access
Trochę precyzji poprosimy.
Co to jest za urządzenie z jakim softem?
Co to znaczy "podłączę kompa na którym zrobie VLAN id 20" - masz po stronie stacji użytkownika sterownik który dodaje tag 802.1Q?
Pokaż konfiguracje z przełącznika obu portów oraz ew. z routera portu w stronę przełącznika.
Co to jest za urządzenie z jakim softem?
Co to znaczy "podłączę kompa na którym zrobie VLAN id 20" - masz po stronie stacji użytkownika sterownik który dodaje tag 802.1Q?
Pokaż konfiguracje z przełącznika obu portów oraz ew. z routera portu w stronę przełącznika.
Re: QinQ a normalny access
Chodzi mi bardziej o kwestie ideowe (zastosowania) niż konkretny problem konfiguracji.
Zastanawiam się jaką funkcję może pełnił tryb dot1q-tunnel na interfacie skoro normalne tryby (trunk,access) też sobie z tym radzą. Do czego się przydaje/używa ten tryb ?
Czyli
Tryb TRUNK na interfacie przenosi pakiety z dwoma TAG-ami
A tryb access dopisuje (ściąga) dodatkowy tag do pakietu już otagowanego - czyli "robi/demontuje" QinqQ.
Tak więc co takiego robi dot1q-tunnel czego nie robi trunk i access ?
Zastanawiam się jaką funkcję może pełnił tryb dot1q-tunnel na interfacie skoro normalne tryby (trunk,access) też sobie z tym radzą. Do czego się przydaje/używa ten tryb ?
Czyli
Tryb TRUNK na interfacie przenosi pakiety z dwoma TAG-ami
A tryb access dopisuje (ściąga) dodatkowy tag do pakietu już otagowanego - czyli "robi/demontuje" QinqQ.
Tak więc co takiego robi dot1q-tunnel czego nie robi trunk i access ?
Re: QinQ a normalny access
Coś się pokiełbasiło nieco. Ze swoich dawnych czasów security-switching-very-wszystko (pokazy różnych ataków i niszczenia młotkiem w trakcie ataku dalej chyba da się znaleźć na video), mogę powiedzieć, że:
1. Port w trybie 'access', odrzuci otagowaną ramkę. W części przełączników, dopuszczalne jest wysłanie ruchu otagowanego tym samym ID VLANu 802.1Q do którego należy port w trybie access - ale nic więcej. Tutaj Twoje obserwacje się nie zgadzają i mam wrażenie, że patrzysz albo nie na sprzęt Cisco, albo być może nie do końca dobrze skonfigurowałeś sprzęt. Jedynym wyjątkiem są tu porty ustawione jako 'voice' ale mam wrażenie, że takimi się nie posługujesz.
2. Port w trybie 'trunk' odbierze ramkę otagowaną RAZ. To spokojnie wystarcza dla sieci typu enterprise (ograniczenie skalowalności do 1024 lub 4096 różnych VLANów), ale nie wystarcza operatorom.
3. Port 'dot1q-tunnel', a właściwie taka funkcjonalność, pozwala przenieść ruch L2 odebrany od klienta, bez ingerencji w tagi - w bardzo prosty, podstawowy sposób. Załóżmy, że Twój klient chce używać VLANów 200, 300 i 500. A Ty dla transportu tego Klienta chcesz użyć w swojej sieci VLAN 2010. Konfiguracja portu w stronę klienta (on będzie miał trunk) wyglądać będzie tak:
Z tego co pamiętam, ograniczeniem jest tu Ethertype - przenoszone są ramki z 0x8100 i taka wartość jest też do ramek dodawana. Jeśli chcesz robić coś więcej, np. dodatkowo ramki CDP, LLDP i inne, musisz włączyć osobno Layer 2 Protocol Tunneling (L2PT, nie mylić z L2TP). Funkcjonalność może działać razem lub osobno od dot1q-tunneling, w zależności od konfiguracji i sprzętu.
W zależności od sprzętu i wersji softu - na Catalystach i routerach z IOSem może zdarzyć się, że będziesz miał możliwość dodawania drugiego taga (tzw. QinQ termination), przez wskazanie podwójnego tagowania przy opisie hermetyzacji (np. encapsulation dot1q 300 second-dot1q 100-199), natomiast na przełącznikach Metro Ethernet i sprzęcie operatorskim masz całą infrastrukturę EVC, która pozwala robić prawie dowolne cuda z sekwencjami zdejmowania, dodawania i mapowania VLANów (tagów).
1. Port w trybie 'access', odrzuci otagowaną ramkę. W części przełączników, dopuszczalne jest wysłanie ruchu otagowanego tym samym ID VLANu 802.1Q do którego należy port w trybie access - ale nic więcej. Tutaj Twoje obserwacje się nie zgadzają i mam wrażenie, że patrzysz albo nie na sprzęt Cisco, albo być może nie do końca dobrze skonfigurowałeś sprzęt. Jedynym wyjątkiem są tu porty ustawione jako 'voice' ale mam wrażenie, że takimi się nie posługujesz.
2. Port w trybie 'trunk' odbierze ramkę otagowaną RAZ. To spokojnie wystarcza dla sieci typu enterprise (ograniczenie skalowalności do 1024 lub 4096 różnych VLANów), ale nie wystarcza operatorom.
3. Port 'dot1q-tunnel', a właściwie taka funkcjonalność, pozwala przenieść ruch L2 odebrany od klienta, bez ingerencji w tagi - w bardzo prosty, podstawowy sposób. Załóżmy, że Twój klient chce używać VLANów 200, 300 i 500. A Ty dla transportu tego Klienta chcesz użyć w swojej sieci VLAN 2010. Konfiguracja portu w stronę klienta (on będzie miał trunk) wyglądać będzie tak:
Kod: Zaznacz cały
sp-sw(config)#interface fastEthernet 0/1
sp-sw(config-if)#switchport access vlan 2010
sp-sw(config-if)#switchport mode dot1q-tunnel
W zależności od sprzętu i wersji softu - na Catalystach i routerach z IOSem może zdarzyć się, że będziesz miał możliwość dodawania drugiego taga (tzw. QinQ termination), przez wskazanie podwójnego tagowania przy opisie hermetyzacji (np. encapsulation dot1q 300 second-dot1q 100-199), natomiast na przełącznikach Metro Ethernet i sprzęcie operatorskim masz całą infrastrukturę EVC, która pozwala robić prawie dowolne cuda z sekwencjami zdejmowania, dodawania i mapowania VLANów (tagów).
Re: QinQ a normalny access
To tutaj właśnie chyba jest pies pogrzebany.
Przełącznik to NEXUS 3064
ethernet 1/1 - router
ethernet 1/3 - komputer
konfiguracja komputer
ip link add link eth0 name eth0.20 type vlan id 20
ip addr add 10.2.6.253/24 dev eth0.20
konfiguracja switha
vlan 1
vlan 2
name TEST
vlan 500
name mgmt
no cdp enable
vrf context management
no port-channel load-balance resilient
hardware profile portmode 64x10G
no hardware profile ecmp resilient
interface Ethernet1/1
switchport mode trunk
switchport trunk allowed vlan 2,500
interface Ethernet1/2
switchport access vlan 2
interface Ethernet1/3
switchport access vlan 2
Akcja : wysyłam ping z komputera (wcześniej dodałem sobie na kompie z linuxem do talibcy ARP maca zmyślonego zeby mi pakiet wygenerowal i po vlanach przeszedl - na routerze tylko podglądnę )
ping 10.2.6.254
i pakiet który dociera do routera wygląda tak:
11 22 11 44 11 11 70 58 12 dd d2 16 81 00 00 02
88 a8 00 14 08 00 45 00 00 54 26 97 40 00 40 01
f2 13 0a 02 06 fd 0a 02 06 fe 08 00 64 67 59 e5
00 18 f3 6e 4a 5e 04 cb 0c 00 08 09 0a 0b 0c 0d
0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d
1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d
2e 2f 30 31 32 33 34 35 36 37
tutaj mozna (zeby nie szukac) obczaic https://hpd.gasmi.net/
Czyli do routera dociera ramka z TAG 2 (vlan switha) jak również 20 ->vlan na interfacie komputer
Przełącznik to NEXUS 3064
ethernet 1/1 - router
ethernet 1/3 - komputer
konfiguracja komputer
ip link add link eth0 name eth0.20 type vlan id 20
ip addr add 10.2.6.253/24 dev eth0.20
konfiguracja switha
vlan 1
vlan 2
name TEST
vlan 500
name mgmt
no cdp enable
vrf context management
no port-channel load-balance resilient
hardware profile portmode 64x10G
no hardware profile ecmp resilient
interface Ethernet1/1
switchport mode trunk
switchport trunk allowed vlan 2,500
interface Ethernet1/2
switchport access vlan 2
interface Ethernet1/3
switchport access vlan 2
Akcja : wysyłam ping z komputera (wcześniej dodałem sobie na kompie z linuxem do talibcy ARP maca zmyślonego zeby mi pakiet wygenerowal i po vlanach przeszedl - na routerze tylko podglądnę )
ping 10.2.6.254
i pakiet który dociera do routera wygląda tak:
11 22 11 44 11 11 70 58 12 dd d2 16 81 00 00 02
88 a8 00 14 08 00 45 00 00 54 26 97 40 00 40 01
f2 13 0a 02 06 fd 0a 02 06 fe 08 00 64 67 59 e5
00 18 f3 6e 4a 5e 04 cb 0c 00 08 09 0a 0b 0c 0d
0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d
1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d
2e 2f 30 31 32 33 34 35 36 37
tutaj mozna (zeby nie szukac) obczaic https://hpd.gasmi.net/
Czyli do routera dociera ramka z TAG 2 (vlan switha) jak również 20 ->vlan na interfacie komputer
Re: QinQ a normalny access
To ciekawa sytuacja. Nie jestem pewien czy faktycznie dostajesz właściwy tag, a w dodatku zgodnie z moimi podejrzeniami, Nexusowy NX-OS też powinien zachowywać się w tej sytuacji normalnie - tzn. odrzucać dodatkowe tagi na portach zdefiniowanych jako access.
Zanim pójdziemy dalej - dobrze byłoby, żebyś otworzył case w TACu. Jeśli nadal jesteś na linii 7.x, sugerowałbym upgrade do najnowszej wersji lub w ogóle do 9.3(3). W ramach case'u, dobrze byłoby użyć np. ethanalyzera i sprawdzić co fizycznie dostajesz na wejściu i wyrzucasz do routera z perspektywy Nexusa.
Podczas dłubania w bazie danych TAC znalazłem jednak kilka case'ów z softem 7.x, w których faktycznie Nexus może dołączyć Ethertype 0x88a8 w zależności od tego w jaki sposób obsługiwany jest ruch wejściowy i wyjściowy."If an access port receives a packet with an 802.1Q tag in the header other than the access VLAN value, that port drops the packet without learning its MAC source address."
Zanim pójdziemy dalej - dobrze byłoby, żebyś otworzył case w TACu. Jeśli nadal jesteś na linii 7.x, sugerowałbym upgrade do najnowszej wersji lub w ogóle do 9.3(3). W ramach case'u, dobrze byłoby użyć np. ethanalyzera i sprawdzić co fizycznie dostajesz na wejściu i wyrzucasz do routera z perspektywy Nexusa.
Re: QinQ a normalny access
Zaraz tutaj spróbuje coś złapać.
Jestem świeży w cisco - wcześniej była bida - dopiero od niedawna mamy jakieś godne zabawki
Z TAC lup upgreadem będzie problem bo nie mam wsparcia wykupionego
ps. faktycznie mam NXOS: version 7.0(3)I7(3
Jestem świeży w cisco - wcześniej była bida - dopiero od niedawna mamy jakieś godne zabawki
Z TAC lup upgreadem będzie problem bo nie mam wsparcia wykupionego
ps. faktycznie mam NXOS: version 7.0(3)I7(3
Re: QinQ a normalny access
Wygląda prawie spoko - zalecana jest 7.0(3)I7(7 a mam ) 7.0(3)I7(3)
Ale wracając do kwestii.
To możliwe jest ze zmiana wersji oprogramowania zmieni coś tak fundamentalnego ? Chyba takie działanie trybu access nie jest przypadkiem i przeoczeniem w oprogramowaniu.
Próbuje ciągle przechwycić ten pakiet icmp na switchu ale coś mi tutaj nie łyka filtr
Ale wracając do kwestii.
To możliwe jest ze zmiana wersji oprogramowania zmieni coś tak fundamentalnego ? Chyba takie działanie trybu access nie jest przypadkiem i przeoczeniem w oprogramowaniu.
Próbuje ciągle przechwycić ten pakiet icmp na switchu ale coś mi tutaj nie łyka filtr
Re: QinQ a normalny access
A jak otrzymam już na port ruch z kilkoma vlanami z których jeden będzie miał jeszcze dodatkowe vlany w sobie to jak to roztagować ?lbromirs pisze: ↑17 lut 2020, 00:47 Coś się pokiełbasiło nieco. Ze swoich dawnych czasów security-switching-very-wszystko (pokazy różnych ataków i niszczenia młotkiem w trakcie ataku dalej chyba da się znaleźć na video), mogę powiedzieć, że:
1. Port w trybie 'access', odrzuci otagowaną ramkę. W części przełączników, dopuszczalne jest wysłanie ruchu otagowanego tym samym ID VLANu 802.1Q do którego należy port w trybie access - ale nic więcej. Tutaj Twoje obserwacje się nie zgadzają i mam wrażenie, że patrzysz albo nie na sprzęt Cisco, albo być może nie do końca dobrze skonfigurowałeś sprzęt. Jedynym wyjątkiem są tu porty ustawione jako 'voice' ale mam wrażenie, że takimi się nie posługujesz.
2. Port w trybie 'trunk' odbierze ramkę otagowaną RAZ. To spokojnie wystarcza dla sieci typu enterprise (ograniczenie skalowalności do 1024 lub 4096 różnych VLANów), ale nie wystarcza operatorom.
3. Port 'dot1q-tunnel', a właściwie taka funkcjonalność, pozwala przenieść ruch L2 odebrany od klienta, bez ingerencji w tagi - w bardzo prosty, podstawowy sposób. Załóżmy, że Twój klient chce używać VLANów 200, 300 i 500. A Ty dla transportu tego Klienta chcesz użyć w swojej sieci VLAN 2010. Konfiguracja portu w stronę klienta (on będzie miał trunk) wyglądać będzie tak:
Z tego co pamiętam, ograniczeniem jest tu Ethertype - przenoszone są ramki z 0x8100 i taka wartość jest też do ramek dodawana. Jeśli chcesz robić coś więcej, np. dodatkowo ramki CDP, LLDP i inne, musisz włączyć osobno Layer 2 Protocol Tunneling (L2PT, nie mylić z L2TP). Funkcjonalność może działać razem lub osobno od dot1q-tunneling, w zależności od konfiguracji i sprzętu.Kod: Zaznacz cały
sp-sw(config)#interface fastEthernet 0/1 sp-sw(config-if)#switchport access vlan 2010 sp-sw(config-if)#switchport mode dot1q-tunnel
W zależności od sprzętu i wersji softu - na Catalystach i routerach z IOSem może zdarzyć się, że będziesz miał możliwość dodawania drugiego taga (tzw. QinQ termination), przez wskazanie podwójnego tagowania przy opisie hermetyzacji (np. encapsulation dot1q 300 second-dot1q 100-199), natomiast na przełącznikach Metro Ethernet i sprzęcie operatorskim masz całą infrastrukturę EVC, która pozwala robić prawie dowolne cuda z sekwencjami zdejmowania, dodawania i mapowania VLANów (tagów).
Teoretycznie pasował by tryb "mieszany"
tj. ACCESS dla QinQ (wtedy zdejmie z niego "górny" znacznik) i trunk dla pozostałych vlanów które chcemy zachować
Re: QinQ a normalny access
"A jak otrzymam już na port ruch z kilkoma vlanami z których jeden będzie miał jeszcze dodatkowe vlany w sobie to jak to roztagować ?"
Straciłem przytomność przy drugim 'vlany'. Możesz proszę podkręcić jasność wypowiedzi?
Straciłem przytomność przy drugim 'vlany'. Możesz proszę podkręcić jasność wypowiedzi?
Re: QinQ a normalny access
Na port ethernet 1/1 mam trunk iwchodzi mi vlan 2,3,4 z tym że vlan 4 ma w sobie vlan 100,200
na ethernet 1/2 chcial bym trunk alloved vlan 2
na ethernet 1/3 chcial bym trunk alloved vlan 3
na ethernet 1/4 chcial bym trunk alloved vlan 100
na ethernet 1/5 chcial bym trunk alloved vlan 200
Czyli ściągnąć zewnetrzny znacznik vlan 4
na ethernet 1/2 chcial bym trunk alloved vlan 2
na ethernet 1/3 chcial bym trunk alloved vlan 3
na ethernet 1/4 chcial bym trunk alloved vlan 100
na ethernet 1/5 chcial bym trunk alloved vlan 200
Czyli ściągnąć zewnetrzny znacznik vlan 4
Re: QinQ a normalny access
Czyli na porcie 1/1 dostajesz ramkę ethernet z trzema tagami potencjalnie? 4|100|200? Nieźle.
Do manipulacji tagami potrzebujesz EVC, Nexus nie obsługuje EVC. Rzuć okiem np. tutaj: https://community.cisco.com/t5/networki ... -p/3108219
Do manipulacji tagami potrzebujesz EVC, Nexus nie obsługuje EVC. Rzuć okiem np. tutaj: https://community.cisco.com/t5/networki ... -p/3108219
Re: QinQ a normalny access
na porcie 1/1 dostaje 3 różne vlany.lbromirs pisze: ↑20 lut 2020, 23:33 Czyli na porcie 1/1 dostajesz ramkę ethernet z trzema tagami potencjalnie? 4|100|200? Nieźle.
Do manipulacji tagami potrzebujesz EVC, Nexus nie obsługuje EVC. Rzuć okiem np. tutaj: https://community.cisco.com/t5/networki ... -p/3108219
Z czego pakiety z vlanem 4 moga należeć do cvlan-u 100 lub 200 jeszcze
Re: QinQ a normalny access
W prosty sposob tego nie zrobisz na tym urzadzeniu. Trzeba je wymienic, albo kombinowac. Mozesz np. zapiac petle miedzy dwoma portami tego switcha. Na jednym dodajesz vlan 4 jako access z wlaczonym dot1q-tunnel a na drugim odbierasz c-vidy w zwyklym trunku.