Bidirectional Forwarding Detection - Versionsgeschichte

Invisigoth67: typo

2024-06-17T14:16:46Z

typo

← Nächstältere Version		Version vom 17. Juni 2024, 16:16 Uhr
Zeile 1:		Zeile 1:
	'''Bidirectional Forwarding Detection''' ('''BFD'''), ist ein minimalistisches [[Nachrichtenverbindung\|verbindungsorientiertes]] [[Netzwerkprotokoll]] zur Erkennung von Fehlern zwischen zwei miteinander verbundenen [[Router]]n.		'''Bidirectional Forwarding Detection''' ('''BFD''') ist ein minimalistisches [[Nachrichtenverbindung\|verbindungsorientiertes]] [[Netzwerkprotokoll]] zur Erkennung von Fehlern zwischen zwei miteinander verbundenen [[Router]]n.

	Es wurde entwickelt, um die [[Konvergenzzeit]] in Netzen bei Störungen zu verkürzen. Die Bekanntgabe von Zustandsänderungen in [[Internet Protocol\|IP]]-Netzen ist mit BFD im Sub-Sekunden-Bereich möglich.		Es wurde entwickelt, um die [[Konvergenzzeit]] in Netzen bei Störungen zu verkürzen. Die Bekanntgabe von Zustandsänderungen in [[Internet Protocol\|IP]]-Netzen ist mit BFD im Sub-Sekunden-Bereich möglich.

Uweschwoebel: /* Einleitung */ Abk. eingeklammert

2024-02-26T21:32:39Z

Einleitung: Abk. eingeklammert

← Nächstältere Version		Version vom 26. Februar 2024, 23:32 Uhr
Zeile 1:		Zeile 1:
	'''Bidirectional Forwarding Detection'''~~, kurz~~ '''BFD''', ist ein minimalistisches [[Nachrichtenverbindung\|verbindungsorientiertes]] [[Netzwerkprotokoll]] zur Erkennung von Fehlern zwischen zwei miteinander verbundenen [[Router]]n.		'''Bidirectional Forwarding Detection''' ('''BFD'''), ist ein minimalistisches [[Nachrichtenverbindung\|verbindungsorientiertes]] [[Netzwerkprotokoll]] zur Erkennung von Fehlern zwischen zwei miteinander verbundenen [[Router]]n.

	Es wurde entwickelt, um die [[Konvergenzzeit]] in Netzen bei Störungen zu verkürzen. Die Bekanntgabe von Zustandsänderungen in [[Internet Protocol\|IP]]-Netzen ist mit BFD im Sub-Sekunden-Bereich möglich.		Es wurde entwickelt, um die [[Konvergenzzeit]] in Netzen bei Störungen zu verkürzen. Die Bekanntgabe von Zustandsänderungen in [[Internet Protocol\|IP]]-Netzen ist mit BFD im Sub-Sekunden-Bereich möglich.

Aka: /* Weblinks */ https, Dateigröße angepasst

2023-07-11T19:35:48Z

Weblinks: https, Dateigröße angepasst

