bfd echo mode

[pjeter]

Ello.

Ustawienia BFD:
hello: 250ms
min_rx: 250ms
dead: 4 x 250 ms
bez echo
interfejsy prawie puste
obciążenie supa 1%

ECHO wyłączone:

Kod: Zaznacz cały

Session state is UP and not using echo function.
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 250000, MinRxInt: 250000, Multiplier: 4
Received MinRxInt: 250000, Received Multiplier: 4
Holddown (hits): 952(0), Hello (hits): 250(2714)
Rx Count: 1826, Rx Interval (ms) min/max/avg: 188/256/221 last: 48 ms ago
Tx Count: 1829, Tx Interval (ms) min/max/avg: 192/252/220 last: 212 ms ago

1) Pytanie: co gdy na DWDMie padnie transmisja w jedną stronę (utrzymując oczywiście interfejsy UP/UP) i zrobi się link jednokierunkowy ? BFD od strony która przestała otrzymywać keepalive'y powiadomi ISISa który IMO powinien wysłać do neighbora (działającym włóknem) pakiet zamknięcia sesji ISISa, ale czy tak będzie ? Bo jeśli nie skutki mogą być opłakane.
Jakieś doświadczenia ?

2) Echo mode by rozwiązało ten problem gdyby nie odległość węzłów (przykładowo Łódź-Katowice) -> max RTT delay raportowany przed BFD sięga nawet 1400 ms , podczas gdy na interfejsie skonfigurowany dead to 4 x 250 ms.

3) Zauważyłem że przy echo mode sam zmienia sie min_rx - czy to oznacza że dead w tym wypadku to 4000 ms ?
(timery w konfiguracji nie zmieniane, same się zmieniają)
ECHO:

Kod: Zaznacz cały

Session state is UP and using echo function with 250 ms interval.
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 4
Received MinRxInt: 1000000, Received Multiplier: 4
Holddown (hits): 0(0), Hello (hits): 1000(217)
Rx Count: 219, Rx Interval (ms) min/max/avg: 1/1484/872 last: 840 ms ago
Tx Count: 218, Tx Interval (ms) min/max/avg: 4/1000/877 last: 552 ms ago

PJ

[gangrena]

1) Pytanie: co gdy na DWDMie padnie transmisja w jedną stronę (utrzymując oczywiście interfejsy UP/UP) i zrobi się link jednokierunkowy ? BFD od strony która przestała otrzymywać keepalive'y powiadomi ISISa który IMO powinien wysłać do neighbora (działającym włóknem) pakiet zamknięcia sesji ISISa, ale czy tak będzie ? Bo jeśli nie skutki mogą być opłakane.
Jakieś doświadczenia ?

Poki co, implementacje IGP niestety nie maja mechanizmow obslugi polaczen jednokierunkowych. Sasiad, ktory przekroczyl holdtime nie jest powiadamiany.

2) Echo mode by rozwiązało ten problem gdyby nie odległość węzłów (przykładowo Łódź-Katowice) -> max RTT delay raportowany przed BFD sięga nawet 1400 ms , podczas gdy na interfejsie skonfigurowany dead to 4 x 250 ms.

A mierzyles RTT innym sposobem? RTT wskazywany przez BFD z uruchomionym echo daje dziwne wskazania, co wiaze sie ze zmienionymi timerami dla control packets. Rzeczywiste RTT masz pewnie na poziomie 200-400 ms

3) Zauważyłem że przy echo mode sam zmienia sie min_rx - czy to oznacza że dead w tym wypadku to 4000 ms ?
(timery w konfiguracji nie zmieniane, same się zmieniają)

Z tego co podaje Cisco, to pakiety echo wysylane sa dodatkowo oprocz standardowych control packets. Nie ma wiec potrzeby, by interval dla control packets byl taki sam, jak dla echo. Stad automatyczne zwiekszenie wartosci do 1 sekundy. Mozna to jeszcze zwiekszyc poprzez "bfd slow-timers". IMHO timery BFD, ktore ustawiasz na interfejsie odnosza sie tylko do echo BFD, a nie do control packets. Wychodzi wiec na to, ze echo powinno miec holdtime = 4x250 ms. 4 sekundy, to bylby deadtime dla control packets.

[pjeter]

Dzięki, przetrawię to co napisałeś i pewnie wrócę do wątku za jakiś czas. :)

PJ

[8bubu8]

Czolem Panowie,

Poki co, implementacje IGP niestety nie maja mechanizmow obslugi polaczen jednokierunkowych. Sasiad, ktory przekroczyl holdtime nie jest powiadamiany.

Bo to powinno "robic" bfd (oczywiscie o ile jest wlaczone dla danego IGP ):
Cytujac z http://tools.ietf.org/html/draft-ietf-b ... tion-6.8.6

