QinQ a normalny access

Problemy związane ze switchingiem
Wiadomość
Autor
radczenko
member
member
Posty: 17
Rejestracja: 15 lut 2020, 22:19

QinQ a normalny access

#1

#1 Post autor: radczenko »

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 ?

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

Re: QinQ a normalny access

#2

#2 Post autor: lbromirs »

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.

radczenko
member
member
Posty: 17
Rejestracja: 15 lut 2020, 22:19

Re: QinQ a normalny access

#3

#3 Post autor: radczenko »

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 ?

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

Re: QinQ a normalny access

#4

#4 Post autor: lbromirs »

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:

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
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).

radczenko
member
member
Posty: 17
Rejestracja: 15 lut 2020, 22:19

Re: QinQ a normalny access

#5

#5 Post autor: radczenko »

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

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

Re: QinQ a normalny access

#6

#6 Post autor: lbromirs »

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.
"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."
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.

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.

radczenko
member
member
Posty: 17
Rejestracja: 15 lut 2020, 22:19

Re: QinQ a normalny access

#7

#7 Post autor: radczenko »

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

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

Re: QinQ a normalny access

#8

#8 Post autor: lbromirs »


radczenko
member
member
Posty: 17
Rejestracja: 15 lut 2020, 22:19

Re: QinQ a normalny access

#9

#9 Post autor: radczenko »

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

radczenko
member
member
Posty: 17
Rejestracja: 15 lut 2020, 22:19

Re: QinQ a normalny access

#10

#10 Post autor: radczenko »

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:

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
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).
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ć ?
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ć

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

Re: QinQ a normalny access

#11

#11 Post autor: lbromirs »

"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?

radczenko
member
member
Posty: 17
Rejestracja: 15 lut 2020, 22:19

Re: QinQ a normalny access

#12

#12 Post autor: radczenko »

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

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

Re: QinQ a normalny access

#13

#13 Post autor: lbromirs »

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

radczenko
member
member
Posty: 17
Rejestracja: 15 lut 2020, 22:19

Re: QinQ a normalny access

#14

#14 Post autor: radczenko »

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
na porcie 1/1 dostaje 3 różne vlany.
Z czego pakiety z vlanem 4 moga należeć do cvlan-u 100 lub 200 jeszcze

tasior
Server Admin
Posty: 166
Rejestracja: 19 sie 2013, 14:44

Re: QinQ a normalny access

#15

#15 Post autor: tasior »

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.

ODPOWIEDZ