← Nächstältere Version		Version vom 11. Juli 2023, 21:35 Uhr
Zeile 26:		Zeile 26:
	== Weblinks ==		== Weblinks ==
	* [https://datatracker.ietf.org/wg/bfd/ BFD-Arbeitsgruppe] der [[Internet Engineering Task Force\|IETF]]		* [https://datatracker.ietf.org/wg/bfd/ BFD-Arbeitsgruppe] der [[Internet Engineering Task Force\|IETF]]
	* [~~http~~://~~www~~.ripe.net~~/ripe/meetings~~/ripe-48/presentations/ripe48-eof-bfd.pdf BFD-Präsentation] (PDF) des Herstellers Juniper Networks, ripe.net		* [https://meetings.ripe.net/ripe-48/presentations/ripe48-eof-bfd.pdf BFD-Präsentation] (PDF; 1,0 MB) des Herstellers Juniper Networks, ripe.net
	* [~~http~~://www.networkworld.com/~~community~~/~~node~~/~~23380~~ Reducing Link Failure Detection Time with BFD.] In: Network World.		* [https://www.networkworld.com/article/2350201/reducing-link-failure-detection-time-with-bfd.html Reducing Link Failure Detection Time with BFD.] In: Network World.
	* BGP-Herstellerinformation von [~~http~~://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html Cisco] und [https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-bfd-understanding.html Juniper]		* BGP-Herstellerinformation von [https://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html Cisco] und [https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-bfd-understanding.html Juniper]

	== Einzelnachweise ==		== Einzelnachweise ==

PerfektesChaos: tk k

2023-06-25T13:16:01Z

tk k

← Nächstältere Version		Version vom 25. Juni 2023, 15:16 Uhr
Zeile 13:		Zeile 13:
	Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Intervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.		Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Intervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.

	Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol]] (RIP), das standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|~~EGP~~]]s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des „next hop“ der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.		Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol]] (RIP), das standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGPs]] kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des „next hop“ der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.

	BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.		BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.
Zeile 20:		Zeile 20:

	== Spezifikation ==		== Spezifikation ==
	BFD ist in ~~[[rfc:~~5880\|RFC 5880]] für die Erkennung von MPLS-LSP-Fehlern beschrieben.		BFD ist in <nowiki>RFC 5880</nowiki><ref>{{RFC-Internet \|RFC=5880 \|Titel=Bidirectional Forwarding Detection (BFD) \|Datum=2010-06}}</ref> für die Erkennung von MPLS-LSP-Fehlern beschrieben.

	Die Beschreibung der Interaktion zwischen BFD und der Routing-Protokolle OSPF und IS-IS erfolgte in ~~[[rfc:~~5881\|RFC 5881~~]].~~		Die Beschreibung der Interaktion zwischen BFD und der Routing-Protokolle OSPF und IS-IS erfolgte in <nowiki>RFC 5881</nowiki>.<ref>{{RFC-Internet \|RFC=5881 \|Titel=Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) \|Datum=2010-06}}</ref>

	== Weblinks ==		== Weblinks ==
	* [https://datatracker.ietf.org/wg/bfd/ BFD-Arbeitsgruppe] der IETF		* [https://datatracker.ietf.org/wg/bfd/ BFD-Arbeitsgruppe] der [[Internet Engineering Task Force\|IETF]]
	* [http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-eof-bfd.pdf BFD-Präsentation] des Herstellers Juniper Networks		* [http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-eof-bfd.pdf BFD-Präsentation] (PDF) des Herstellers Juniper Networks, ripe.net
	* ~~Artikel in der Network World:~~ [http://www.networkworld.com/community/node/23380 Reducing Link Failure Detection Time with BFD]		* [http://www.networkworld.com/community/node/23380 Reducing Link Failure Detection Time with BFD.] In: Network World.
	* BGP-Herstellerinformation von [http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html Cisco] und [https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-bfd-understanding.html Juniper]		* BGP-Herstellerinformation von [http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs_bfd.html Cisco] und [https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-bfd-understanding.html Juniper]

			== Einzelnachweise ==
			<references />

	[[Kategorie:Netzwerkprotokoll]]		[[Kategorie:Netzwerkprotokoll]]

Pladdin: Tippfehler korrigiert.

2017-07-30T20:58:49Z

Tippfehler korrigiert.

← Nächstältere Version		Version vom 30. Juli 2017, 22:58 Uhr
Zeile 13:		Zeile 13:
	Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Intervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.		Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Intervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.

	Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol]] (RIP), das standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|~~EGB~~]]s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des „next hop“ der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.		Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol]] (RIP), das standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGP]]s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des „next hop“ der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.

	BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.		BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.

Wikinger08: QS beendet: Typo, Typo, Typo

