Резервирование L2 — различия между версиями
Moiseevvi (обсуждение | вклад) (→LAcP) |
Moiseevvi (обсуждение | вклад) (→BFD) |
||
| Строка 6: | Строка 6: | ||
=UDLD= | =UDLD= | ||
=BFD= | =BFD= | ||
| + | =Link tracking= | ||
| + | =Backup link= | ||
| + | =REP= | ||
| + | |||
=Fate Sharing= | =Fate Sharing= | ||
The underlying assumption is simple: if the routing protocol manages to exchange information between adjacent nodes, there won’t be any problems with the user traffic. Furthermore, if the routing protocol updates in a distance vector protocol made it from egress router to ingress router, the traffic should experience no problems when being sent in the reverse direction. | The underlying assumption is simple: if the routing protocol manages to exchange information between adjacent nodes, there won’t be any problems with the user traffic. Furthermore, if the routing protocol updates in a distance vector protocol made it from egress router to ingress router, the traffic should experience no problems when being sent in the reverse direction. | ||
Версия 06:03, 29 апреля 2015
Содержание
LAG
LACP
PAgP
MLAG
UDLD
BFD
Link tracking
Backup link
REP
Fate Sharing
The underlying assumption is simple: if the routing protocol manages to exchange information between adjacent nodes, there won’t be any problems with the user traffic. Furthermore, if the routing protocol updates in a distance vector protocol made it from egress router to ingress router, the traffic should experience no problems when being sent in the reverse direction. http://blog.ipspace.net/2014/08/fate-sharing-in-ip-networks.html