Kod: Zaznacz cały

 Else (bfd.SessionState is Up)
              If received State is Down
                  Set bfd.LocalDiag to 3 (Neighbor signaled session down)
                  Set bfd.SessionState to Down

Jak dla mnie powyzszy zapis oznacza, ze sasiad bfd sygnalizuje zmiane stanu sesji bfd po swojej stronie sasiadowi.
Kiedy to robi? Tak szybko jak sie da, cytujac
http://tools.ietf.org/html/draft-ietf-b ... tion-6.8.7

A BFD Control packet SHOULD be transmitted during the interval
between periodic Control packet transmissions when the contents of
that packet would differ from that in the previously transmitted
packet (other than the Poll and Final bits) in order to more rapidly
communicate a change in state.

A mierzyles RTT innym sposobem? RTT wskazywany przez BFD z uruchomionym echo daje dziwne wskazania, co wiaze sie ze zmienionymi timerami dla control packets. Rzeczywiste RTT masz pewnie na poziomie 200-400 ms

Hmm a co maja timery do RTT?
Jak dla mnie PJeter, to co pokazujesz to nie jest RTT tylko czas a raczej interwal pomiedzy kolejnymi pakietami kontrolnymi bfd... A skoro min interval to 1s (slow timer) to i czasy wygladaja bardziej "ludzko"

Z tego co podaje Cisco, to pakiety echo wysylane sa dodatkowo oprocz standardowych control packets. Nie ma wiec potrzeby, by interval dla control packets byl taki sam, jak dla echo. Stad automatyczne zwiekszenie wartosci do 1 sekundy. Mozna to jeszcze zwiekszyc poprzez "bfd slow-timers". IMHO timery BFD, ktore ustawiasz na interfejsie odnosza sie tylko do echo BFD, a nie do control packets. Wychodzi wiec na to, ze echo powinno miec holdtime = 4x250 ms. 4 sekundy, to bylby deadtime dla control packets.

Pozwolcie, ze zacytuje:

"When you turn off echo packets, the detection mechanism is control
packets. Thus, control packets are running at the negotiated rate of
100ms (10 packets per second). When you turn on echo packets then the
detection mechanism are echo packets. Thus, echo packets are running at
the negotiated rate of 100ms and control packets are throttled back to
the slow rate (default 1 second)"

... i wszystko jasne

Pozdro
8bubu8

[gangrena]

Bo to powinno "robic" bfd (oczywiscie o ile jest wlaczone dla danego IGP ):
Cytujac z http://tools.ietf.org/html/draft-ietf-b ... tion-6.8.6

Kod: Zaznacz cały

 Else (bfd.SessionState is Up)
              If received State is Down
                  Set bfd.LocalDiag to 3 (Neighbor signaled session down)
                  Set bfd.SessionState to Down

Jak dla mnie powyzszy zapis oznacza, ze sasiad bfd sygnalizuje zmiane stanu sesji bfd po swojej stronie sasiadowi.

Parametry bfd.LocalDiag oraz bfd.SessionState sa ustawiane lokalnie na routerze, na ktorym przeprowadzany jest powyzszy algorytm. Poza tym przekroczenie holdtime nie jest rownowazne z otrzymaniem pakietu kontrolnego ze State=Down

Kiedy to robi? Tak szybko jak sie da, cytujac
http://tools.ietf.org/html/draft-ietf-b ... tion-6.8.7

A BFD Control packet SHOULD be transmitted during the interval
between periodic Control packet transmissions when the contents of
that packet would differ from that in the previously transmitted
packet (other than the Poll and Final bits) in order to more rapidly
communicate a change in state.

Ten fragment jest dobrym argumentem, ze control packet jest wysylany, tylko SHOULD pozostawia zbyt duza dowolnosc w implementacji

Hmm a co maja timery do RTT?
Jak dla mnie PJeter, to co pokazujesz to nie jest RTT tylko czas a raczej interwal pomiedzy kolejnymi pakietami kontrolnymi bfd... A skoro min interval to 1s (slow timer) to i czasy wygladaja bardziej "ludzko"

Rozpatrywalismy echo mode, wiec timery ustawiane dla tego trybu maja znaczenie w stosunku do RTT. Nie mozna ustawic tak wymagajacych timerow, jak dla control packets. Echo ma dwa razy dluzsza trase + czas przetworzenia przez router sasiedni.

Pozwolcie, ze zacytuje:

"When you turn off echo packets, the detection mechanism is control
packets. Thus, control packets are running at the negotiated rate of
100ms (10 packets per second). When you turn on echo packets then the
detection mechanism are echo packets. Thus, echo packets are running at
the negotiated rate of 100ms and control packets are throttled back to
the slow rate (default 1 second)"