2017-06-01T09:08:01Z

QS beendet: Typo, Typo, Typo

← Nächstältere Version		Version vom 1. Juni 2017, 11:08 Uhr
Zeile 1:		Zeile 1:
		⚫	'''Bidirectional Forwarding Detection''', kurz '''BFD''', ist ein minimalistisches [[Nachrichtenverbindung\|verbindungsorientiertes]] [[Netzwerkprotokoll]] zur Erkennung von Fehlern zwischen zwei miteinander verbundenen [[Router]]n.
	{{QS-Antrag\|25. April 2017\|2=vollprogramm, sofern relevant--[[Benutzer:Lutheraner\|Lutheraner]] ([[Benutzer Diskussion:Lutheraner\|Diskussion]]) 16:25, 25. Apr. 2017 (CEST)}}

⚫	'''Bidirectional Forwarding Detection''', kurz '''BFD''', ist ein minimalistisches [[Nachrichtenverbindung\|verbindungsorientiertes]] [[Netzwerkprotokoll]] zur Erkennung von Fehlern zwischen zwei miteinander ~~verbundene~~ [[Router]]~~<nowiki/>~~n.

	Es wurde entwickelt, um die [[Konvergenzzeit]] in Netzen bei Störungen zu verkürzen. Die Bekanntgabe von Zustandsänderungen in [[Internet Protocol\|IP]]-Netzen ist mit BFD im Sub-Sekunden-Bereich möglich.		Es wurde entwickelt, um die [[Konvergenzzeit]] in Netzen bei Störungen zu verkürzen. Die Bekanntgabe von Zustandsänderungen in [[Internet Protocol\|IP]]-Netzen ist mit BFD im Sub-Sekunden-Bereich möglich.

	BFD arbeitet mit geringem Protokoll-[[Overhead (EDV)\|Overhead]] auch auf Medien, die ~~selber~~ über keine oder nur eine eingeschränkte bzw. träge Fehlererkennungsmöglichkeit verfügen. Hierzu gehören beispielsweise ''Virtual Circuits'' (VC) im [[Synchrone Digitale Hierarchie\|SDH]]-Umfeld, IP-Tunnel-Verbindungen und [[Multiprotocol Label Switching\|MPLS]]-Label-Switched-Pfade (LSP).		BFD arbeitet mit geringem Protokoll-[[Overhead (EDV)\|Overhead]] auch auf Medien, die selbst über keine oder nur eine eingeschränkte bzw. träge Fehlererkennungsmöglichkeit verfügen. Hierzu gehören beispielsweise ''Virtual Circuits'' (VC) im [[Synchrone Digitale Hierarchie\|SDH]]-Umfeld, IP-Tunnel-Verbindungen und [[Multiprotocol Label Switching\|MPLS]]-Label-Switched-Pfade (LSP).

	BFD baut eine Verbindung ([[Sitzung (Informatik)\|Session]]) zwischen zwei Endpunkten (Routern) auf. Sind diese nicht unmittelbar benachbart, spricht man von Multihop-BFD.		BFD baut eine Verbindung ([[Sitzung (Informatik)\|Session]]) zwischen zwei Endpunkten (Routern) auf. Sind diese nicht unmittelbar benachbart, spricht man von Multihop-BFD.
Zeile 13:		Zeile 11:
	Die [[Authentifizierung\|Authentisierung]] von BFD-Sessions ist möglich. Hier stehen je nach Gerätehersteller und Firmware-Version neben Kennwörtern im Klartext auch [[Message-Digest Algorithm 5\|MD5]]- oder [[Secure Hash Algorithm\|SHA1]]-basierte Verfahren zur Verfügung.		Die [[Authentifizierung\|Authentisierung]] von BFD-Sessions ist möglich. Hier stehen je nach Gerätehersteller und Firmware-Version neben Kennwörtern im Klartext auch [[Message-Digest Algorithm 5\|MD5]]- oder [[Secure Hash Algorithm\|SHA1]]-basierte Verfahren zur Verfügung.

	Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-~~Invervalle~~ sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.		Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Intervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.

	Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol~~\|RIP~~]]~~-Protokoll~~, ~~welches~~ standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGB]]~~<nowiki/>~~s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des ~~"next~~ ~~hop"~~ der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.		Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol]] (RIP), das standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGB]]s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des „next hop“ der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.

	BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.		BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.

