VTP - problem z revision number w PT 5.3

Wiadomość

Tompa · #1

Witam wszystkich,

Ostatnimi czasy szykuję się do CCNA i aktualnie wałkuje temat VTP na PT ver. 5.3 . Przy ostatnio testowanym scenariuszu naszły mnie pewne wątpliwości które mam nadzieje uda wam się mi wyjaśnić

Do rzeczy:

Topologia następująca:

PC0 ------- Switch 0 --------- Switch 1 ------- PC1

Pc'ty są tylko dla picu i nic nie wnoszą. Łącze pomiędzy Switchami jest na początku scenariusza nie ruszane (czyli nie ma tam trunk'a).

Konfiguracja wpisywana chronologicznie wygląda następująco:

Switch 0:

Switch(config)#interface vlan 1
Switch(config-if)#ip address 192.168.1.1 255.255.255.0
Switch(config-if)#no shutdown

Switch(config)#vlan 23
Switch(config-vlan)#name switch0
Switch(config-vlan)#exit
Switch(config)#
Switch(config)#vtp mode server
Device mode already VTP SERVER.
Switch(config)#
Switch(config)#vtp domain tompa
Changing VTP domain name from NULL to tompa

Komendy show wyglądają następująco na switchu 0:

Switch#show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 6
VTP Operating Mode : Server
VTP Domain Name : tompa
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0xE2 0x56 0x42 0xC3 0xF8 0x9C 0x54 0xEB
Configuration last modified by 192.168.1.1 at 3-1-93 00:01:59
Local updater ID is 192.168.1.1 on interface Vl1 (lowest numbered VLAN interface found)

Switch#show vlan brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Fa0/24
23 switch0 active

Revision number = 0 z powodu zmiany domeny z domyślnego Null na tompa. Przynajmniej tak to rozumiem.

Konfiguracja na Switch'u 1:

Switch(config)#interface vlan 1
Switch(config-if)#ip ad
Switch(config-if)#ip address 192.168.1.2 255.255.255.0
Switch(config-if)#no shutdown

Switch(config)#vlan 75
Switch(config-vlan)#name switch1
Switch(config-vlan)#exit
Switch(config)#
Switch(config)#vtp mode client
Setting device to VTP CLIENT mode.
Switch(config)#vtp domain tompa
Changing VTP domain name from NULL to tompa
Switch(config)#exit

Komendy show na Switchu 1:

Switch#show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 6
VTP Operating Mode : Client
VTP Domain Name : tompa
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x32 0x37 0xCB 0xEC 0x98 0x86 0x50 0xED
Configuration last modified by 192.168.1.2 at 3-1-93 00:02:40
Switch#show vlan brief

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Fa0/24
75 switch1 active

Następnie włączyłem na łączu pomiędzy Switch'ami trunk, by VTP mogło zacząć rozsyłać swoje wiadomości.

Na switchu 0 wpisałem:

Switch(config)#interface fastEthernet 0/2
Switch(config-if)#switchpo
Switch(config-if)#switchport mode trunk

I teraz meritum. Wydawało mi się, że w tym przypadku oba switche posiadające ten sam revision number zachowają swoją konfiguracje (Vlan 23 na switchu 0, i vlan 75 na switchu 1) . Jednakże po podniesieniu trunku, Switch 1 przyjął konfiguracje od switcha 0 pomimo takiego samego revision number. Zrzut ze switcha 1 wygląda następująco:

Switch#show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 255
Number of existing VLANs : 6
VTP Operating Mode : Client
VTP Domain Name : tompa
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0xE2 0x56 0x42 0xC3 0xF8 0x9C 0x54 0xEB
Configuration last modified by 192.168.1.1 at 3-1-93 00:01:59

Switch#show vlan

VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/10, Fa0/11, Fa0/12, Fa0/13
Fa0/14, Fa0/15, Fa0/16, Fa0/17
Fa0/18, Fa0/19, Fa0/20, Fa0/21
Fa0/22, Fa0/23, Fa0/24
23 switch0 active

Czy jest to błąd PT ? Czy rzeczywiście tak powinno się to zachować? Jeśli tak to gdzie jest błąd w moim rozumowaniu? Dziękuje z góry za każdą pomoc!

Pozdrawiam!

ba10 · #2

Moim zdaniem poprawnie

Numer rewizji zmienia się wtedy kiedy na serwerze dodajesz jakiś vlan.
Switche muszą od czegoś wyjść, więc musi być wspólna konfiguracja vlanów u wszystkich taka sama i jaką przesyłał serwer vtp.
Na kliencie nie możesz edytować vlanów, bo klient tylko odbiera ustawienia z serwera vtp i na tej podstawie konfiguruje swoje ustawienia.

Tompa · #3

Re: ba10
Dzięki za odpowiedź!

Chyba nie do końca jednak jest tak jak mówisz. W materiałach cisco, jest wyraźnie napisane, że aktualizacja danych o VLAN'ach przez VTP następuje tylko jeśli w odebranej wiadomości VTP zgadza się domena, opcjonalnie hasło i rev number jeśli jest większy od aktualnego na urządzeniu (client lub serwer). Poza tym według materiałów (Odom) klient i serwer VTP działają identycznie (obydwa wysyłają i przetwarzają wiadomości) z jedyną różnicą taką, że na kliencie jest zablokowane dodawanie VLAN'ów.