O, wlasnie. Teoria poparta bezprzecznym cytatem

[8bubu8]

Parametry bfd.LocalDiag oraz bfd.SessionState sa ustawiane lokalnie na routerze, na ktorym przeprowadzany jest powyzszy algorytm. Poza tym przekroczenie holdtime nie jest rownowazne z otrzymaniem pakietu kontrolnego ze State=Down

Oczywiscie ze bfd.LocalDiag oraz bfd.SessionState sa lokalne dla routera odbierajacego pakiet
W naszym przypadku router lokalny ustawia je na podstawie pakietu kontrolnego (z ustawionym State na Down), ktory otrzymal od sasiada bfd.
Przekroczenie holdtime zdefiniowanego w http://tools.ietf.org/html/draft-ietf-b ... tion-6.8.4 powoduje wyslanie pakietu kontrolnego z ustawionym State=Down do drugiej strony bfd

A BFD Control packet SHOULD be transmitted during the interval
between periodic Control packet transmissions when the contents of
that packet would differ from that in the previously transmitted
packet (other than the Poll and Final bits) in order to more rapidly
communicate a change in state.

Ten fragment jest dobrym argumentem, ze control packet jest wysylany, tylko SHOULD pozostawia zbyt duza dowolnosc w implementacji

Masz troche racji Piotrek, mysle ze zostawili to SHOULD by nie utrudniac implementacji na roznych platformach (distributed forwarding vs centralized CPU).
Wg mnie sens powyzszego zdania jest taki ze zmiana stanu sesji bfd powinna byc sygnalizowana jak najszybciej (nawet pomiedzy kolejnymi pakietami kontrolnymi) a nie powinno sie czekac na kolejny pakiet kontrolny...

Rozpatrywalismy echo mode, wiec timery ustawiane dla tego trybu maja znaczenie w stosunku do RTT. Nie mozna ustawic tak wymagajacych timerow, jak dla control packets. Echo ma dwa razy dluzsza trase + czas przetworzenia przez router sasiedni.

Oczywiscie taka zaleznosc jak piszesz istnieje, natomiast ja mialem na mysli fakt iz manipulujac timerami _nie modyfikujesz_ RTT w sieci...

O, wlasnie. Teoria poparta bezprzecznym cytatem

I zdaje sie PJeter ja potwierdzil w praktyce

Pozdro
8bubu8

[gangrena]

Przekroczenie holdtime zdefiniowanego w http://tools.ietf.org/html/draft-ietf-b ... tion-6.8.4 powoduje wyslanie pakietu kontrolnego z ustawionym State=Down do drugiej strony bfd

Niestety nie zgodze sie. Fragment, ktory podales wspomina o ustawieniu parametrow np. bfd.SessionState na Down oraz bfd.LocalDiag na 1 (Control Detection Time Expired) dla Asynchronous mode. Nie ma natomiast (chyba, ze przeoczylem) algorytmu wyraznie mowiacego, ze "If the State of a received control packet = Down THEN send a the control packet with State = Down to neighbour". Tego mi brakuje w tym dokumencie.

Wg mnie sens powyzszego zdania jest taki ze zmiana stanu sesji bfd powinna byc sygnalizowana jak najszybciej (nawet pomiedzy kolejnymi pakietami kontrolnymi) a nie powinno sie czekac na kolejny pakiet kontrolny...

BFD wysyla pakiety unicast do sasiada. Jezeli widzi sasiada w stanie Down, to zglasza ten stan do IGP. Protokol routingu dezaktywuje sesje z sasiadem, a tym samym BFD nie ma juz informacji do kogo wyslac pakiet kontrolny. No chyba, ze ten jeden pakiet kontrolny jest wysylany przed powiadomieniem IGP.

Oczywiscie taka zaleznosc jak piszesz istnieje, natomiast ja mialem na mysli fakt iz manipulujac timerami _nie modyfikujesz_ RTT w sieci...

IMO, nikt nie wspominal o wplywie timerow na RTT, co najwyzej o RTT pakietu echo

I zdaje sie PJeter ja potwierdzil w praktyce

To dobra wiadomosc

[8bubu8]

Niestety nie zgodze sie. Fragment, ktory podales wspomina o ustawieniu parametrow np. bfd.SessionState na Down oraz bfd.LocalDiag na 1 (Control Detection Time Expired) dla Asynchronous mode. Nie ma natomiast (chyba, ze przeoczylem) algorytmu wyraznie mowiacego, ze "If the State of a received control packet = Down THEN send a the control packet with State = Down to neighbour". Tego mi brakuje w tym dokumencie.