DaDoKa: Ergänzung Verlinkungen

2017-05-15T11:01:39Z

Ergänzung Verlinkungen

← Nächstältere Version		Version vom 15. Mai 2017, 13:01 Uhr
Zeile 19:		Zeile 19:
	BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.		BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.

	Marktführende Netzwerkkomponentenhersteller ermöglichen die Verarbeitung von BFD-Sessions in Hardware auf der Line-Card ihrer Router. Die Zahl der unterstützten BFD-Sessions ist geräteabhängig und bewegt sich im Wertebereich von unter hundert bis über tausend BFD-Sessions. Die Verwendung von Authentisierung kann je nach Router-Modell zu einer Verarbeitung der BFD-Sessions in Software durch die Router-CPU erfolgen und führt damit zu einer Limitierung der Zahl möglicher BFD-Sessions bzw. eine Erhöhung der BFD-Hello-Intervalle.		Marktführende Netzwerkkomponentenhersteller ermöglichen die Verarbeitung von BFD-Sessions in [[Hardware]] auf der Line-Card ihrer Router. Die Zahl der unterstützten BFD-Sessions ist geräteabhängig und bewegt sich im Wertebereich von unter hundert bis über tausend BFD-Sessions. Die Verwendung von Authentisierung kann je nach Router-Modell zu einer Verarbeitung der BFD-Sessions in [[Software]] durch die Router-[[Prozessor\|CPU]] erfolgen und führt damit zu einer Limitierung der Zahl möglicher BFD-Sessions bzw. eine Erhöhung der BFD-[[Keepalive\|Hello]]-Intervalle.

	== Spezifikation ==		== Spezifikation ==

DaDoKa: Ergänzung statische Route, Quelle: siehe Juniper-Beitrag unter Weblinks

2017-04-25T18:56:15Z

Ergänzung statische Route, Quelle: siehe Juniper-Beitrag unter Weblinks

← Nächstältere Version		Version vom 25. April 2017, 20:56 Uhr
Zeile 15:		Zeile 15:
	Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Invervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.		Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Invervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.

	Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol\|RIP]]-Protokoll, welches standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGB]]<nowiki/>s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen.		Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol\|RIP]]-Protokoll, welches standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGB]]<nowiki/>s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des "next hop" der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.

	BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.		BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.

DaDoKa: Ergänzung EGP

2017-04-25T18:46:54Z

Ergänzung EGP