W innych symulacjach które zrobiłem jest to potwierdzone, jakby ten client miał uprzednio dodane kilka VLAN'ów tak by jego rev number był większy od rev number servera, to server by przyjął konfiguracje klienta. Jedynie ten scenariusz dał mi wyniki których nie potrafię zinterpretować

Może jeszcze komuś uda mnie się oświetlić

Dzięki jeszcze raz z góry!

ba10 · #4

Oczywiście, że w tym danym przypadku, bo jego rozważamy , jest tak jak mówie i w PT i na switchach fizycznych. Jeśli oby dwa switche klient i serwer maja te same numery rewizji to klient przyjmie konfiguracje z serwera vtp bo serwer jest nadrzędny czyli nad klientem. Nie umiem tego prościej napisać.

Na kliencie tak jak napisałem wcześniej, nie można edytować Vlanów czyli dodawać ale także usuwać czy modyfikować istniejących.
Serwer synchronizuje konfiguracje VLAN w danej domenie opierając się na wiadomościach przesyłanych przez trunk.
Tutaj jakoś nie ma głębszej filozofii

Tompa · #5

Wnioskuje z twojego posta, że miałeś możliwość sprawdzenia tego na rzeczywistym sprzęcie?

Nie mam problemu z przyjęciem do wiadomości, że w przypadku gdy rev number są równe to client przyjmie konfiguracje od servera. Mój problem polega na tym, że nigdzie nie potrafię w materiałach znaleźć potwierdzenia takiego zachowania.

Na stronie cisco: http://www.cisco.com/en/US/tech/tk389/t ... 4c52.shtml

Server—In VTP server mode, you can create, modify, and delete VLANs and specify other configuration parameters, such as VTP version and VTP pruning, for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links. VTP server is the default mode.

Client—VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs on a VTP client.

oraz

When the switch receives a summary advertisement packet, the switch compares the VTP domain name to its own VTP domain name. If the name is different, the switch simply ignores the packet. If the name is the same, the switch then compares the configuration revision to its own revision. If its own configuration revision is higher or equal, the packet is ignored. If it is lower, an advertisement request is sent.

Co wydaje się zaprzeczać takiemu scenariuszowi, w Odomie również jest napisane, że rev number musi być większy by konfiguracja została przyjęta. Stąd wynika moje delikatne zagubienie w temacie. Ale jeśli sprawdziłeś to na rzeczywistym sprzęcie to zapewne musi tak być. Chociaż dziwi mnie wtedy pewna nie konsekwencja z materiałami.

Pozdr.

ba10 · #6

Tak, na rzeczywistym, fizycznym , namacalnym

Codziennie mam taką możliwośc

Serwer zarządza wszystkimi tymi informacjami o VLANach, by nie trzeba było "biegać" i zmieniać wszystkiego na oddzielnych urządzeniach, tylko na jednym i on juz dalej przekaże, to taki "zarządca" to on wydaje rozkazy i jego się trzeba słuchać

To jak master i slave

Kurcze braki mi już porównań

Dla mnie wydaje się to logiczne.
Masz sieć, i zepsuł się switch który pracował za vtp server. Podkładasz nowy, czysty, server vtp i on zbiera informacje od innych switchy w domenie i w mig masz wszystko na serverze , nie potrzebujesz klepać wszystkich vlanów ręcznie. I dział to w druga stronę, zepsuje się switch klient, podkładasz nowy skonfigurowany vtp client z domeną i masz zaraz vlany na nim. I w końcu przy tworzeniu nowej sieci te informacje do klientów od kogoś muszą iść, i właśnie do tego służy server i protokół vtp byś nie musiał "klepac" wszystkiego ręcznie i żeby klient pobrał sobie informacje. Jest to zwyczajny model klient-serwer. Być może gdy pisane były materiały, dla autorów było to bardzo oczywiste i dlatego nigdzie nie jest wspomniane o tym.

kkub · #7

A nie jest tak ,że zassała się konfiguracja na sw2 z powodu różnicy MD5 digest na urządzeniach , chociaż revision bylo takie same ?

ba10 · #8

@kkub
Raczej nie, MD5 nie ma tu nic do rzeczy, bo przeważnie jest używane do tego czy pakiet nie został zmodyfikowany, czyli czy jest poprawny.
Ale jak masz jakieś dokumenty na ten temat to się chętnie z nimi zapoznam.
@Tompa
W Catalyst 3560 Switch Command Reference, Release 12.2(58)SE w sekcji vtp (global configuration) przy opisie serwera i clienta są opisane zachowania przy "starcie" :
Serever :

Kod: Zaznacz cały

A switch in VTP server mode is enabled for VTP and sends advertisements.

Client

Kod: Zaznacz cały

When a VTP client starts up, it does not send VTP advertisements until it receives advertisements to initialize its VLAN database.

Myślę, że to powino wytłumaczyć całą sytuację.