A ten fragment? :

"A BFD Control packet SHOULD be transmitted during the interval
between periodic Control packet transmissions when the contents of
that packet would differ from that in the previously transmitted
packet (other than the Poll and Final bits) in order to more rapidly
communicate a change in state."

BFD wysyla pakiety unicast do sasiada. Jezeli widzi sasiada w stanie Down, to zglasza ten stan do IGP. Protokol routingu dezaktywuje sesje z sasiadem, a tym samym BFD nie ma juz informacji do kogo wyslac pakiet kontrolny. No chyba, ze ten jeden pakiet kontrolny jest wysylany przed powiadomieniem IGP.

Dokaladnie tak
My rozpatrujemy sytuacje ze sasiad _z naszego punktu widzenia_ ma dopiero byc Down (zgubilismy odpowiednia ilosc pakietow kontrolnych) czyli dopiero wykrywamy stan awarii sesji bfd. Wg mnie bfd wysyla wtedy do neighbora pakiet kontrolny z State=Down i powiadamia lokalny proces IGP ze neighbor padl, jednoczesnie deaktywujac dana sesje bfd

IMO, nikt nie wspominal o wplywie timerow na RTT, co najwyzej o RTT pakietu echo

"A mierzyles RTT innym sposobem? RTT wskazywany przez BFD z uruchomionym echo daje dziwne wskazania, co wiaze sie ze zmienionymi timerami dla control packets."

To dobra wiadomosc

I tu jestesmy calkowicie zgodni

Pozdro
8bubu8

[gangrena]

A ten fragment?

Jak dla mnie, ten fragment wciaz nie jest tak jednoznaczny, jak rozpisany algorytm dla ustawienia stanow sesji.

Wg mnie bfd wysyla wtedy do neighbora pakiet kontrolny z State=Down

Wyglada na to, ze najlepszy bylby test. Moze zrobimy CPOC?

"A mierzyles RTT innym sposobem? RTT wskazywany przez BFD z uruchomionym echo daje dziwne wskazania, co wiaze sie ze zmienionymi timerami dla control packets."

Ten fragment nie oznacza, ze "manipulujac timerami modyfikujesz RTT". On oznacza, ze "dziwne wskazania" wiaza sie ze zmienionymi timerami. Jak bowiem ustawienie timerow mogloby opoznic pakiet przesylany w sieci po opuszczeniu interfejsu? Logiczne jest, ze nie ma takiego wplywu. Pakiet moze byc co najwyzej pozniej wyslany przez router zrodlowy, co wynika z parametru interval, a scislej ze slow_timer.

[8bubu8]

Jak dla mnie, ten fragment wciaz nie jest tak jednoznaczny, jak rozpisany algorytm dla ustawienia stanow sesji.

Ok
Tak naprawde to jest tylko czesc algorytmu calego protokolu - ja bym to nazwal algorytmem ustawiania stanow sesji po otrzymaniu pakietu kontrolnego...

Wyglada na to, ze najlepszy bylby test. Moze zrobimy CPOC?

A zestawisz laba ?

Ten fragment nie oznacza, ze "manipulujac timerami modyfikujesz RTT". On oznacza, ze "dziwne wskazania" wiaza sie ze zmienionymi timerami. Jak bowiem ustawienie timerow mogloby opoznic pakiet przesylany w sieci po opuszczeniu interfejsu? Logiczne jest, ze nie ma takiego wplywu. Pakiet moze byc co najwyzej pozniej wyslany przez router zrodlowy, co wynika z parametru interval, a scislej ze slow_timer.

Po tych wyczerpujacych uzupelnieniach, chyba juz wiem co chciales napisac

Pozdr
8bubu8

[gangrena]

Tak naprawde to jest tylko czesc algorytmu calego protokolu - ja bym to nazwal algorytmem ustawiania stanow sesji po otrzymaniu pakietu kontrolnego

Tutaj zgadzam sie w zupelnosci. Przydalby sie tak jednoznaczny przyklad dla przekroczenia holdtime. Czesc draftu 6.8.7 nie mowi, czy control packet powinien byc wyslany w odpowiedzi na zmiane stanu, ktorej przyczyna byl czynnik zewnetrzny (czyli np. przekroczenie holdtime), czy tez czynnik wewnetrzny i czy w ogole na pewno. Moze juz wchodze w niepotrzebne dywagacje, ale w takim wypadku, router zdalny A, ktorego pakiety kontrolne BFD przestaly docierac do routera B, wyslalby rowniez pakiet kontrolny do A w odpowiedzi na pakiet kontrolny od routera B. Moze i tak byc. Przydaloby sie to przetestowac

A zestawisz laba ?

Ja bardzo chetnie. Serio