← Nächstältere Version		Version vom 25. April 2017, 20:46 Uhr
Zeile 7:		Zeile 7:
	BFD arbeitet mit geringem Protokoll-[[Overhead (EDV)\|Overhead]] auch auf Medien, die selber über keine oder nur eine eingeschränkte bzw. träge Fehlererkennungsmöglichkeit verfügen. Hierzu gehören beispielsweise ''Virtual Circuits'' (VC) im [[Synchrone Digitale Hierarchie\|SDH]]-Umfeld, IP-Tunnel-Verbindungen und [[Multiprotocol Label Switching\|MPLS]]-Label-Switched-Pfade (LSP).		BFD arbeitet mit geringem Protokoll-[[Overhead (EDV)\|Overhead]] auch auf Medien, die selber über keine oder nur eine eingeschränkte bzw. träge Fehlererkennungsmöglichkeit verfügen. Hierzu gehören beispielsweise ''Virtual Circuits'' (VC) im [[Synchrone Digitale Hierarchie\|SDH]]-Umfeld, IP-Tunnel-Verbindungen und [[Multiprotocol Label Switching\|MPLS]]-Label-Switched-Pfade (LSP).

	BFD baut eine Verbindung ([[Sitzung (Informatik)\|Session]]) zwischen zwei Endpunkten (Routern) auf. Sind diese nicht unmittelbar benachbart, spricht man von Multihop-BFD. Der BFD-Verbindung geht ein [[Drei-Wege-Handschlag]] voraus.		BFD baut eine Verbindung ([[Sitzung (Informatik)\|Session]]) zwischen zwei Endpunkten (Routern) auf. Sind diese nicht unmittelbar benachbart, spricht man von Multihop-BFD.

			Der BFD-Verbindung geht ein [[Drei-Wege-Handschlag]] voraus.

	Die [[Authentifizierung\|Authentisierung]] von BFD-Sessions ist möglich. Hier stehen je nach Gerätehersteller und Firmware-Version neben Kennwörtern im Klartext auch [[Message-Digest Algorithm 5\|MD5]]- oder [[Secure Hash Algorithm\|SHA1]]-basierte Verfahren zur Verfügung.		Die [[Authentifizierung\|Authentisierung]] von BFD-Sessions ist möglich. Hier stehen je nach Gerätehersteller und Firmware-Version neben Kennwörtern im Klartext auch [[Message-Digest Algorithm 5\|MD5]]- oder [[Secure Hash Algorithm\|SHA1]]-basierte Verfahren zur Verfügung.
Zeile 13:		Zeile 15:
	Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Invervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.		Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Invervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.

	Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol\|RIP]]-Protokoll, welches standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. ~~BFD kann auch für~~ [[~~Border~~ Gateway ~~Protocol~~\|~~BGP~~]] ~~genutzt~~ ~~werden~~.		Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol\|RIP]]-Protokoll, welches standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGB]]<nowiki/>s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen.

	BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.		BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.

DaDoKa: /* Redundanzen entfernt */

2017-04-25T14:58:25Z

Redundanzen entfernt

← Nächstältere Version		Version vom 25. April 2017, 16:58 Uhr
Zeile 22:		Zeile 22:
	BFD ist in [[rfc:5880\|RFC 5880]] für die Erkennung von MPLS-LSP-Fehlern beschrieben.		BFD ist in [[rfc:5880\|RFC 5880]] für die Erkennung von MPLS-LSP-Fehlern beschrieben.

	Die Beschreibung der Interaktion zwischen BFD und der Routing-Protokolle OSPF und IS-IS ~~Open Shortest Path First (OSPF)~~ erfolgte in [[rfc:5881\|RFC 5881]].		Die Beschreibung der Interaktion zwischen BFD und der Routing-Protokolle OSPF und IS-IS erfolgte in [[rfc:5881\|RFC 5881]].

	== Weblinks ==		== Weblinks ==

← Nächstältere Version		Version vom 1. Juni 2017, 11:08 Uhr
Zeile 1:		Zeile 1:
		⚫	'''Bidirectional Forwarding Detection''', kurz '''BFD''', ist ein minimalistisches [[Nachrichtenverbindung\|verbindungsorientiertes]] [[Netzwerkprotokoll]] zur Erkennung von Fehlern zwischen zwei miteinander verbundenen [[Router]]n.
	{{QS-Antrag\|25. April 2017\|2=vollprogramm, sofern relevant--[[Benutzer:Lutheraner\|Lutheraner]] ([[Benutzer Diskussion:Lutheraner\|Diskussion]]) 16:25, 25. Apr. 2017 (CEST)}}

