Protocolli e architetture di routing/B2/en

Il titolo di questa pagina non è corretto per via delle caratteristiche del software MediaWiki. Il titolo corretto è B2. IGRP and EIGRP.

[[{{#ifcategory:Traduzioni|Protocolli e architetture di routing|Protocolli e architetture di routing/B2|Protocolli e architetture di routing/en}}/B1{{#ifcategory:Traduzioni|/en||Protocolli e architetture di routing/en}}|B1. Routing Information Protocol]]	[[{{#ifcategory:Traduzioni|Protocolli e architetture di routing/en|Protocolli e architetture di routing/B2|Protocolli e architetture di routing/en}}#Forwarding and routing|{{#ifcategory:Traduzioni|Protocolli e architetture di routing|Protocolli e architetture di routing/B2|Protocolli e architetture di routing/en}} (Forwarding and routing)]]	[[{{#ifcategory:Traduzioni|Protocolli e architetture di routing|Protocolli e architetture di routing/B2|Protocolli e architetture di routing/en}}/B3{{#ifcategory:Traduzioni|/en||Protocolli e architetture di routing/en}}|B3. Open Shortest Path First]]

3-4 Interior Gateway Routing Protocol (IGRP) is an intra-domain routing protocol, proprietary by Cisco, based on the Distance Vector (DV) algorithm.

Also in IGRP the support for classless addressing (netmask) is absent, but with respect to RIP it has some additional 'marketing-oriented' features which however hide some unexpected technical mistakes:

• more sophisticated metrics: they introduce more complexity and less route stability;
• multipath routing: unequal-cost multipath routing may originate loops;
• support for heterogeneous networks: a wide range for link costs may slow down convergence to infinity;
• 15 less traffic related to routing protocol: DV update happens every 90 seconds;
• 14 greater stability: triggered updates are sent only if the cost has changed more than 10% to avoid frequent reconfiguration of the network;
• not more than one IP fragmentation: IGRP messages also transport information about the MTUs supported by the routers along the path → the packet can be fragmented immediately based on the minimum MTU, avoiding that at a later time it will be fragmented again by a smaller MTU.

Metrics

7 Cost <math>C</math> is obtained by the combination of 4 metrics:

<math>\begin{cases} \displaystyle C = \frac{10^7}{B} \left( k_1 + \frac{k_2}{256-L} \right) + k_3 D & \text{if } k_5 = 0 \\ \displaystyle C = \left[ \frac{10^7}{B} \left( k_1 + \frac{k_2}{256-L} \right) + k_3 D \right] \frac{k_5}{R+k_4} & \text{if } k_5 \neq 0 \end{cases}</math>

• 5-6 <math>B</math> - bandwidth: it is directly proportional to the link bandwidth (values 1 to 2²⁴ with 1 = 1.2 kbit/s);
• <math>D</math> - delay: it is inversely proportional to the link bandwidth, and it only considers transmission delay ignoring other components such as propagation delay and queuing delay (values 1 to 2²⁴ with 1 = 10 ms);
• <math>R</math> - reliability: it can be quite variable in time (values 1 to 255 with 255 = 100%);
• <math>L</math> - load: it depends on instantaneous traffic (values 1 to 255 with 255 = 100%).

With default values for coefficients <math>k_{1 \ldots 5}</math>, the cost only considers delay <math>D</math> and bandwidth <math>B</math>:

<math>k_1 = k_3 = 1 , \, k_2 = k_4 = k_5 = 0 \Rightarrow C = \frac{10^7}{B} + D</math>

IGRP commands require the specification of a class of service (TOS), but in practice routing based on classes of service has never been implemented in this protocol, because it would require a different routing table and a different cost function for each class of service.

Problems

Such a sophisticated metric really suffers from some problems from the technical point of view:

• 8 it is difficult to understand the routing choices: humans look at the network topology and measure the distance in 'hop count' → it is not easy to determine which is the best path when a more sophisticated metric is adopted;
• it is difficult to understand how to tune coefficients <math>k_{1 \ldots 5}</math>: what happens to the network when parameters are changed? which values have to be given to them in order to obtain the wanted behavior?
• 9 some metrics (e.g. load), being not very stable, force the network to continuously adapt its paths because the latter often change their costs → the need to frequently update routes leads to more transients with consequent black holes and bouncing effects, more routing traffic and more CPU resources dedicated to routing protocols;
• 10-11 it is difficult to define the right threshold value for infinity: IGRP defines it to 2²⁴, but it is required too much time when low-cost links are involved.

Multipath routing

12 IGRP supports unequal-cost multipath routing: multiple routes are allowed for the same destination, even if those routes have different costs (<math>c_\text{sec} \leq V \cdot c_\text{prim}</math>), and load is distributed proportionally to the cost of the route.

13 Problem

Traffic may enter a loop when different paths are chosen by two routers: one may choose the primary path (optimal route) and the other one the secondary path (sub-optimal route) → in the latest version of IGRP only equal-cost multipath routing is allowed (coefficient <math>V</math> is set to 1) in order to prevent these issues.

16-17-18-19-20 EIGRP

Enhanced IGRP introduces several enhancements to IGRP, especially from the scalability point of view:

• it supports classless addressing: networks are at last announces with their proper address-netmask pairs;
• it implements Diffusing Update Algorithm (DUAL): the network is loop-free, even during transients, and convergence is faster (no count-to-infinity phenomena);
• it decouples the neighbor discovery functionality from the route update mechanism: routers periodically exchange small Hello messages, while DVs are generated only when something has changed in the network:
  • Hello messages can be sent at high frequency, making fault detection and hence convergence faster, because:
    • they consume less bandwidth → routing traffic is reduced;
    • they consume less CPU resources with respect to DV processing and computation;
  • DVs must be sent through a reliable protocol: every DV must be confirmed by an acknowledgment message, and must be retransmitted if it went lost.

Il titolo di questa pagina non è corretto per via delle caratteristiche del software MediaWiki. Il titolo corretto è B2. IGRP and EIGRP.

[[{{#ifcategory:Traduzioni|Protocolli e architetture di routing|Protocolli e architetture di routing/B2|Protocolli e architetture di routing/en}}/B1{{#ifcategory:Traduzioni|/en||Protocolli e architetture di routing/en}}|B1. Routing Information Protocol]]	[[{{#ifcategory:Traduzioni|Protocolli e architetture di routing/en|Protocolli e architetture di routing/B2|Protocolli e architetture di routing/en}}#Forwarding and routing|{{#ifcategory:Traduzioni|Protocolli e architetture di routing|Protocolli e architetture di routing/B2|Protocolli e architetture di routing/en}} (Forwarding and routing)]]	[[{{#ifcategory:Traduzioni|Protocolli e architetture di routing|Protocolli e architetture di routing/B2|Protocolli e architetture di routing/en}}/B3{{#ifcategory:Traduzioni|/en||Protocolli e architetture di routing/en}}|B3. Open Shortest Path First]]