Alegerea DR in OSPF – răspuns

V-am rămas dator cu un răspuns de aici, nu? Aveţi mai jos post-ul meu pe forumul studenţilor (le promisesem la curs că refac topologia, verific, şi postez rezultatul final).

Topologia era formată din 3 router-e în stea (R1, R2, R3), pentru care ID-urile erau (în ordine) 172.16.1.1, 1.2, şi 1.3.

După cum v-am promis la curs, am verificat pe echipamente dacă alegerea DR în OSPF este sau nu este preemptivă (adică: dacă vine un router cu un ID mai bun, poate să dea jos DR-ul?) . Toată documentația spune că nu este, dar se pare că a existat un laborator la care rezultatele au fost altele.

Verificarea a fost făcută pe 3 routere 2801, legate toate într-un switch. IOS: 12.4(9)T

IP-uri: 192.168.1.1, 192.168.1.2, și 192.168.1.3. ( /24 )
Router ID-uri: 172.16.1.1, 172.16.2.2, 172.16.3.3

Rezultate:

  1. pornesc OSPF pe R1. După un timp, am:
  2. R1#sh ip ospf int f0/0
    FastEthernet0/0 is up, line protocol is up
    Internet Address 192.168.1.1/24, Area 0
    Process ID 1, Router ID 172.16.1.1, Network Type BROADCAST, Cost: 1
    Transmit Delay is 1 sec, State DR, Priority 1

  3. pornesc OSPF și pe R2. Obțin:
  4. R2#sh ip ospf int f0/0 FastEthernet0/0 is up, line protocol is up
    Internet Address 192.168.1.2/24, Area 0
    Process ID 1, Router ID 172.16.2.2, Network Type BROADCAST, Cost: 1
    Transmit Delay is 1 sec, State BDR, Priority 1
    Designated Router (ID) 172.16.1.1, Interface address 192.168.1.1

    Observați că router-ul 2, deși are un ID mai mare decât R1, nu i-a luat acestuia locul ca DR, și s-a mulțumit cu rolul de BDR.

  5. pornesc OSPF pe R3 (router-ul cu cel mai mare ID din toate)Rezultat:
  6. R3#sh ip ospf int f0/0
    FastEthernet0/0 is up, line protocol is up
    Internet Address 192.168.1.3/24, Area 0
    Process ID 1, Router ID 172.16.3.3, Network Type BROADCAST, Cost: 1
    Transmit Delay is 1 sec, State DROTHER, Priority 1
    Designated Router (ID) 172.16.1.1, Interface address 192.168.1.1
    Backup Designated router (ID) 172.16.2.2, Interface address 192.168.1.2

    Router-ul 3 nu mai găsește nici un loc, și rămâne DROTHER.

  7. Închid interfața de pe R1 (actualul DR). Ce văd pe R2:
  8. Dec 6 09:58:50.019: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

    R2#sh ip ospf int f0/0
    FastEthernet0/0 is up, line protocol is up
    Internet Address 192.168.1.2/24, Area 0
    Process ID 1, Router ID 172.16.2.2, Network Type BROADCAST, Cost: 1
    Transmit Delay is 1 sec, State DR, Priority 1
    Designated Router (ID) 172.16.2.2, Interface address 192.168.1.2
    Backup Designated router (ID) 172.16.3.3, Interface address 192.168.1.3

    Router-ul 2 (fostul BDR) este promovat automat ca DR (deși există un router cu ID mai mare în rețea!). Pentru BDR are loc o nouă alegere, în urma căreia R3 devine BDR.

  9. Repornesc interfața de pe R1. Și obțin:
  10. R1#sh ip ospf int f0/0
    FastEthernet0/0 is up, line protocol is up
    Internet Address 192.168.1.1/24, Area 0
    Process ID 1, Router ID 172.16.1.1, Network Type BROADCAST, Cost: 1
    Transmit Delay is 1 sec, State DROTHER, Priority 1
    Designated Router (ID) 172.16.2.2, Interface address 192.168.1.2
    Backup Designated router (ID) 172.16.3.3, Interface address 192.168.1.3

    Router-ul 1 a rămas ca DROTHER.

  11. Și o ultimă verificare: închid interfața de pe R3, și o repornesc (poate-poate așa o să vrea să ia el locul DR-ului):
  12. R3#sh ip ospf int f0/0
    FastEthernet0/0 is up, line protocol is up
    Internet Address 192.168.1.3/24, Area 0
    Process ID 1, Router ID 172.16.3.3, Network Type BROADCAST, Cost: 1
    Transmit Delay is 1 sec, State DR, Priority 1
    Designated Router (ID) 172.16.3.3, Interface address 192.168.1.3
    Backup Designated router (ID) 172.16.1.1, Interface address 192.168.1.1

    Aici a venit surpriza – R3 ii ia locul DR-ului! Totuși, observați că BDR-ul este R1, așa că procesul nu este… chiar cum ne-am aștepta dacă ar fi cu adevărat preemptiv.