⚫	'''Bidirectional Forwarding Detection''', kurz '''BFD''', ist ein minimalistisches [[Nachrichtenverbindung\|verbindungsorientiertes]] [[Netzwerkprotokoll]] zur Erkennung von Fehlern zwischen zwei miteinander ~~verbundene~~ [[Router]]~~<nowiki/>~~n.

	Es wurde entwickelt, um die [[Konvergenzzeit]] in Netzen bei Störungen zu verkürzen. Die Bekanntgabe von Zustandsänderungen in [[Internet Protocol\|IP]]-Netzen ist mit BFD im Sub-Sekunden-Bereich möglich.		Es wurde entwickelt, um die [[Konvergenzzeit]] in Netzen bei Störungen zu verkürzen. Die Bekanntgabe von Zustandsänderungen in [[Internet Protocol\|IP]]-Netzen ist mit BFD im Sub-Sekunden-Bereich möglich.

	BFD arbeitet mit geringem Protokoll-[[Overhead (EDV)\|Overhead]] auch auf Medien, die ~~selber~~ über keine oder nur eine eingeschränkte bzw. träge Fehlererkennungsmöglichkeit verfügen. Hierzu gehören beispielsweise ''Virtual Circuits'' (VC) im [[Synchrone Digitale Hierarchie\|SDH]]-Umfeld, IP-Tunnel-Verbindungen und [[Multiprotocol Label Switching\|MPLS]]-Label-Switched-Pfade (LSP).		BFD arbeitet mit geringem Protokoll-[[Overhead (EDV)\|Overhead]] auch auf Medien, die selbst über keine oder nur eine eingeschränkte bzw. träge Fehlererkennungsmöglichkeit verfügen. Hierzu gehören beispielsweise ''Virtual Circuits'' (VC) im [[Synchrone Digitale Hierarchie\|SDH]]-Umfeld, IP-Tunnel-Verbindungen und [[Multiprotocol Label Switching\|MPLS]]-Label-Switched-Pfade (LSP).

	BFD baut eine Verbindung ([[Sitzung (Informatik)\|Session]]) zwischen zwei Endpunkten (Routern) auf. Sind diese nicht unmittelbar benachbart, spricht man von Multihop-BFD.		BFD baut eine Verbindung ([[Sitzung (Informatik)\|Session]]) zwischen zwei Endpunkten (Routern) auf. Sind diese nicht unmittelbar benachbart, spricht man von Multihop-BFD.
Zeile 13:		Zeile 11:
	Die [[Authentifizierung\|Authentisierung]] von BFD-Sessions ist möglich. Hier stehen je nach Gerätehersteller und Firmware-Version neben Kennwörtern im Klartext auch [[Message-Digest Algorithm 5\|MD5]]- oder [[Secure Hash Algorithm\|SHA1]]-basierte Verfahren zur Verfügung.		Die [[Authentifizierung\|Authentisierung]] von BFD-Sessions ist möglich. Hier stehen je nach Gerätehersteller und Firmware-Version neben Kennwörtern im Klartext auch [[Message-Digest Algorithm 5\|MD5]]- oder [[Secure Hash Algorithm\|SHA1]]-basierte Verfahren zur Verfügung.

	Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-~~Invervalle~~ sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.		Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Intervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.

	Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol~~\|RIP~~]]~~-Protokoll~~, ~~welches~~ standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGB]]~~<nowiki/>~~s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des ~~"next~~ ~~hop"~~ der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.		Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol]] (RIP), das standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGB]]s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen. Bei statischen Routen steht mittels BFD ein Werkzeug zur Verfügung, mit dem die Erreichbarkeit des „next hop“ der Route überwacht und diese bei Nichterreichbarkeit aus der [[Routingtabelle\|Routing-Tabelle]] entfernt werden kann.

	BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.		BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.

