Guestshell w Cisco Catalyst 9300
Może masz czasem potrzebę, aby podłączyć dwa komputery testowe do urządzeń sieciowych?
Testowaliśmy właśnie konfigurację VXLAN pomiędzy switchami Cisco Catalyst 9300 i w celu pełnego przetestowania rozwiązania potrzebne były dwa urządzenia testowe, co więcej powinny być w jednym vlanie rozciągniętym przez VXLAN. Tylko wyszło kilka problemów… switche są 10km od nas, jest weekend … i załatwienie wejścia do serwerowni i testy to zabawa na cały dzień.
Trochę dużo, aby sprawdzić, czy dana komunikacja działa. Co zrobić?
Z pomocą przychodzi guestshell, czyli Linux wbudowany w switch. Można sobie uruchomić taką instancję wirtualną i połączyć ją ze switchem. Instrukcji konfiguracji jest pełno – połączenie po L3 z urządzeniem. Ale czy można zrobić połączenie po L2 i wrzucić wirtualkę do vlanu i dalej rozciągnąć po VXLAN na odległy site? I to jest jeszcze po interfejsie AppGigEth1/0/1 – fizycznym interfejsie wewnętrznym podłączonym do maszyny wirtualnej. Na switchu można instalować kontenery i maszyny wirtualne, ale bez dodatkowego dysku (którego tutaj nie mieliśmy) pozostaje nam guestshell.
Oczywiście da się! Co prawda pewne braki w dokumentacji powodują, że trwało to dobre 2 godziny, ale się udało.
Na początku była masa błędów podczas startu linuxa, na przykład:
#guestshell enable
Interface will be selected if configured in app-hosting
Please wait for completion
% Error: App Activation error: Cannot have trunk and access vlan for two interfaces simultaneously
Próbowałem skonfigurować też interfejs pod linuksem
[guestshell@guestshell ~]$ sudo ifconfig eth1 up
SIOCSIFFLAGS: Operation not permitted
Niestety interfejsy wirtualki, można konfigurować tylko z poziomu switcha. W końcu, trochę po omacku, udało się znaleźć poprawną konfigurację interfejsu
interface AppGigabitEthernet1/0/1
switchport mode trunk
app-hosting appid guestshell
app-vnic AppGigabitEthernet trunk
vlan 100 guest-interface 1
guest-ipaddress 10.117.117.204 netmask 255.255.255.248
app-default-gateway 10.117.117.201 guest-interface 1
#guestshell enable
Interface will be selected if configured in app-hosting
Please wait for completion
guestshell installed successfully
Current state is: DEPLOYED
guestshell activated successfully
Current state is: ACTIVATED
guestshell started successfully
Current state is: RUNNING
Guestshell enabled successfully
#guestshell
[guestshell@guestshell ~]$ sudo ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
47: eth1@if48: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 52:54:dd:5f:52:92 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.117.117.204/29 brd 10.117.117.207 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::5054:ddff:fe5f:5292/64 scope link
valid_lft forever preferred_lft forever
[guestshell@guestshell ~]$ ping 10.117.117.202
PING 10.117.117.202 (10.117.117.202) 56(84) bytes of data.
64 bytes from 10.117.117.202: icmp_seq=1 ttl=254 time=0.912 ms
64 bytes from 10.117.117.202: icmp_seq=2 ttl=254 time=0.828 ms
I już!
Mamy linuksa podłączonego do interfejsu. Co pozostało? Podłączyć na dwóch końcach dwa guestshell i sprawdzić komunikację. Jak widać na poniższym screenie wszystko działa poprawnie, mamy nawet potwierdzenie z tcpdump, że pakiety docierają na drugą stronę.
Bardzo ciekawa funkcjonalność! W końcu jak inaczej podłączyć dwa hosty do odległych switchy nie wychodząc z domu ?
Dodam tylko, że nowe switche wspierają hostowanie różnych aplikacji oraz wspierają kontenery dockera.
autorem artykułu jest:
Piotr Szafran Dyrektor – techniczny/CEO w Network Experts Sp. z o.o. sp. k.
Posiada ponad 15 lat doświadczenia w dużych sieciach operatorskich jak i enterprise. Realizował projekty jako inżynier w Citibank oraz Główny Architekt sieci Exatela, zrealizował projekty za ponad 10M USD.
Masz pytania? Napisz