Am repetat operațiunea de mai multe ori, cu același rezultat:

  • la pornirea procesului, router-ul nou apărut nu ia locul DR-ului (procesul de elecție nu este preemptiv)
  • la închiderea și repornirea interfeței, router-ul revine pe postul de DR.

Se explică acum comportamentul diferit la cele două laboratoare. Totuși, comportamentul diferit nu se datorează faptului că procesul de elecție ar fi devenit preemptiv în IOS-urile noi. Impresia mea este că router-ele țin minte fostul DR, și îl lasă să își reia locul atunci când revine în rețea.
Nu găsesc nicăieri în documentație ceva care să spună că așa este, dar am făcut următorul experiment (care pare să îmi dea dreptate):

  • închid interfața de pe R3. R1 devine DR, R2 devine BDR.
  • închid și interfața de pe R2. R1 devine DR, pentru că a rămas singur. Totuși, ține minte că înaintea lui a fost DR router-ul 2
  • repornesc interfața pe R3. R1 nu îl mai recunoaște ca fiind fostul DR, și ca urmare nu îl mai lasă să își reia locul. R1 rămâne DR, și R3 devine BDR.

În plus, un debug ospf adjacency îmi confirmă bănuiala:

Dec 6 17:16:07.678: OSPF: DR/BDR election on FastEthernet0/0
<—-output ommitted—->
Dec 6 17:16:07.678: OSPF: Remember old DR 172.16.3.3 (id)

Concluzie – procesul de elecție a DR NU este preemptiv, dar poate da uneori această impresie (prin faptul că ține minte fostul DR).

4 Comments »

  1. Fuzzy Said,

    December 15, 2007 @ 2:36

    Întâmplare face ca tocmai astăzi mi-am aruncat ochii peste capitolul OSPF din cartea de la CISCO Press pentru CCNA.
    Acolo spune destul de clar că în cazul în care apare un ID mai bun nu îi va ceda imediat acestuia locul ci numai în cazul extraordinar în care link-ul este pierdut cu DR-ul actual şi se fac din nou alegeri, însă odată ce router-ul cu ID mai bun devine DR el nu va mai ceda locul.
    Este chiar şi un notice subliniat pe tema asta în carte (care nu are multe aseamănări cu cursul, fiindui net superioară).

  2. NullCode Said,

    December 17, 2007 @ 23:30

    Interesant . Abia acum o sa ma documentez si eu in domeniul OSPF ( abia acum am ajuns la capitolul acesta ) si o postez si eu parerea mea 😉

  3. simionov daniel Said,

    October 2, 2008 @ 0:08

    am testat si eu ce zici matale aici, si nu e asa cum zici. routerul 3 desi a fost DR, nu mai revine DR de nici o culoare. poate din cauza ca am asteptat eu sa fie considerat dead?

    ios c3725-adventerprisek9-mz.124-15.T5

    am incercat si eu de mai multe ori. nu revine.

  4. bogd Said,

    October 5, 2008 @ 23:49

    @daniel: este posibil ca acest comportament să depindă de IOS (deși eu unul l-am văzut pe cel puțin 3 IOS-uri diferite, din gama 12.2-12.3).

    Am retestat acum pe un 12.3(14)T, și comportamentul se menține:

    ROM: 3600 Software (C3640-JK9O3S-M), Version 12.3(14)T7, RELEASE SOFTWARE (fc2)

    *Mar 1 00:08:31.591: OSPF: Remember old DR 192.168.99.2 (id)

    Nu îmi este clar totuși la ce te referi prin „am așteptat să fie considerat dead” – dacă te referi la dead interval, oricum nu i-ar fi luat nimeni locul DR-ului până nu expira acel interval 🙂

RSS feed for comments on this post · TrackBack URI

Leave a Comment