← Nächstältere Version		Version vom 25. April 2017, 20:46 Uhr
Zeile 7:		Zeile 7:
	BFD arbeitet mit geringem Protokoll-[[Overhead (EDV)\|Overhead]] auch auf Medien, die selber über keine oder nur eine eingeschränkte bzw. träge Fehlererkennungsmöglichkeit verfügen. Hierzu gehören beispielsweise ''Virtual Circuits'' (VC) im [[Synchrone Digitale Hierarchie\|SDH]]-Umfeld, IP-Tunnel-Verbindungen und [[Multiprotocol Label Switching\|MPLS]]-Label-Switched-Pfade (LSP).		BFD arbeitet mit geringem Protokoll-[[Overhead (EDV)\|Overhead]] auch auf Medien, die selber über keine oder nur eine eingeschränkte bzw. träge Fehlererkennungsmöglichkeit verfügen. Hierzu gehören beispielsweise ''Virtual Circuits'' (VC) im [[Synchrone Digitale Hierarchie\|SDH]]-Umfeld, IP-Tunnel-Verbindungen und [[Multiprotocol Label Switching\|MPLS]]-Label-Switched-Pfade (LSP).

	BFD baut eine Verbindung ([[Sitzung (Informatik)\|Session]]) zwischen zwei Endpunkten (Routern) auf. Sind diese nicht unmittelbar benachbart, spricht man von Multihop-BFD. Der BFD-Verbindung geht ein [[Drei-Wege-Handschlag]] voraus.		BFD baut eine Verbindung ([[Sitzung (Informatik)\|Session]]) zwischen zwei Endpunkten (Routern) auf. Sind diese nicht unmittelbar benachbart, spricht man von Multihop-BFD.

			Der BFD-Verbindung geht ein [[Drei-Wege-Handschlag]] voraus.

	Die [[Authentifizierung\|Authentisierung]] von BFD-Sessions ist möglich. Hier stehen je nach Gerätehersteller und Firmware-Version neben Kennwörtern im Klartext auch [[Message-Digest Algorithm 5\|MD5]]- oder [[Secure Hash Algorithm\|SHA1]]-basierte Verfahren zur Verfügung.		Die [[Authentifizierung\|Authentisierung]] von BFD-Sessions ist möglich. Hier stehen je nach Gerätehersteller und Firmware-Version neben Kennwörtern im Klartext auch [[Message-Digest Algorithm 5\|MD5]]- oder [[Secure Hash Algorithm\|SHA1]]-basierte Verfahren zur Verfügung.
Zeile 13:		Zeile 15:
	Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Invervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.		Die Ende-zu-Ende-Verfügbarkeit wird durch periodisch gesendete Hello-Nachrichten geprüft. Hello-Invervalle sind hersteller- und gerätespezifisch und liegen im Bereich einiger Millisekunden. Das Ausbleiben der dritten Hello-Nachricht führt standardmäßig zum Abbruch der BFD-Session.

	Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol\|RIP]]-Protokoll, welches standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. ~~BFD kann auch für~~ [[~~Border~~ Gateway ~~Protocol~~\|~~BGP~~]] ~~genutzt~~ ~~werden~~.		Mit der Möglichkeit der Zustandsoffenbarung von Verbindungen an Routing-Protokolle, wie beispielsweise OSPF und IS-IS, sind diese damit in der Lage, den Ausfall ihres Nachbarn auch unterhalb der für das [[Interior Gateway Protocol\|IGP]] typischen Dead-Timer-Zeit zu erkennen. Dies gilt selbst für das [[Routing Information Protocol\|RIP]]-Protokoll, welches standardmäßig einen 30-Sekunden-Wert für sein Hello-Zeitintervall verwendet. Für [[Exterior-Gateway-Protokoll\|EGB]]<nowiki/>s kann das BGP-Protokoll die Zustandsinformationen von BFD nutzen, um schnelle Konvergenzzeiten zu erreichen.

	BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.		BFD verfügt im Unterschied zu Routing-Protokollen, wie [[Routing Information Protocol\|RIP]], [[Open Shortest Path First\|OSPF]] oder [[IS-IS]] über keinen Mechanismus zur automatischen Erkennung von benachbarten Routern. Daher muss jede BFD-Session zwischen Routern entsprechend konfiguriert werden.