Exit Zen
160
../../principles/dv.rst:169
English
:math:`[A=\infty,B=0,C=\infty,E=1]` to router `C`
0/490 · 49
161
../../principles/dv.rst:170
English
:math:`[A=\infty,B=0,C=1,E=\infty]` to router `E`
0/490 · 49
162
../../principles/dv.rst:172
English
If, unfortunately, the distance vector sent to router `C` is lost due to a transmission error or because router `C` is overloaded, a new count to infinity problem can occur. If router `C` sends its distance vector :math:`[A=2,B=1,C=0,E=\infty]` to router `E`, this router installs a route of distance `3` to reach `A` via `C`. Router `E` sends its distance vectors :math:`[A=3,B=\infty,C=1,E=1]` to router `B` and :math:`[A=\infty,B=1,C=\infty,E=0]` to router `C`. This distance vector allows `B` to recover a route of distance `4` to reach `A`.
0/5450 · 545
163
../../principles/dv.rst:177
English
Forwarding tables versus routing tables
0/390 · 39
164
../../principles/dv.rst:179
English
Routers usually maintain at least two data structures that contain information about the reachable destinations. The first data structure is the `routing table`. The `routing table` is a data structure that associates a destination to an outgoing interface or a nexthop router and a set of additional attributes. Different routing protocols can associate different attributes for each destination. Distance vector routing protocols will store the cost to reach the destination along the shortest path. Other routing protocols may store information about the number of hops of the best path, its lifetime or the number of sub paths. A `routing table` may store different paths towards a given destination and flag one of them as the best one.
0/7410 · 741
165
../../principles/dv.rst:181
English
The `routing table` is a software data structure which is updated by (one or more) routing protocols. The `routing table` is usually not directly used when forwarding packets. Packet forwarding relies on a more compact data structure which is the `forwarding table`. On high-end routers, the `forwarding table` is implemented directly in hardware while lower performance routers will use a software implementation. A `forwarding table` contains a subset of the information found in the `routing table`. It only contains the nexthops towards each destination that are used to forward packets and no attributes. A `forwarding table` will typically associate each destination to one or more outgoing interface or nexthop router.
0/7250 · 725
166
../../principles/linkstate.rst:9
English
Link state routing
0/180 · 18
167
../../principles/linkstate.rst:11
English
Link state routing is the second family of routing protocols. While distance vector routers use a distributed algorithm to compute their routing tables, link-state routers exchange messages to allow each router to learn the entire network topology. Based on this learned topology, each router is then able to compute its routing table by using a shortest path computation such as Dijkstra's algorithm [Dijkstra1959]_. A detailed description of this shortest path algorithm may be found in [Wikipedia:Dijkstra]_.
0/5110 · 511
168
../../principles/linkstate.rst:13
English
For link-state routing, a network is modeled as a `directed weighted graph`. Each router is a node, and the links between routers are the edges in the graph. A positive weight is associated to each directed edge and routers use the shortest path to reach each destination. In practice, different types of weights can be associated to each directed edge :
0/3540 · 354
169
../../principles/linkstate.rst:15
English
unit weight. If all links have a unit weight, shortest path routing prefers the paths with the least number of intermediate routers.
0/1320 · 132
170
../../principles/linkstate.rst:16
English
weight proportional to the propagation delay on the link. If all link weights are configured this way, shortest path routing uses the paths with the smallest propagation delay.
0/1760 · 176
171
../../principles/linkstate.rst:17
English
:math:`weight=\frac{C}{bandwidth}` where `C` is a constant larger than the highest link bandwidth in the network. If all link weights are configured this way, shortest path routing prefers higher bandwidth paths over lower bandwidth paths.
0/2390 · 239
172
../../principles/linkstate.rst:19
English
Usually, the same weight is associated to the two directed edges that correspond to a physical link (i.e. :math:`R1 \rightarrow R2` and :math:`R2 \rightarrow R1`). However, nothing in the link state protocols requires this. For example, if the weight is set in function of the link bandwidth, then an asymmetric ADSL link could have a different weight for the upstream and downstream directions. Other variants are possible. Some networks use optimization algorithms to find the best set of weights to minimize congestion inside the network for a given traffic demand [FRT2002]_.
0/5790 · 579
173
../../principles/linkstate.rst:24
English
When a link-state router boots, it first needs to discover to which routers it is directly connected. For this, each router sends a HELLO message every `N` seconds on all its interfaces. This message contains the router's address. Each router has a unique address. As its neighboring routers also send HELLO messages, the router automatically discovers to which neighbors it is connected. These HELLO messages are only sent to neighbors that are directly connected to a router, and a router never forwards the HELLO messages that it receives. HELLO messages are also used to detect link and router failures. A link is considered to have failed if no HELLO message has been received from a neighboring router for a period of :math:`k \times N` seconds.
0/7510 · 751
175
../../principles/linkstate.rst:33
English
Once a router has discovered its neighbors, it must reliably distribute all its outgoing edges to all routers in the network to allow them to compute their local view of the network topology. For this, each router builds a `link-state packet` (LSP) containing the following information:
0/2860 · 286
176
../../principles/linkstate.rst:35
English
LSP.Router: identification (address) of the sender of the LSP
0/610 · 61
177
../../principles/linkstate.rst:36
English
LSP.age: age or remaining lifetime of the LSP
0/450 · 45
178
../../principles/linkstate.rst:37
English
LSP.seq: sequence number of the LSP
0/350 · 35
180
../../principles/linkstate.rst:42
English
These LSPs must be reliably distributed inside the network without using the router's routing table since these tables can only be computed once the LSPs have been received. The `Flooding` algorithm is used to efficiently distribute the LSPs of all routers. Each router that implements `flooding` maintains a `link state database` (LSDB) containing the most recent LSP sent by each router. When a router receives a LSP, it first verifies whether this LSP is already stored inside its LSDB. If so, the router has already distributed the LSP earlier and it does not need to forward it. Otherwise, the router forwards the LSP on all its links except the link over which the LSP was received. Flooding can be implemented by using the following pseudo-code.
0/7520 · 752
182
../../principles/linkstate.rst:59
English
Which is the most recent LSP ?
0/300 · 30