4 network.key
Upcoming SlideShare
Loading in...5
×
 

4 network.key

on

  • 1,800 views

Computer Networking : Principles, Protocols and Practice part 4

Computer Networking : Principles, Protocols and Practice part 4

Statistics

Views

Total Views
1,800
Views on SlideShare
1,800
Embed Views
0

Actions

Likes
0
Downloads
44
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • These slides are licensed under the creative commons attribution share-alike license 3.0. You can obtain detailed information about this <br /> license at http://creativecommons.org/licenses/by-sa/3.0/ <br /> <br /> <br /> <br /> The slides are part of an effort to develop an open-source networking textbook. See http://inl.info.ucl.ac.be/CNP3 for the current version of the textbook and more information on how to contribute. <br />
  • <br /> <br />
  • <br /> <br />
  • PPP is defined in several documents, including : <br /> <br /> <br /> <br /> RFC1661 The Point-to-Point Protocol (PPP). W. Simpson, Ed.. July 1994 <br /> <br /> <br /> <br /> Local area networks are described in part 5. <br />
  • PPP is defined in several documents, including : <br /> <br /> <br /> <br /> RFC1661 The Point-to-Point Protocol (PPP). W. Simpson, Ed.. July 1994 <br /> <br /> <br /> <br /> Local area networks are described in part 5. <br />
  • PPP is defined in several documents, including : <br /> <br /> <br /> <br /> RFC1661 The Point-to-Point Protocol (PPP). W. Simpson, Ed.. July 1994 <br /> <br /> <br /> <br /> Local area networks are described in part 5. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • The datagram mode is used in other networking protocols <br /> <br /> <br /> <br /> Internet Protocol <br /> IPX (used by Novell) <br /> ConnectionLess Network Protocol (CLNP), developed by ISO and used in some networks <br />
  • The datagram mode is used in other networking protocols <br /> <br /> <br /> <br /> Internet Protocol <br /> IPX (used by Novell) <br /> ConnectionLess Network Protocol (CLNP), developed by ISO and used in some networks <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Virtual circuits are used by several networking technologies, including : <br /> <br /> - Asynchronous Transfer Mode (ATM) <br /> <br /> <br /> - Frame Relay <br /> <br /> <br /> <br /> <br /> <br /> MultiProtocol Label Switching (MPLS) is a way to integrate virtual circuits with IP. It will be described later. <br />
  • Virtual circuits are used by several networking technologies, including : <br /> <br /> - Asynchronous Transfer Mode (ATM) <br /> <br /> <br /> - Frame Relay <br /> <br /> <br /> <br /> <br /> <br /> MultiProtocol Label Switching (MPLS) is a way to integrate virtual circuits with IP. It will be described later. <br />
  • Virtual circuits are used by several networking technologies, including : <br /> <br /> - Asynchronous Transfer Mode (ATM) <br /> <br /> <br /> - Frame Relay <br /> <br /> <br /> <br /> <br /> <br /> MultiProtocol Label Switching (MPLS) is a way to integrate virtual circuits with IP. It will be described later. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • En outre, un temporisateur East associ&#xE9; &#xE0; chaque entr&#xE9;e de la table de routage de tout routeur. Ce temporisateur East remis &#xE0; z&#xE9;ro chaque fois qu&apos;un vecteur de distance contenant cette route East re&#xE7;u par le routeur. Si le temporisateur expire, la route East consid&#xE9;r&#xE9;e comme &#xE9;tant invalide et elle East supprim&#xE9;e de la table de routage. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Pseudocode <br /> Every N seconds: <br /> <br /> for each link=l <br /> <br /> <br /> { /* one different vector for each link */ <br /> <br /> <br /> Vector=null; <br /> <br /> <br /> for each destination=d in R[] <br /> <br /> <br /> { <br /> <br /> <br /> if (R[d].link&lt;>l) <br /> <br /> <br /> { <br /> <br /> <br /> Vector=Vector+Pair(d,R[d].cost); <br /> <br /> <br /> } <br /> <br /> <br /> } <br /> <br /> <br /> Send(Vector); <br /> <br /> <br /> } <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Pseudocode <br /> <br /> <br /> <br /> Every N seconds: <br /> <br /> for each link=l <br /> <br /> <br /> { /* one different vector for each link */ <br /> <br /> <br /> Vector=null; <br /> <br /> <br /> for each destination=d in R[] <br /> <br /> <br /> { <br /> <br /> <br /> if (R[d].link&lt;>l) <br /> <br /> <br /> { <br /> <br /> <br /> Vector=Vector+Pair(d,R[d].cost); <br /> <br /> <br /> } <br /> <br /> <br /> else <br /> <br /> <br /> { <br /> <br /> <br /> Vector=Vector+Pair(d, <br /> &#x221E; <br /> ); <br /> <br /> <br /> } <br /> <br /> <br /> } <br /> <br /> <br /> Send(Vector); <br /> <br /> <br /> } <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Different costs can be used for different link directions <br />
  • Contents of the LSP <br /> LSP.Router : Identification of the sender of the LSP <br /> LSP.Links[] : links advertised in the LSP <br /> LSP.Links[i].Id : identification of the neighbour <br /> LSP.Links[i].delay : cost of the link <br />
  • <br /> <br />
  • <br /> <br />
  • Il faut noter que le LSP envoy&#xE9; par le routeur E d&#xE9;crit les liens dirig&#xE9;s du routeur E vers les routeurs D, B et C. Le LSP du routeur D contiendra l&apos;information relative au liens dirig&#xE9;s D->E et D->A. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> Link state routing protocols apply the two way connectivity check before starting the computation. This check verifies that a link is advertised by both endpoints of the link. If this is not the case, then the link is removed from the graph. This check is important to deal with node failures, but it also allows to speedup the convergence after a link failure. <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • IP is defined in <br /> <br /> <br /> <br /> RFC791 Internet Protocol. J. Postel. Sep-01-1981. <br /> <br /> <br /> <br /> <br /> <br />
  • <br /> <br />
  • Il East utile de remarquer que la diff&#xE9;rence fondamentale entre les routeurs et les stations terminales n&apos;East pas le nombre d&apos;interfaces. M&#xEA;me si une station terminale dispose en g&#xE9;n&#xE9;ral d&apos;une seule interface physique, rien ne l&apos;emp&#xEA;che d&apos;en avoir plusieurs. M&#xEA;me dans ce cas, la station pourra tr&#xE8;s bien seulement recevoir et envoyer des paquets qui sont dEastin&#xE9;s &#xE0; l&apos;une de ces interfances. C&apos;East par exemple le cas d&apos;un serveur qui serait connect&#xE9; physiquement &#xE0; deux r&#xE9;seaux distincts. Une telle station ne deviendra un routeur que si elle accepte de retransmettre vers leur destinations des paquets qui ne lui sont pas directement dEastin&#xE9;s. En pratique, un routeur n&apos;aura que peu d&apos;utilit&#xE9; si il n&apos;a qu&apos;une interface. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Une autre fa&#xE7;on tr&#xE8;s fr&#xE9;quente de repr&#xE9;senter le nombre de bits correspondant au sous-r&#xE9;seau East de faire suivre l&apos;adresse IP d&apos;un masque. Si le sous-r&#xE9;seau correspond aux M bitsde poids forts de l&apos;adresses, alors les M bits de poids fort du masque sont mis &#xE0; un tandis que les 32-M bits de poids faible sont mis &#xE0; z&#xE9;ro. <br /> <br /> <br /> <br /> Par exemple, <br /> <br /> Sous-r&#xE9;seau /8 : Masque =255.0.0.0 (aussi appel&#xE9; r&#xE9;seau de classe A pour des raisons historiques) <br /> <br /> <br /> Sous-r&#xE9;seau /16:Masque = 255.255.0.0 (aussi appel&#xE9; r&#xE9;seau de classe B pour des raisons historiques) <br /> <br /> <br /> Sous-r&#xE9;seau /23:Masque = 255.255.254.0 <br /> <br /> <br /> Sous-r&#xE9;seau /24:Masque = 255.255.255.0 (aussi appel&#xE9; r&#xE9;seau de classe C pour des raisons historiques) <br /> <br /> <br /> Sous-r&#xE9;seau /30:Masque = 255.255.255.253 souvent, les lignes point-&#xE0;-point utilisent des sous-r&#xE9;seaux /30 <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />
  • <br /> <br />
  • The addresses 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are called private addresses or RFC1918 addresses <br /> <br /> <br /> <br /> RFC1918 Address Allocation for Private Internets. Y. Rekhter, B. <br /> <br /> Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. <br /> <br /> <br /> <br /> <br /> More information about the allocation of IP addresses may be found in <br /> <br /> <br /> http://www.ripe.net <br /> <br /> <br /> <br /> <br /> http://www.iana.org <br /> <br /> <br />
  • The addresses 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are called private addresses or RFC1918 addresses <br /> <br /> <br /> <br /> RFC1918 Address Allocation for Private Internets. Y. Rekhter, B. <br /> <br /> Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. <br /> <br /> <br /> <br /> <br /> More information about the allocation of IP addresses may be found in <br /> <br /> <br /> http://www.ripe.net <br /> <br /> <br /> <br /> <br /> http://www.iana.org <br /> <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • L&apos;algorithme permettant de fragmenter un paquet IP peut se construire de fa&#xE7;on quasi imm&#xE9;diate sur base de cet exemple. Lorsque les diff&#xE9;rents fragments d&apos;un paquet ont &#xE9;t&#xE9; construits, il rEaste &#xE0; les transmettre vers la destination. Certaines impl&#xE9;mentations transmettent les fragments dans l&apos;ordre croissant tandis que d&apos;autres les transmettent dans l&apos;ordre d&#xE9;croissant. La deuxi&#xE8;me solution, lorsque les fragments arrivent en s&#xE9;quence, facilite la gEastion des buffers de la destination. En effet, si la destination re&#xE7;oit d&apos;abord le dernier fragment d&apos;un paquet, elle connait imm&#xE9;diatement la taille exacte du buffer n&#xE9;cessaire pour r&#xE9;assembler ce paquet. Alors que si la destination re&#xE7;oit d&apos;abord le premier fragment, elle n&apos;a aucune information sur la longueur totale du paquet. <br />
  • En pratique, la conception d&apos;un algorithme de r&#xE9;assemblage est un peu plus complexe que ce qui est d&#xE9;crit ci dessus car il faut prendre en compte divers &#xE9;l&#xE9;ments comme l&apos;arriv&#xE9;e de fragments hors s&#xE9;quence et les pertes de segments. <br />
  • <br /> <br />
  • Cette solution east utilis&#xE9;e dans l&apos;Internet par certains protocoles utilisateurs de la couche IP. TCP par exemple est capable d&apos;adapter la taille des segments qu&apos;il envoie en fonction de la longueur maximale des paquets accept&#xE9;es dans le r&#xE9;seau. Cette technique porte le nom de PathMTU discovery (MTU signifie Maximum Transmission Unit, c&apos;East-&#xE0;-dire la taille maximale des paquets IP g&#xE9;n&#xE9;ralement sur une ligne donn&#xE9;e) <br /> <br /> <br /> <br /> Voir : <br /> <br /> <br /> <br /> RFC1191 Path MTU discovery. J.C. Mogul, S.E. Deering. Nov-01-1990 <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br /> <br /> <br /> <br /> <br /> <br /> 1 ICMP Internet Control Message [RFC792] <br /> <br /> <br /> 2 IGMP Internet Group Management [RFC1112] <br /> <br /> <br /> 4 IP IP in IP (encapsulation) [RFC2003] <br /> <br /> <br /> 6 TCP Transmission Control [RFC793] <br /> <br /> <br /> 17 UDP User Datagram [RFC768] <br /> <br /> <br /> <br /> <br /> See also http://www.iana.org/assignments/protocol-numbers <br /> <br /> <br /> <br /> IP options are rarely used in practice <br />
  • <br /> <br /> <br /> <br /> <br /> <br /> <br /> 1 ICMP Internet Control Message [RFC792] <br /> <br /> <br /> 2 IGMP Internet Group Management [RFC1112] <br /> <br /> <br /> 4 IP IP in IP (encapsulation) [RFC2003] <br /> <br /> <br /> 6 TCP Transmission Control [RFC793] <br /> <br /> <br /> 17 UDP User Datagram [RFC768] <br /> <br /> <br /> <br /> <br /> See also http://www.iana.org/assignments/protocol-numbers <br /> <br /> <br /> <br /> IP options are rarely used in practice <br />
  • <br /> <br /> <br /> <br /> <br /> <br /> <br /> 1 ICMP Internet Control Message [RFC792] <br /> <br /> <br /> 2 IGMP Internet Group Management [RFC1112] <br /> <br /> <br /> 4 IP IP in IP (encapsulation) [RFC2003] <br /> <br /> <br /> 6 TCP Transmission Control [RFC793] <br /> <br /> <br /> 17 UDP User Datagram [RFC768] <br /> <br /> <br /> <br /> <br /> See also http://www.iana.org/assignments/protocol-numbers <br /> <br /> <br /> <br /> IP options are rarely used in practice <br />
  • <br /> <br /> <br /> <br /> <br /> <br /> <br /> 1 ICMP Internet Control Message [RFC792] <br /> <br /> <br /> 2 IGMP Internet Group Management [RFC1112] <br /> <br /> <br /> 4 IP IP in IP (encapsulation) [RFC2003] <br /> <br /> <br /> 6 TCP Transmission Control [RFC793] <br /> <br /> <br /> 17 UDP User Datagram [RFC768] <br /> <br /> <br /> <br /> <br /> See also http://www.iana.org/assignments/protocol-numbers <br /> <br /> <br /> <br /> IP options are rarely used in practice <br />
  • <br /> <br /> <br /> <br /> <br /> <br /> <br /> 1 ICMP Internet Control Message [RFC792] <br /> <br /> <br /> 2 IGMP Internet Group Management [RFC1112] <br /> <br /> <br /> 4 IP IP in IP (encapsulation) [RFC2003] <br /> <br /> <br /> 6 TCP Transmission Control [RFC793] <br /> <br /> <br /> 17 UDP User Datagram [RFC768] <br /> <br /> <br /> <br /> <br /> See also http://www.iana.org/assignments/protocol-numbers <br /> <br /> <br /> <br /> IP options are rarely used in practice <br />
  • <br /> <br /> <br /> <br /> <br /> <br /> <br /> 1 ICMP Internet Control Message [RFC792] <br /> <br /> <br /> 2 IGMP Internet Group Management [RFC1112] <br /> <br /> <br /> 4 IP IP in IP (encapsulation) [RFC2003] <br /> <br /> <br /> 6 TCP Transmission Control [RFC793] <br /> <br /> <br /> 17 UDP User Datagram [RFC768] <br /> <br /> <br /> <br /> <br /> See also http://www.iana.org/assignments/protocol-numbers <br /> <br /> <br /> <br /> IP options are rarely used in practice <br />
  • <br /> <br /> <br /> <br /> <br /> <br /> <br /> 1 ICMP Internet Control Message [RFC792] <br /> <br /> <br /> 2 IGMP Internet Group Management [RFC1112] <br /> <br /> <br /> 4 IP IP in IP (encapsulation) [RFC2003] <br /> <br /> <br /> 6 TCP Transmission Control [RFC793] <br /> <br /> <br /> 17 UDP User Datagram [RFC768] <br /> <br /> <br /> <br /> <br /> See also http://www.iana.org/assignments/protocol-numbers <br /> <br /> <br /> <br /> IP options are rarely used in practice <br />
  • <br /> <br /> <br /> <br /> <br /> <br /> <br /> 1 ICMP Internet Control Message [RFC792] <br /> <br /> <br /> 2 IGMP Internet Group Management [RFC1112] <br /> <br /> <br /> 4 IP IP in IP (encapsulation) [RFC2003] <br /> <br /> <br /> 6 TCP Transmission Control [RFC793] <br /> <br /> <br /> 17 UDP User Datagram [RFC768] <br /> <br /> <br /> <br /> <br /> See also http://www.iana.org/assignments/protocol-numbers <br /> <br /> <br /> <br /> IP options are rarely used in practice <br />
  • The first three options have been defined in <br /> RFC791 Internet Protocol. J. Postel. Sep-01-1981. <br /> <br /> <br /> <br /> The last is discussed in <br /> RFC2113 IP Router Alert Option. D. Katz. February 1997 <br /> <br /> <br /> <br /> However, there have been proposals to remove it <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Exemple de configuration d&apos;une station IP : <br /> <br /> <br /> <br /> configuration des interfaces (une loopback et une Ethernet) <br /> /sbin/ifconfig -a <br /> lo0: flags=849 mtu 8232 <br /> <br /> inet 127.0.0.1 netmask ff000000 <br /> <br /> hme0: flags=863 mtu 1500 <br /> <br /> inet 130.104.229.58 netmask ffffff80 broadcast 130.104.229.127 <br /> <br /> <br /> <br /> <br /> Cette station dispose de deux interfaces, l&apos;interface loopback East lo0 et l&apos;interface Ethernet hme0. <br /> <br /> <br /> <br /> table de routage <br /> <br /> <br /> <br /> netstat -rnv <br /> <br /> <br /> <br /> IRE Table: <br /> <br /> Destination Mask Gateway Device Mxfrg Rtt Ref Flg Out In/Fwd <br /> <br /> -------------------- --------------- -------------------- ------ ----- ----- --- --- ----- ------ <br /> 130.104.229.0 255.255.255.128 130.104.229.58 hme0 1500* 0 3 U 5750 0 <br /> 224.0.0.0 240.0.0.0 130.104.229.58 hme0 1500* 0 3 U 0 0 <br /> default 0.0.0.0 130.104.229.126 1500* 0 0 UG 42564 0 <br /> 127.0.0.1 255.255.255.255 127.0.0.1 lo0 8232* 315 0 UH 65966 0 <br /> <br /> <br /> <br /> default correspond &#xE0; la route par d&#xE9;faut, 0.0.0.0/0 et 224.0.0.0 correspond au multicast <br />
  • RARP est rarement utilis&#xE9; en pratique aujourd&apos;hui. Il servait essentiellement pour permettre &#xE0; des stations ne disposant que d&apos;un ROM limit&#xE9;e d&apos;obtenir leur adresse IP afin de booter depuis un serveur situ&#xE9; sur le m&#xEA;me r&#xE9;seau local. <br /> <br /> <br /> <br /> DHCP East le protocole d&apos;attribution d&apos;adresses le plus couramment utilis&#xE9;. Il East le successeur de BOOTP. DHCP est d&#xE9;fini dans : <br /> RFC2131 Dynamic Host Configuration Protocol. R. Droms. March 1997. <br />
  • En pratique, le nexthop sera l&apos;adresse IP d&apos;un routeur, g&#xE9;n&#xE9;ralement directement joignable via la couche liaison de donn&#xE9;es, auquel le routeur local devra envoyer les paquets pour rejoindre un r&#xE9;seau distant. <br />
  • <br /> <br />
  • Pour une pr&#xE9;sentation des m&#xE9;thodes permettant de localiser la route la plus sp&#xE9;cifique dans une table de routage, voir : <br /> R. Perlman, Interconnections : bridges and routers, Second Edition, Addison Wesley <br />
  • <br /> <br />
  • <br /> <br />
  • ICMP is defined in <br /> <br /> <br /> <br /> RFC792 Internet Control Message Protocol. J. Postel. Sep-01-1981. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Example of ping usage <br /> <br /> <br /> ping astrolabe <br /> <br /> PING astrolabe (130.104.229.109) 56(84) bytes of data. <br /> 64 bytes from astrolabe (130.104.229.109): icmp_seq=1 ttl=245 time=20.7 ms <br /> 64 bytes from astrolabe (130.104.229.109): icmp_seq=2 ttl=245 time=20.2 ms <br /> 64 bytes from astrolabe (130.104.229.109): icmp_seq=3 ttl=245 time=20.1 ms <br /> <br /> <br /> <br /> --- astrolabe ping statistics --- <br /> 3 packets transmitted, 3 received, 0% packet loss, time 2016ms <br /> rtt min/avg/max/mdev = 20.156/20.383/20.722/0.244 ms <br /> Example of traceroute <br /> ] traceroute www.geant.net <br /> traceroute: Warning: ckecksums disabled <br /> traceroute to newweb.dante.org.uk (62.40.101.34), 30 hops max, 40 byte packets <br /> <br /> 1 accelar-1 (130.104.229.126) 1.890 ms 1.752 ms 1.723 ms <br /> <br /> <br /> 2 XVLX-CR.fsa.ucl.ac.be (130.104.233.233) 1.620 ms 1.620 ms 1.603 ms <br /> <br /> <br /> 3 CsPythagore.sri.ucl.ac.be (130.104.254.221) 1.317 ms 1.305 ms 1.302 ms <br /> <br /> <br /> 4 CsHalles.sri.ucl.ac.be (130.104.254.201) 1.512 ms 1.425 ms 1.415 ms <br /> <br /> <br /> 5 193.191.11.9 (193.191.11.9) 0.891 ms 0.780 ms 0.780 ms <br /> <br /> <br /> 6 193.191.1.197 (193.191.1.197) 1.166 ms 1.263 ms 1.079 ms <br /> <br /> <br /> 7 193.191.1.2 (193.191.1.2) 1.329 ms 1.107 ms 1.100 ms <br /> <br /> <br /> 8 belnet.be1.be.geant.net (62.40.103.13) 1.341 ms 1.490 ms 1.323 ms <br /> <br /> <br /> 9 be.nl1.nl.geant.net (62.40.96.22) 4.779 ms 4.586 ms 4.515 ms <br /> <br /> 10 nl.uk1.uk.geant.net (62.40.96.182) 12.259 ms 12.051 ms 12.029 ms <br /> 11 62.40.101.34 (62.40.101.34) 12.811 ms 12.310 ms 12.645 ms <br />
  • <br /> <br />
  • For more information about the exhaustion of IPv4 addresses, see <br /> <br /> <br /> <br /> http://www.potaroo.net/tools/ipv4/index.html <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • This figure shows the number of IPv4 prefixes used on the global Internet. In addition, some networks, e.g. large cable networks, have had difficulties in using IPv4 due to the limited number of available addresses. For example, comcast is planning to use IPv6 to manage its cable modems mainly because IPv4 does not allow them to have enough addresses to identify all their potential cable modems in a scalable manner, see http://www.nanog.org/mtg-0606/durand.html <br /> <br /> <br /> <br /> <br /> <br />
  • <br /> <br />
  • In contrast, the number of ASes using IPv4 is much larger. In March 2008, more than 27000 ASes were advertising IPv4 addresses, see http://bgp.potaroo.net/bgprpts/rva-index.html <br /> <br /> <br /> <br /> <br /> <br />
  • For a detailed discussion of NAT and its implications, see : <br /> <br /> <br /> <br /> [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, <br /> November 2000. <br /> <br /> <br /> <br /> [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications <br /> with the IP Network Address Translator (NAT)", RFC 3027, <br /> January 2001. <br /> <br /> <br /> <br /> [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address <br /> Translator (NAT) Terminology and Considerations", RFC <br /> 2663, August 1999. <br /> <br /> <br /> <br /> [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network <br /> Address Translator (Traditional NAT)", RFC 3022, January <br /> 2001. <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />
  • IP version 4 supports 4,294,967,296 distinct addresses, but some are reserved for : <br /> private addresses (RFC1918) <br /> loopback (127.0.0.1) <br /> multicast <br /> ... <br /> <br /> <br />
  • IP version 4 supports 4,294,967,296 distinct addresses, but some are reserved for : <br /> private addresses (RFC1918) <br /> loopback (127.0.0.1) <br /> multicast <br /> ... <br /> <br /> <br />
  • The IPv6 addressing architecture is defined in : <br /> <br /> <br /> <br /> R. Hinden, S. Deering, IP Version 6 Addressing Architecture, RFC4291, February 2006 <br /> <br /> <br /> <br /> <br /> <br />
  • <br /> <br />
  • Today, the default encoding for global unicast addresses is to use : <br /> 48 bits for the global routing prefix (first three bits are set to 001) <br /> 16 bits for the subnet ID <br /> 64 bits for the interface ID <br />
  • Today, the default encoding for global unicast addresses is to use : <br /> 48 bits for the global routing prefix (first three bits are set to 001) <br /> 16 bits for the subnet ID <br /> 64 bits for the interface ID <br />
  • Today, the default encoding for global unicast addresses is to use : <br /> 48 bits for the global routing prefix (first three bits are set to 001) <br /> 16 bits for the subnet ID <br /> 64 bits for the interface ID <br />
  • See http://www.ripe.net/ripe/docs/ripe-388.html for the policy used by RIPE to allocate IP prefixes in Europe <br />
  • Site-local addresses were defined in the first IPv6 specifications, but they are now deprecated and should not be used. <br /> <br /> <br /> <br /> Recently &#x201C;private&#x201D; addresses have been defined as Unique Local IPv6 Addresses as a way to allow entreprise to obtain IPv6 addresses without being forced to request them from providers or RIRs. <br /> <br /> <br /> <br /> The way to choose such a ULA prefix is defined in : <br /> <br /> <br /> <br /> R. Hinden, B. Haberman, Unique Local IPv6 Unicast Addresses, RFC4193, October 2005 <br /> <br /> <br /> <br /> <br /> <br /> <br /> Recently, the case for a registration of such addresses has been proposed, see : <br /> R. Hinden, G. Huston, T. Narten, Centrally Assigned Unique Local IPv6 Unicast Addresses, internet draft, , work in progress, June 2007 <br /> <br /> <br /> <br /> See also <br /> <br /> http://www.ripe.net/ripe/policies/proposals/2007-05.html - <br />
  • The full list of well known IPv6 multicast groups is available from http://www.iana.org/assignments/ipv6-multicast-addresses <br /> <br /> <br /> <br /> <br /> <br /> <br /> Examples include <br /> <br /> <br /> <br /> <br /> <br /> <br /> Node-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF01:0:0:0:0:0:0:1 All Nodes Address [RFC4291] <br /> FF01:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> <br /> <br /> <br /> Link-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF02:0:0:0:0:0:0:1 All Nodes Address [RFC4291] <br /> FF02:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> FF02:0:0:0:0:0:0:5 OSPFIGP [RFC2328,Moy] <br /> FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers [RFC2328,Moy] <br /> FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080] <br /> FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci] <br /> FF02:0:0:0:0:0:1:2 All-dhcp-agents [RFC3315] <br /> <br /> <br /> <br /> Site-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF05:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> <br /> <br /> <br /> FF05:0:0:0:0:0:1:3 All-dhcp-servers [RFC3315] <br /> <br /> Variable Scope Multicast Addresses <br /> ---------------------------------- <br /> <br /> <br /> <br /> <br /> <br /> <br /> The IPv6 multicast addresses with variable scope are listed below. <br /> <br /> <br /> <br /> FF0X:0:0:0:0:0:0:0 Reserved Multicast Address [RFC4291] <br /> FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119,DLM1] <br /> FF0X:0:0:0:0:0:0:103 Rwhod [SXD] <br /> FF0X:0:0:0:0:0:0:10A IETF-1-LOW-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10B IETF-1-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10C IETF-1-VIDEO [SC3] <br /> FF0X:0:0:0:0:0:0:10D IETF-2-LOW-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10E IETF-2-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10F IETF-2-VIDEO [SC3] <br />
  • The full list of well known IPv6 multicast groups is available from http://www.iana.org/assignments/ipv6-multicast-addresses <br /> <br /> <br /> <br /> <br /> <br /> <br /> Examples include <br /> <br /> <br /> <br /> <br /> <br /> <br /> Node-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF01:0:0:0:0:0:0:1 All Nodes Address [RFC4291] <br /> FF01:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> <br /> <br /> <br /> Link-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF02:0:0:0:0:0:0:1 All Nodes Address [RFC4291] <br /> FF02:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> FF02:0:0:0:0:0:0:5 OSPFIGP [RFC2328,Moy] <br /> FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers [RFC2328,Moy] <br /> FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080] <br /> FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci] <br /> FF02:0:0:0:0:0:1:2 All-dhcp-agents [RFC3315] <br /> <br /> <br /> <br /> Site-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF05:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> <br /> <br /> <br /> FF05:0:0:0:0:0:1:3 All-dhcp-servers [RFC3315] <br /> <br /> Variable Scope Multicast Addresses <br /> ---------------------------------- <br /> <br /> <br /> <br /> <br /> <br /> <br /> The IPv6 multicast addresses with variable scope are listed below. <br /> <br /> <br /> <br /> FF0X:0:0:0:0:0:0:0 Reserved Multicast Address [RFC4291] <br /> FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119,DLM1] <br /> FF0X:0:0:0:0:0:0:103 Rwhod [SXD] <br /> FF0X:0:0:0:0:0:0:10A IETF-1-LOW-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10B IETF-1-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10C IETF-1-VIDEO [SC3] <br /> FF0X:0:0:0:0:0:0:10D IETF-2-LOW-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10E IETF-2-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10F IETF-2-VIDEO [SC3] <br />
  • The full list of well known IPv6 multicast groups is available from http://www.iana.org/assignments/ipv6-multicast-addresses <br /> <br /> <br /> <br /> <br /> <br /> <br /> Examples include <br /> <br /> <br /> <br /> <br /> <br /> <br /> Node-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF01:0:0:0:0:0:0:1 All Nodes Address [RFC4291] <br /> FF01:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> <br /> <br /> <br /> Link-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF02:0:0:0:0:0:0:1 All Nodes Address [RFC4291] <br /> FF02:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> FF02:0:0:0:0:0:0:5 OSPFIGP [RFC2328,Moy] <br /> FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers [RFC2328,Moy] <br /> FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080] <br /> FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci] <br /> FF02:0:0:0:0:0:1:2 All-dhcp-agents [RFC3315] <br /> <br /> <br /> <br /> Site-Local Scope <br /> ---------------- <br /> <br /> <br /> <br /> FF05:0:0:0:0:0:0:2 All Routers Address [RFC4291] <br /> <br /> <br /> <br /> FF05:0:0:0:0:0:1:3 All-dhcp-servers [RFC3315] <br /> <br /> Variable Scope Multicast Addresses <br /> ---------------------------------- <br /> <br /> <br /> <br /> <br /> <br /> <br /> The IPv6 multicast addresses with variable scope are listed below. <br /> <br /> <br /> <br /> FF0X:0:0:0:0:0:0:0 Reserved Multicast Address [RFC4291] <br /> FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119,DLM1] <br /> FF0X:0:0:0:0:0:0:103 Rwhod [SXD] <br /> FF0X:0:0:0:0:0:0:10A IETF-1-LOW-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10B IETF-1-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10C IETF-1-VIDEO [SC3] <br /> FF0X:0:0:0:0:0:0:10D IETF-2-LOW-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10E IETF-2-AUDIO [SC3] <br /> FF0X:0:0:0:0:0:0:10F IETF-2-VIDEO [SC3] <br />
  • The allocated anycast addresses are references in http://www.iana.org/assignments/ipv6-anycast-addresses <br />
  • The IPv6 packet format is described in <br /> S. Deering, B. Hinden, Internet Protocol, Version 6 (IPv6) Specification , RFC2460, Dec 1998 <br /> <br /> <br /> <br /> <br /> <br /> <br /> Several documents have been written about the usage of the Flow label. The last one is <br /> <br /> <br /> <br /> J. Rajahalme, A. Conta, B. Carpenter, S. Deering, IPv6 Flow Label Specification, RFC3697, 2004 <br /> <br /> <br /> <br /> <br /> However, this proposal is far from being widely used and deployed. <br />
  • The IPv6 packet format is described in <br /> S. Deering, B. Hinden, Internet Protocol, Version 6 (IPv6) Specification , RFC2460, Dec 1998 <br /> <br /> <br /> <br /> <br /> <br /> <br /> Several documents have been written about the usage of the Flow label. The last one is <br /> <br /> <br /> <br /> J. Rajahalme, A. Conta, B. Carpenter, S. Deering, IPv6 Flow Label Specification, RFC3697, 2004 <br /> <br /> <br /> <br /> <br /> However, this proposal is far from being widely used and deployed. <br />
  • The IPv6 packet format is described in <br /> S. Deering, B. Hinden, Internet Protocol, Version 6 (IPv6) Specification , RFC2460, Dec 1998 <br /> <br /> <br /> <br /> <br /> <br /> <br /> Several documents have been written about the usage of the Flow label. The last one is <br /> <br /> <br /> <br /> J. Rajahalme, A. Conta, B. Carpenter, S. Deering, IPv6 Flow Label Specification, RFC3697, 2004 <br /> <br /> <br /> <br /> <br /> However, this proposal is far from being widely used and deployed. <br />
  • The IPv6 packet format is described in <br /> S. Deering, B. Hinden, Internet Protocol, Version 6 (IPv6) Specification , RFC2460, Dec 1998 <br /> <br /> <br /> <br /> <br /> <br /> <br /> Several documents have been written about the usage of the Flow label. The last one is <br /> <br /> <br /> <br /> J. Rajahalme, A. Conta, B. Carpenter, S. Deering, IPv6 Flow Label Specification, RFC3697, 2004 <br /> <br /> <br /> <br /> <br /> However, this proposal is far from being widely used and deployed. <br />
  • The IPv6 packet format is described in <br /> S. Deering, B. Hinden, Internet Protocol, Version 6 (IPv6) Specification , RFC2460, Dec 1998 <br /> <br /> <br /> <br /> <br /> <br /> <br /> Several documents have been written about the usage of the Flow label. The last one is <br /> <br /> <br /> <br /> J. Rajahalme, A. Conta, B. Carpenter, S. Deering, IPv6 Flow Label Specification, RFC3697, 2004 <br /> <br /> <br /> <br /> <br /> However, this proposal is far from being widely used and deployed. <br />
  • IPv6 does not require changes to TCP and UDP for IPv4. The only modification is the computation of the checksum field of the UDP and TCP headers since this checksum is computed by concerning a pseudo header that contains the source and destination IP addresses. <br />
  • IPv6 does not require changes to TCP and UDP for IPv4. The only modification is the computation of the checksum field of the UDP and TCP headers since this checksum is computed by concerning a pseudo header that contains the source and destination IP addresses. <br />
  • IPv6 does not require changes to TCP and UDP for IPv4. The only modification is the computation of the checksum field of the UDP and TCP headers since this checksum is computed by concerning a pseudo header that contains the source and destination IP addresses. <br />
  • IPv6 does not require changes to TCP and UDP for IPv4. The only modification is the computation of the checksum field of the UDP and TCP headers since this checksum is computed by concerning a pseudo header that contains the source and destination IP addresses. <br />
  • An example hop-by-hop option is the router alert option defined in <br /> A. Jackson, C. Partridge, IPv6 Router Alert Option RFC2711, 1999 <br /> <br /> <br />
  • The Type 0 Routing header is specified in RFC2460 <br /> <br /> <br /> <br /> Two other types of routing headers have been defined. Type 1 is experimental and never used. Type 2 is specific for Mobile IPv6 that will be covered later. <br /> <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • The type 0 routing header was deprecated in <br /> J. Abley, P. Savola, G. Neville-Neil, Deprecation of Type 0 Routing Headers in IPv6 RFC5095, Dec. 2007 <br /> <br /> <br /> <br /> For more information about the security issues with this header, see <br /> Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest Security Conference 2007, <br /> April 2007. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br /> <br /> The Len field encodes the size of the data field in bytes. Furthermore, special options have been defined to allow hosts using the options to pad the size of vairable length options to multiples of 64 bits. <br /> <br /> <br /> <br /> Pad1 option (alignment requirement: none) <br /> <br /> <br /> <br /> +-+-+-+-+-+-+-+-+ <br /> | 0 | <br /> +-+-+-+-+-+-+-+-+ <br /> <br /> <br /> <br /> NOTE! the format of the Pad1 option is a special case -- it does <br /> not have length and value fields. <br /> <br /> <br /> <br /> The Pad1 option is used to insert one octet of padding into the <br /> Options area of a header. If more than one octet of padding is <br /> required, the PadN option, described next, should be used, rather <br /> than multiple Pad1 options. <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> Deering & Hinden Standards Track [Page 10] <br /> <br /> RFC 2460 IPv6 Specification December 1998 <br /> <br /> <br /> <br /> <br /> <br /> <br /> PadN option (alignment requirement: none) <br /> <br /> <br /> <br /> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - <br /> | 1 | Opt Data Len | Option Data <br /> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - <br /> <br /> <br /> <br /> The PadN option is used to insert two or more octets of padding <br /> into the Options area of a header. For N octets of padding, the <br /> Opt Data Len field contains the value N-2, and the Option Data <br /> consists of N-2 zero-valued octets. <br /> <br /> <br />
  • As of today, it is unclear whether the jumbogram option has been implemented in practice. Using it requires link layer technologies that are able to support frames larger than 64 KBytes. <br /> <br /> <br /> <br /> The jumbogram option has been defined in <br /> <br /> <br /> <br /> D. Borman, S. Deering, B. Hinden, IPv6 Jumbograms, RFC2675, August 1999 <br /> <br /> <br /> <br /> <br /> The Kame (http://www.kame.net) implementation on FreeBSD supports this option, but there is no link-layer that supports large frames. <br />
  • Path MTU discovery is defined in <br /> <br /> <br /> <br /> J. Mogul, S. Deering, Path MTU Discovery, RFC1191, 1996 <br /> and in <br /> J. McCann, S. Deering, J. Mogul, Path MTU Discovery for IP version 6, RFC1981, 1996 <br /> for IPv6 <br /> <br /> <br />
  • Path MTU discovery is defined in <br /> <br /> <br /> <br /> J. Mogul, S. Deering, Path MTU Discovery, RFC1191, 1996 <br /> and in <br /> J. McCann, S. Deering, J. Mogul, Path MTU Discovery for IP version 6, RFC1981, 1996 <br /> for IPv6 <br /> <br /> <br />
  • In IPv6, the fragment identification field is much larger than in IPv4. Furthermore, it is only used in packets that really need fragmentation. IPv6 header does not contain a fragmentation information for each unfragmented packet unlike IPv4. <br />
  • ICMPv6 is defined in : <br /> A. Conta, S. Deering, M. Gupta, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC4443, March 2006 <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />
  • ICMPv6 uses a next header value of 58 inside IPv6 packets <br />
  • ICMPv6 uses a next header value of 58 inside IPv6 packets <br />
  • ICMPv6 uses a next header value of 58 inside IPv6 packets <br />
  • <br /> <br />
  • Pour une description d&#xE9;taill&#xE9;e des firewalls, voir par exemple : <br /> <br /> Cheswick, William R., Bellovin, Steven M., Rubin, Aviel D. Firewalls and internet security - Second edition - Repelling the Wily Hacker, Addison-Wesley 2003 <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Dans ce cas, le NAT devra modifier l&apos;adresse source des paquets allant du r&#xE9;seau interne vers le r&#xE9;seau externes et l&apos;adresse destination des paquets IP allant dans le sens inverse. <br /> <br /> <br /> <br /> Le temporisateur mentionn&#xE9; dans le transparent East une des solutions possibles pour &#xE9;viter qu&apos;une adresse publique ne soit associ&#xE9;e &#xE9;ternellement &#xE0; une adresse priv&#xE9;e. Une autre solution East d&apos;analyser les paquets &#xE9;chang&#xE9;s et par exemple si seul du trafic TCP East &#xE9;chang&#xE9; de lib&#xE9;rer l&apos;adresse IP publique lorsqu&apos;aucun paquet n&apos;a &#xE9;t&#xE9; re&#xE7;u durant une p&#xE9;riode de x secondes ou minutes. <br />
  • <br /> <br /> <br /> Le NAT d&#xE9;crit dans le transparent ci-dessus doit donc : <br /> <br /> modifier les champs adresse source (de l&apos;ent&#xEA;te IP) et port source (de l&apos;ent&#xEA;te TCP ou UDP) dans le sens r&#xE9;seau interne -> Internet <br /> <br /> <br /> modifier les champs adresse destination (de l&apos;ent&#xEA;te IP) et port destination (de l&apos;ent&#xEA;te TCP ou UDP) dans le sens Internet -> r&#xE9;seau internet <br /> <br /> Lorsqu&apos;il modifie ces champs, le NAT East oblig&#xE9; de recalculer le checksum se trouvant dans l&apos;ent&#xEA;te IP et celui se trouvant dans l&apos;ent&#xEA;te transport. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Source : http://www.belnet.be <br />
  • Source http://www.dante.net <br />
  • Source http://www.uu.net <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • La version actuelle de RIP East d&#xE9;finie dans <br /> RFC2453 RIP Version 2. G. Malkin. November 1998 <br /> <br /> <br /> <br /> Une autre description de RIP East disponible dans : <br /> Gary Malkin, RIP : an intra-domain routing protocol, Addison-Wesley, 2002 <br /> <br /> <br /> <br /> IP multicast East couvert dans le cours avanc&#xE9;. A ce stade, il suffit de consid&#xE9;rer IP multicast (avec TTL=1) comme &#xE9;tant un m&#xE9;canisme permettant &#xE0; un routeur connect&#xE9; sur un r&#xE9;seau local d&apos;envoyer, en une seule transmission, un paquet qui sera re&#xE7;u par tous les routeurs RIP connect&#xE9;s &#xE0; ce r&#xE9;seau local. <br />
  • <br /> <br />
  • <br /> <br />
  • Ce probl&#xE8;me de synchronisation des messages &#xE9;chang&#xE9;s par les protocoles de routage a &#xE9;t&#xE9; d&#xE9;crit dans : <br /> <br /> <br /> <br /> The Synchronization of Periodic Routing Messages , Floyd, S., and Jacobson, V. IEEE/ACM Transactions on Networking, V.2 N.2, p. 122-136, April 1994. <br />
  • <br /> <br />
  • Pour plus d&#xA0;&apos;informations sur OSPF, voir <br /> RFC2328 OSPF Version 2. J. Moy. April 1998. <br /> ou <br /> J. Moy, OSPF: Anatomy of an Internet Routing Protocol, Addison Wesley, 1998 <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • Cet exemple ne pr&#xE9;sente que les informations de routage concernant les sous-r&#xE9;seaux indiqu&#xE9;s sur le sch&#xE9;ma. Les adresses des routeurs sont ignor&#xE9;es pour simplifier l&apos;exemple. <br />
  • <br /> <br />
  • <br /> <br />
  • For more information on the organization of the Internet, see : <br /> <br /> <br /> <br /> <br /> G. Huston, Peerings and settlements, Internet Protocol Journal, Vol. 2, N1 et 2, 1999, <br /> <br /> http://www.cisco.com/warp/public/759/ipj_Volume2.html <br /> <br /> <br /> <br /> <br /> <br /> For more information on interconnection points or Internet exchanges, see : <br /> <br /> <br /> <br /> <br /> http: <br /> <br /> //www.euro-ix.net/ <br /> <br /> <br /> <br /> <br /> http://www.ripe.net/ripe/wg/eix/index.html <br /> <br /> <br /> <br /> <br /> http://www.ep.net/ep-main.html <br /> <br /> <br />
  • <br /> <br />
  • On link AS7-AS4 <br /> AS7 advertises its own routes to AS4 <br /> AS4 advertises to AS7 the routes that allow to reach the entire Internet <br /> On link AS4-AS2 <br /> AS4 advertises its own routes and the routes belonging to AS7 <br /> AS2 advertises the routes that allow to reach the entire Internet <br />
  • On link AS3-AS4 <br /> AS3 advertises its internal routes <br /> AS4 advertises its internal routes and the routes learned from AS7 (its customer) <br /> On link AS1-AS2 <br /> AS1 advertises its internal routes and the routes received from AS3 and AS4 (its customers) <br /> AS2 advertises its internal routes and the routes learned from AS74(its customer) <br />
  • <br /> <br />
  • <br /> <br />
  • RFC 2622 Routing Policy Specification Language (RPSL). C. Alaettinoglu, C. <br /> <br /> Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, <br /> <br /> <br /> M. Terpstra. June 1999. <br /> <br /> <br /> <br /> <br /> RFC 2650 Using RPSL in Practice. D. Meyer, J. Schmitz, C. Orange, M. <br /> <br /> Prior, C. Alaettinoglu. August 1999. <br /> <br /> <br /> <br /> <br /> Internet Routing Registries contain the routing policies of various ISPs, see : <br /> <br /> <br /> <br /> <br /> <br /> http://www.ripe.net/ripencc/pub-services/whois.html <br /> <br /> <br /> <br /> <br /> http://www.arin.net/whois/index.html <br /> <br /> <br /> <br /> <br /> http://www.apnic.net/apnic-bin/whois.pl <br /> <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • See : <br /> <br /> <br /> <br /> <br /> L. Subramanian, S. Agarwal, J. Rexford, and RH Katz. Characterizing the Internet hierarchy from multiple vantage points. In IEEE INFOCOM, 2002 <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • In the above export filter, we assume that the BGP sender does not send to PeerX the routes learned from this peer. This behavior is not required by the BGP specification, but is a common optimization, often called sender-side loop detection. <br /> <br /> <br /> <br /> The check for the presence of the localAS number in the routes learned is specified in the BGP RFC. <br />
  • <br /> <br />
  • <br /> <br />
  • If link AS10-AS20 goes down, AS20 will not consider anymore the path learned from AS10. It will thus remove this path from its routing table and will instead select the path learned from AS40. This will force AS20 to send the following UPDATE to AS30 : <br />
  • If link AS10-AS20 goes down, AS20 will not consider anymore the path learned from AS10. It will thus remove this path from its routing table and will instead select the path learned from AS40. This will force AS20 to send the following UPDATE to AS30 : <br />
  • If link AS10-AS20 goes down, AS20 will not consider anymore the path learned from AS10. It will thus remove this path from its routing table and will instead select the path learned from AS40. This will force AS20 to send the following UPDATE to AS30 : <br />
  • If link AS10-AS20 goes down, AS20 will not consider anymore the path learned from AS10. It will thus remove this path from its routing table and will instead select the path learned from AS40. This will force AS20 to send the following UPDATE to AS30 : <br />
  • If link AS10-AS20 goes down, AS20 will not consider anymore the path learned from AS10. It will thus remove this path from its routing table and will instead select the path learned from AS40. This will force AS20 to send the following UPDATE to AS30 : <br />
  • In this example, we only consider the BGP messages concerning the following IP networks :194.100.0.0/24, 194.100.1.0.0/24 and 194.100.2.0/23. Routes concerning networks 195.100.* also need to be distributed in practice, but they are not considered in the example. <br /> <br /> <br /> <br /> The UPDATE message carries the ASPath in order to be able to detect routing loops. <br /> <br /> <br /> <br /> The nexthop information in the UPDATE is often equal to the IP address of the router advertising the route, but it can be sometimes useful to advertise as a next hop another IP address than the address of the router producing the BGP UPDATE message. For example, a router supporting BGP could advertise a route on behalf of another router who cannot run the BGP protocol. <br />
  • In this example, we only consider the BGP messages concerning the following IP networks :194.100.0.0/24, 194.100.1.0.0/24 and 194.100.2.0/23. Routes concerning networks 195.100.* also need to be distributed in practice, but they are not considered in the example. <br /> <br /> <br /> <br /> The UPDATE message carries the ASPath in order to be able to detect routing loops. <br /> <br /> <br /> <br /> The nexthop information in the UPDATE is often equal to the IP address of the router advertising the route, but it can be sometimes useful to advertise as a next hop another IP address than the address of the router producing the BGP UPDATE message. For example, a router supporting BGP could advertise a route on behalf of another router who cannot run the BGP protocol. <br />
  • In this example, we only consider the BGP messages concerning the following IP networks :194.100.0.0/24, 194.100.1.0.0/24 and 194.100.2.0/23. Routes concerning networks 195.100.* also need to be distributed, but they are not considered in the example. <br />
  • In this example, we only consider the BGP messages concerning the following IP networks :194.100.0.0/24, 194.100.1.0.0/24 and 194.100.2.0/23. Routes concerning networks 195.100.* also need to be distributed, but they are not considered in the example. <br />
  • In this example, we only consider the BGP messages concerning the following IP networks :194.100.0.0/24, 194.100.1.0.0/24 and 194.100.2.0/23. Routes concerning networks 195.100.* also need to be distributed, but they are not considered in the example. <br />
  • In this example, we only consider the BGP messages concerning the following IP networks :194.100.0.0/24, 194.100.1.0.0/24 and 194.100.2.0/23. Routes concerning networks 195.100.* also need to be distributed, but they are not considered in the example. <br />
  • In this example, we only consider the BGP messages concerning the following IP networks :194.100.0.0/24, 194.100.1.0.0/24 and 194.100.2.0/23. Routes concerning networks 195.100.* also need to be distributed, but they are not considered in the example. <br />
  • <br /> <br />
  • <br /> <br />
  • Note that in RPSL, the set localpref construct does not exist. It is replaced with action preference=x. Unfortunately, in RPSL the routes with the lowest preference are preferred. RPSL uses thus the opposite of local-pref.... <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • In practice, the exchange of BGP UPDATE messages will cease due to the utilization of timers by BGP routers and the routing will stabilize on one of the two stable route assignments. <br />
  • This local-pref settings corresponds to the economical relationships between the various ASes. <br /> Since AS1 is paid to carry packets towards Cust1 and Cust2, it will select a route towards those networks whenever possible. <br /> Since AS1 does not need to pay to carry packets towards Peer1-4, AS1 will select a route towards those networks whenever possible. <br /> AS1 will only utilize the routes receive from its providers when there is no other choice. <br /> <br /> <br /> <br /> It is shown in the following papers that this way of utilizing the local-pref attribute leads to stable BGP routes : <br /> Lixin Gao, Timothy G. Griffin, and Jennifer Rexford, "Inherently safe backup <br /> routing with BGP," Proc. IEEE INFOCOM, April 2001 <br /> Lixin Gao and Jennifer Rexford, "Stable Internet routing without global <br /> coordination," IEEE/ACM Transactions on Networking, December 2001, pp. <br /> 681-692 <br /> <br /> <br /> <br /> The RPSL policy of AS1 could be as follows : <br /> RPSL policy for AS1 <br /> aut-num: AS1 <br /> <br /> import: from Cust1 action set localpref=200; accept Cust1 <br /> <br /> <br /> from Cust2 action set localpref=200; accept Cust2 <br /> <br /> <br /> from Peer1 action set localpref=150; accept Peer1 <br /> <br /> <br /> from Peer2 action set localpref=160; accept Peer2 <br /> <br /> <br /> from Peer3 action set localpref=170; accept Peer3 <br /> <br /> <br /> from Peer4 action set localpref=180; accept Peer4 <br /> <br /> <br /> from Prov1 action set localpref=100; accept ANY <br /> <br /> <br /> from Prov2 action set localpref=100; accept ANY <br /> <br /> <br />
  • Due to the utilization of the local-pref attribute, some paths on the Internet are longer than their optimum length, see : <br /> <br /> <br /> <br /> Lixin Gao and Feng Wang , The Extent of AS Path Inflation by Routing Policies, GlobalInternet 2002 <br />
  • <br /> <br />
  • There are regularly discussions on whether the redistribution of BGP routes in an IGP should be removed from BGP implementations. See e.g. <br /> <br /> <br /> http://www.irbs.net/internet/nanog/0210/0140.html <br /> <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • In some cases, it is useful to update the value of BGP nexthop when an UPDATE message is received over an eBGP session. Most BGP implementations support this feature with a command often called &#x201C;nexthop-self&#x201D;. Although this command is useful in some practical situations, we do not discuss its utilization in this course. <br />
  • In some cases, it is useful to update the value of BGP nexthop when an UPDATE message is received over an eBGP session. Most BGP implementations support this feature with a command often called &#x201C;nexthop-self&#x201D;. Although this command is useful in some practical situations, we do not discuss its utilization in this course. <br />
  • In some cases, it is useful to update the value of BGP nexthop when an UPDATE message is received over an eBGP session. Most BGP implementations support this feature with a command often called &#x201C;nexthop-self&#x201D;. Although this command is useful in some practical situations, we do not discuss its utilization in this course. <br />
  • In some cases, it is useful to update the value of BGP nexthop when an UPDATE message is received over an eBGP session. Most BGP implementations support this feature with a command often called &#x201C;nexthop-self&#x201D;. Although this command is useful in some practical situations, we do not discuss its utilization in this course. <br />
  • <br /> <br />
  • The Forwarding table of a router is thus built on the basis of both the IGP table and the BGP table. <br />
  • In this example, the iBGP session between R2 and R4 would be established over a TCP connection. The packets of this connection with source/dest R2 or R4 would be routed from R2 to R4 and the opposite via R5 by using the IGP table. Thus, the IP addresses of the routers must be distributed by the IGP. <br />
  • The solution of using tunnels inside an AS to forward transit packets was discused in the BGP4 applicability RFC : <br /> <br /> <br /> <br /> Y. Rekhter, P. Gross (Eds.), Application of the Border Gateway Protocol in the Internet, RFC1772, March 1995 <br /> <br /> <br /> <br /> However, it only became widespread with the deployment of MPLS. It should be noted that today IP tunnels could also be used inside ASes to transit packets. <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • The BGP decision process also contains a additional step after the ASPath step where the routes with the lowest ORIGIN attribute are preferred. We ignore this step and this attribute in this tutorial. <br /> <br /> <br /> <br /> The BGP decision process used by router vendors may change compared to this theoretical description. For real BGP decision processes, see : <br /> <br /> <br /> <br /> <br /> <br /> http://www.cisco.com/en/US/tech/tk826/tk365/technologies_tech_note09186a0080094431.shtml <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> http://www.riverstonenet.com/support/bgp/routing-model/index.htm#_Route_Selection_Process <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> http://www.juniper.net/techpubs/software/junos53/swconfig53-ipv6/html/routing-overview-ipv69.html <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> http://www.foundrynet.com/services/documentation/ecmg/BGP4.html <br /> <br /> <br /> <br /> <br /> <br /> <br /> There have been some proposals to allow ISPs to change the BGP decision process on their routers to have a better control on the selected routes.A. Retana, R. White, BGP Custom Decision Process, Internet draft, draft-retana-bgp-custom-decision-00.txt, work in progress, 2003 <br /> <br /> <br /> One usage of this decision process may be found in <br /> <br /> http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a008022ab06.html <br />
  • A recent study of the quality of the AS Path as a performance indicator compared the round trip time with the length of the AS Path and has shown that the length of the AS Path was only a good indicator for 50% of the considered paths. See : <br /> <br /> <br /> <br /> Bradley Huffaker, Marina Fomenkov, Daniel J. Plummer, David Moore and k claffy, Distance Metrics in the Internet, Presented at the IEEE International Telecommunications Symposium (ITS) in 2002. <br /> http://www.caida.org/outreach/papers/2002/Distance/ <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> <br />
  • <br /> Note that on some router implementations, the lowest router id step in the BGP decision process is replaced by the selection of the oldest route. See e.g. : <br /> <br /> http://www.cisco.com/warp/public/459/25.shtml <br /> <br /> <br /> Preferring the oldest route when breaking times is used to prefer stable paths over unstable paths, however, a drawback of this approach is that the selection of the BGP routes will depend on the arrival times of the corresponding messages. This makes the BGP selection process non-deterministic and can lead to problems that are difficult to debug. <br />
  • A titre d&apos;exemple concernant l&apos;allocation des adresses IP avec la premi&#xE8;re solution, on peut citer les universit&#xE9;s belges. Actuellement ces universit&#xE9;s se connectent &#xE0; l&apos;Internet &#xE0; travers le r&#xE9;seau Belnet, mais elles utilisent, pour des raisons historiques, des identificateurs de sous-r&#xE9;seaux fort diff&#xE9;rents : <br /> 138.48.0.0/16 pour FUNDP <br /> 139.165.0.0/16 pour Ulg <br /> 130.104.0.0/16 pour l&apos;UCL <br /> Cela implique que le r&#xE9;seau Belne doit annoncer &#xE0; l&apos;ensemble de l&apos;Internet une route pour chaque universit&#xE9; belge plut&#xF4;t que d&apos;annoncer une seule route pour l&apos;ensemble des universit&#xE9;s. <br />
  • <br /> <br />
  • <br /> <br />
  • Pour plus d&apos;informations, voir <br /> <br /> <br /> http://bgp.potaroo.net <br /> <br /> <br /> <br /> <br /> <br /> D&apos;autres sources de donn&#xE9;es utiles sur l&apos;&#xE9;tat des tables BGP sont : <br /> <br /> <br /> http://www.netlantis.org/ <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> http://www.route-views.org <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> http://www.ripe.net/ris/ <br /> <br /> <br />
  • <br /> Source : <br /> <br /> http://bgp.potaroo.net <br /> <br /> <br />
  • <br /> Source : <br /> <br /> http://bgp.potaroo.net <br /> <br /> <br />
  • <br /> Source : <br /> <br /> http://bgp.potaroo.net <br /> <br /> <br />
  • <br /> Source : <br /> <br /> http://bgp.potaroo.net <br /> <br /> <br />
  • <br /> Source : <br /> <br /> http://bgp.potaroo.net <br /> <br /> <br />

4 network.key 4 network.key Presentation Transcript

  • Computer Networking : Principles, Protocols and Practice Part 4 : Network Layer Olivier Bonaventure http://inl.info.ucl.ac.be/ CNPP/2008.4. © O. Bonaventure 2008
  • Network layer  Basics  Datagram mode  Virtual circuits  Routing  IP : Internet Protocol  Routing in IP networks CNPP/2008.4. © O. Bonaventure, 2007
  • The network layer Transport Transport Packets Packets Network Network Network Datalink Datalink Datalink Physical Physical Physical  Goal  Allow packets to be forwarded from any source to any destination through heterogeneous networks and routers  Services  Unreliable connectionless service  Reliable connection-oriented service CNPP/2008.4. © O. Bonaventure, 2007
  • Two types of datalink layers CNPP/2008.4. © O. Bonaventure, 2007
  • Two types of datalink layers  WAN type datalink layer  PPP, HDLC  Reliable exchange of frames between two hosts attached to the same “link”  Mainly used by wide area networks CNPP/2008.4. © O. Bonaventure, 2007
  • Two types of datalink layers  WAN type datalink layer  PPP, HDLC  Reliable exchange of frames between two hosts attached to the same “link”  Mainly used by wide area networks CNPP/2008.4. © O. Bonaventure, 2007
  • Two types of datalink layers  WAN type datalink layer  PPP, HDLC  Reliable exchange of frames between two hosts attached to the same “link”  Mainly used by wide area networks  LAN type datalink layer  Ethernet, Token Ring, FDDI, WiFi, Wimax,  Exchange of frames between hosts attached to the same LAN  limited geographical coverage CNPP/2008.4. © O. Bonaventure, 2007
  • The datalink service Network Network Datalink Frames Datalink Physical Physical  Service of datalink layer  Unreliable connectionless service  Transmission of frames between hosts directly connected at the physical layer or directly attached to the same LAN  Unreliable transmission (frames can be lost but usually transmission errors are detected)  Most datalink layers have maximum frame length  Connection-oriented service, reliable or not  Transmission of frames between hosts directly connected at the physical layer or directly attached to the same LAN  Reliable or unreliable transmission CNPP/2008.4. © O. Bonaventure, 2007
  • Routers LD1 R LANα R LANβ Network Network Network Network DL1 DL1 LANα LANα LANβ LANβ  Router  Relay within the network layer  packet is unit of transmission CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer Basic principles CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer Basic principles  Each host/router must be identified by a network layer address which is independent from its datalink layer address CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer Basic principles  Each host/router must be identified by a network layer address which is independent from its datalink layer address  Network layer forwards packets from source to destination through multiple routers CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer Basic principles  Each host/router must be identified by a network layer address which is independent from its datalink layer address  Network layer forwards packets from source to destination through multiple routers  Network layer service must be completely independent from the service provided by the datalink layer CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer Basic principles  Each host/router must be identified by a network layer address which is independent from its datalink layer address  Network layer forwards packets from source to destination through multiple routers  Network layer service must be completely independent from the service provided by the datalink layer  Network layer user should not need to know anything about the internal structure of the network layer to be able to send packets CNPP/2008.4. © O. Bonaventure, 2007
  • Internal organisation of the network layer CNPP/2008.4. © O. Bonaventure, 2007
  • Internal organisation of the network layer  Two possible organisations  datagrams  virtual circuits CNPP/2008.4. © O. Bonaventure, 2007
  • Internal organisation of the network layer  Two possible organisations  datagrams  virtual circuits  The internal organisation of the network is orthogonal to the service provided, but often  datagram mode is used to provide a connectionless service  virtual circuits are used to provide a connection- oriented service CNPP/2008.4. © O. Bonaventure, 2007
  • Datagram transmission mode CNPP/2008.4. © O. Bonaventure, 2007
  • Datagram transmission mode  Basics  Each route/host is identified by an address  Information is divided in packets  Each packet contains  Source address  Destination address  Payload  Router behavior  Upon packet arrival look at destination address and routing table to decide where the packet should be forwarded  hop-by-hop forwarding, each routers takes a forwarding decision CNPP/2008.4. © O. Bonaventure, 2007
  • Datagram transmission mode  Basics  Each route/host is identified by an address  Information is divided in packets  Each packet contains  Source address  Destination address  Payload  Router behavior  Upon packet arrival look at destination address and routing table to decide where the packet should be forwarded  hop-by-hop forwarding, each routers takes a forwarding decision  Examples  IP (IPv4 and IPv6)  CLNP  IPX CNPP/2008.4. © O. Bonaventure, 2007
  • Datagram transmission mode (2) R1ʼs routing table A via West R5ʼs routing table ... A via West R2ʼs routing table ... I via East A via West J via East I via West ... J via East I via South-East Addr:B J via East Addr:E R1 Addr:D R5 Addr:A R2 R3ʼs routing table Addr:H A via North-West Addr:C ... Addr:I I via North-East R4 J via North-East R3 Addr:J R4ʼs routing table  The routing tables of all routers must be A via North ... coherent to ensure that a packet sent by I via West any source will reach its destination J via North CNPP/2008.4. © O. Bonaventure, 2007
  • Datagram transmission mode (2) R1ʼs routing table A via West R5ʼs routing table ... A via West R2ʼs routing table ... I via East A via West J via East I via West ... J via East I via South-East Addr:B J via East Addr:E R1 Addr:D SRC:A Dst:J BlaBla R5 Addr:A R2 R3ʼs routing table Addr:H A via North-West Addr:C ... Addr:I I via North-East R4 J via North-East R3 Addr:J R4ʼs routing table  The routing tables of all routers must be A via North ... coherent to ensure that a packet sent by I via West any source will reach its destination J via North CNPP/2008.4. © O. Bonaventure, 2007
  • Datagram transmission mode (2) R1ʼs routing table A via West R5ʼs routing table ... A via West R2ʼs routing table ... I via East A via West J via East I via West ... J via East I via South-East Addr:B J via East Addr:E R1 Addr:D SRC:A Dst:J BlaBla R5 Addr:A R2 R3ʼs routing table Addr:H A via North-West Addr:C ... Addr:I I via North-East R4 J via North-East R3 Addr:J R4ʼs routing table  The routing tables of all routers must be A via North ... coherent to ensure that a packet sent by I via West any source will reach its destination J via North CNPP/2008.4. © O. Bonaventure, 2007
  • Datagram transmission mode (2) R1ʼs routing table A via West R5ʼs routing table ... A via West R2ʼs routing table ... I via East A via West J via East I via West ... J via East I via South-East Addr:B J via East Addr:E R1 Addr:D SRC:A Dst:J BlaBla R5 Addr:A R2 R3ʼs routing table Addr:H A via North-West Addr:C ... Addr:I I via North-East R4 J via North-East R3 Addr:J R4ʼs routing table  The routing tables of all routers must be A via North ... coherent to ensure that a packet sent by I via West any source will reach its destination J via North CNPP/2008.4. © O. Bonaventure, 2007
  • Datagram transmission mode (2) R1ʼs routing table A via West R5ʼs routing table ... A via West R2ʼs routing table ... I via East A via West J via East I via West ... J via East I via South-East Addr:B J via East Addr:E R1 Addr:D SRC:A Dst:J BlaBla R5 Addr:A R2 R3ʼs routing table Addr:H A via North-West Addr:C ... Addr:I I via North-East R4 J via North-East R3 Addr:J R4ʼs routing table  The routing tables of all routers must be A via North ... coherent to ensure that a packet sent by I via West any source will reach its destination J via North CNPP/2008.4. © O. Bonaventure, 2007
  • Virtual circuit organisation CNPP/2008.4. © O. Bonaventure, 2007
  • Virtual circuit organisation  Goals  Keep forwarding on the routers as simple as possible  consulting a routing table for each packet is costly from a performance viewpoint CNPP/2008.4. © O. Bonaventure, 2007
  • Virtual circuit organisation  Goals  Keep forwarding on the routers as simple as possible  consulting a routing table for each packet is costly from a performance viewpoint  Solution  Before transmitting packets containing data, create a virtual circuit that links source and destination through the network  During the virtual circuit establishment, efficient datastructures are updated on each transit router to simplify forwarding  Use the virtual circuits to forward the packets  All packets will follow the same path CNPP/2008.4. © O. Bonaventure, 2007
  • Virtual circuit organisation  Goals  Keep forwarding on the routers as simple as possible  consulting a routing table for each packet is costly from a performance viewpoint  Solution  Before transmitting packets containing data, create a virtual circuit that links source and destination through the network  During the virtual circuit establishment, efficient datastructures are updated on each transit router to simplify forwarding  Use the virtual circuits to forward the packets  All packets will follow the same path  Example  ATM, X.25, Frame Relay, MPLS, gMPLS CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Addr:B Addr:E R1 Addr:D R5 Addr:A R2 Addr:H Addr:C Addr:I R4 R3 Addr:J CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Addr:E R1 Addr:D R5 Addr:A R2 Addr:H Addr:C Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Open(Dest=J) Addr:E R1 Addr:D R5 Addr:A R2 Addr:H Addr:C Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Open(Dest=J) Open(Dest=J) Addr:E R1 Addr:D R5 Addr:A R2 Addr:H Addr:C Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Open(Dest=J) Open(Dest=J) Addr:E Open(Dest=J) R1 Addr:D R5 Addr:A R2 Addr:H Addr:C Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Open(Dest=J) Open(Dest=J) Addr:E Open(Dest=J) R1 Addr:D R5 Addr:A Open(Dest=I) R2 Addr:H Addr:C Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment Source routing/ explicit routing Source (or first hop router) indicates in vc establishment packet the path to be followed CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Open(Dest=J) Open(Dest=J) Addr:E Open(Dest=J) R1 Addr:D R5 Addr:A Open(Dest=I) R2 Addr:H Addr:C Open(Dest=I; Route=R3,R2,R4)) Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment Source routing/ explicit routing Source (or first hop router) indicates in vc establishment packet the path to be followed CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Open(Dest=J) Open(Dest=J) Addr:E Open(Dest=J) R1 Addr:D R5 Addr:A Open(Dest=I) R2 Open(Dest=I; Route=R2,R4)) Addr:H Addr:C Open(Dest=I; Route=R3,R2,R4)) Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment Source routing/ explicit routing Source (or first hop router) indicates in vc establishment packet the path to be followed CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Open(Dest=J) Open(Dest=J) Addr:E Open(Dest=J) R1 Addr:D R5 Addr:A Open(Dest=I) R2 Open(Dest=I; Route=R2,R4)) Open(Dest=I; Route=R4)) Addr:H Addr:C Open(Dest=I; Route=R3,R2,R4)) Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment Source routing/ explicit routing Source (or first hop router) indicates in vc establishment packet the path to be followed CNPP/2008.4. © O. Bonaventure, 2007
  • Establishment of a virtual circuit Open(Dest=J) Addr:B Open(Dest=J) Open(Dest=J) Addr:E Open(Dest=J) R1 Addr:D R5 Addr:A Open(Dest=I) R2 Open(Dest=I; Route=R2,R4)) Open(Dest=I; Route=R4)) Addr:H Addr:C Open(Dest=I; Route=R3,R2,R4)) Addr:I R4 R3 Addr:J Hop-by-hop routing Each router consults its routing table to forward vc establishment Source routing/ explicit routing Source (or first hop router) indicates in vc establishment packet the path to be followed CNPP/2008.4. © O. Bonaventure, 2007
  • Packet transmission Addr:B Addr:E R1 Addr:D R5 Addr:A R2 Circuit:123 BlaBla Addr:H Addr:C Addr:I R4 R3 Addr:J  Packet contents  virtual circuit identifier  packet payload  What kind of virtual circuit identifier  Naive solution  unique identifier for all virtual circuits inside network  How to coordinate allocation of vc identifiers ? CNPP/2008.4. © O. Bonaventure, 2007
  • Packet transmission (2)  How unique should virtual circuits identifiers be ?  globally unique  unrealistic  unique inside a given network  then coordination among routers is necessary  unique on a given link  easier to manage, no coordination required, but  virtual circuit identifier may need to be changed from link to link  How to update the virtual circuit identifier of packets  All routers must contain a label forwarding table  this table is updated every time a virtual circuit is established Label forwarding table Inport Inlabel Outport Outlabel West L1 East L1 West L2 East L3 N-W L1 North L1 CNPP/2008.4. © O. Bonaventure, 2007
  • Virtual circuits : example Label forwarding table Inport Inlabel Outport Outlabel Label table South L2 S- E L1 Flow1 : L1 via BR1 Flow2 : L2 via BR1 BR2 BR3 BR1 Label table Flow3 : L1 via BR1 Label forwarding table Label forwarding table Inport Inlabel Outport Outlabel Inport Inlabel Outport Outlabel West L1 East L1 West L1 North L2 West L2 East L3 West L2 East L1 N-W L1 North L1 S-W L1 East L2 CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer  Basics  Routing  Static routing  Distance vector routing  Link state routing  IP : Internet Protocol  Routing in IP networks CNPP/2008.4. © O. Bonaventure, 2007
  • Routing and Forwarding  Main objective of network layer  transport packets form source to destination  Two mechanisms are used in network layer  forwarding  algorithm use by each router to determine on which interface each packet should be sent to reach its destination or follow its virtual circuit  relies on the routing table maintained by each router  routing  algorithm (usually distributed) that distributes to all routers the information that allows them to build their routing tables CNPP/2008.4. © O. Bonaventure, 2007
  • Routing (2)  How to build the routing tables of each router ? A B CC D EE  Principle  Include in the routing table of each router the path to allow it to reach each destination  Which path to be included in the routing table  From A to C ?  From D to B CNPP/2008.4. © O. Bonaventure, 2007
  • Selection of the shortest paths Cost=1 Cost=1 A B CC Cost=1 Cost=1 Cost=1 Cost=1 D EE  Principle  Associate a weight/cost to each link  Each router chooses the lowest cost path  How to ensure that the routing tables of all routers are coherent ? CNPP/2008.4. © O. Bonaventure, 2007
  • Selection of the shortest paths Routing table A : Local D : South B : East C : East [via B] E: East [via B] Cost=1 Cost=1 A B CC Cost=1 Cost=1 Cost=1 Cost=1 D EE  Principle  Associate a weight/cost to each link  Each router chooses the lowest cost path  How to ensure that the routing tables of all routers are coherent ? CNPP/2008.4. © O. Bonaventure, 2007
  • Selection of the shortest paths Routing table Routing table A : West A : Local B : Local D : South C : East B : East D : South [via E] C : East [via B] E : South E: East [via B] Cost=1 Cost=1 A B CC Cost=1 Cost=1 Cost=1 Cost=1 D EE  Principle  Associate a weight/cost to each link  Each router chooses the lowest cost path  How to ensure that the routing tables of all routers are coherent ? CNPP/2008.4. © O. Bonaventure, 2007
  • Selection of the shortest paths Routing table Routing table A : West Routing table A : Local B : Local A : West [via B] D : South C : East B : West B : East D : South [via E] C : Local C : East [via B] E : South D : West [via B] E: East [via B] E : South West Cost=1 Cost=1 A B CC Cost=1 Cost=1 Cost=1 Cost=1 D EE  Principle  Associate a weight/cost to each link  Each router chooses the lowest cost path  How to ensure that the routing tables of all routers are coherent ? CNPP/2008.4. © O. Bonaventure, 2007
  • Selection of the shortest paths Routing table Routing table A : West Routing table A : Local B : Local A : West [via B] D : South C : East B : West B : East D : South [via E] C : Local C : East [via B] E : South D : West [via B] E: East [via B] E : South West Cost=1 Cost=1 A B CC Routing table A : North Cost=1 Cost=1 B : North [via A] Cost=1 C : East [via E] D : Local Cost=1 E : East D EE  Principle  Associate a weight/cost to each link  Each router chooses the lowest cost path  How to ensure that the routing tables of all routers are coherent ? CNPP/2008.4. © O. Bonaventure, 2007
  • Selection of the shortest paths Routing table Routing table A : West Routing table A : Local B : Local A : West [via B] D : South C : East B : West B : East D : South [via E] C : Local C : East [via B] E : South D : West [via B] E: East [via B] E : South West Cost=1 Cost=1 A B CC Routing table A : North Cost=1 Cost=1 Routing table B : North [via A] A : North [via B] Cost=1 B : North C : East [via E] D : Local Cost=1 C : North-East E : East D EE D : West E : Local  Principle  Associate a weight/cost to each link  Each router chooses the lowest cost path  How to ensure that the routing tables of all routers are coherent ? CNPP/2008.4. © O. Bonaventure, 2007
  • Static Routing  Principle  Network manager or network management station computes all routing tables and downloads them on all routers  How to compute routing tables ?  shortest path algorithms  more complex algorithms to provide load balancing or traffic engineering  Advantages of static routing  Easy to use in a small network  routing tables can be optimised  Drawbacks of static routing  does not adapt dynamically to network load  how to deal with link and router failures ? CNPP/2008.4. © O. Bonaventure, 2007
  • Dynamic or distributed routing  Principle  routers exchange messages and use a distributed algorithm to build their routing tables  used in almost all networks  Advantages  can easily adapt routing tables to events  Drawbacks  more complex to implement than static routing  Most common distributed routing methods  Distance vector routing  Link state routing CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer  Basics  Routing  Static routing  Distance vector routing  Link state routing  IP : Internet Protocol  Routing in IP networks CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vector routing  Basic principles Cost=1 Cost=1  Configuration of each router R  Cost of each link Cost=2  When it boots, a router only knows itself  Each router sends periodically to all its neighbours a vector that contains for each destination that it knows 1. Destination address 2. Distance between transmitting router and destination • distance vector is a summary of the routerʼs routing table  Each router will update its routing table based on the information received from its neighbours CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vector routing (2)  Routing table maintained by router  For each destination d inside routing table  R[d].cost = total cost of shortest path to reach d  R[d].link = outgoing link used to reach d via shortest path  Distance vector sent to neighbours  For each destination d  V[d].cost = total cost of shortest path to reach d Every N seconds: Vector=null; for each destination=d in R[] { Vector=Vector+Pair(d,R[d].cost); } for each interface { Send(Vector); } CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vector routing (3)  Processing of received distance vectors Received(Vector V[],link l) { /* received vector from link l */ for each destination=d in V[] { if (d isin R[]) { if ((V[d].cost+l.cost) < R[d].cost) { /* shorter path */ R[d].cost=V[d].cost+l.cost; R[d].link=l; } } else { /* new route */ R[d].cost=V[d].cost+l.cost; R[d].link=l; } } CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example  All links have a unit cost Routing table Routing table B : 0 [Local] Routing table A : 0 [ Local ] C : 0 [Local] A B CC Routing table D : 0 [Local] Routing table D D EE E : 0 [Local] CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example  All links have a unit cost Routing table Routing table B : 0 [Local] Routing table A : 0 [ Local ] C : 0 [Local] A=0 A B CC A=0 Routing table D : 0 [Local] Routing table D D EE E : 0 [Local] When a router boots, it only knows itself. Its distance vector thus contains only its address CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (2) Routing table Routing table B : 0 [Local] Routing table A : 0 [ Local ] A : 1 [West] C : 0 [Local] A B CC D=0 ; A=1 Routing table D : 0 [Local] Routing table A : 1 [North] D D EE E : 0 [Local] D=0 ; A=1 CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (3) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] D : 1 [South] C : 0 [Local] A : 1 [West] A B CC Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D D EE D : 1 [West] A : 2 [West] CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (3) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] D : 1 [South] C : 0 [Local] A : 1 [West] C=0 A B CC C=0 Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D D EE D : 1 [West] A : 2 [West] CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (4) Routing table Routing table B : 0 [Local] Routing table A : 0 [ Local ] A : 1 [West] D : 1 [South] C : 1 [East] C : 0 [Local] A B CC Routing table Routing table E : 0 [Local] D : 0 [Local] D : 1 [West] A : 1 [North] D D EE A : 2 [West] C : 1 [North-East] CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (4) Routing table Routing table B : 0 [Local] Routing table A : 0 [ Local ] A : 1 [West] D : 1 [South] C : 1 [East] C : 0 [Local] A B CC E=0;D=1;A=2;C=1 E=0;D=1;A=2;C=1 Routing table Routing table E : 0 [Local] D : 0 [Local] D : 1 [West] A : 1 [North] D D EE A : 2 [West] C : 1 [North-East] E=0;D=1;A=2;C=1 CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (4) Routing table Routing table B : 0 [Local] Routing table A : 0 [ Local ] A : 1 [West] D : 1 [South] C : 1 [East] C : 0 [Local] A B CC E=0;D=1;A=2;C=1 E=0;D=1;A=2;C=1 Routing table Routing table E : 0 [Local] D : 0 [Local] D : 1 [West] A : 1 [North] D D EE A : 2 [West] C : 1 [North-East] E=0;D=1;A=2;C=1  Reception of distance vector on B  New route to reach E and D, longer route for A  Reception of distance vector on C  New routes to reach D, A and E  Reception of distance vector on D  New routes to reach E and C, longer route for A CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (5)  B is the first to send its vector Routing table B : 0 [Local] A : 1 [West] Routing table Routing table C : 1 [East] C : 0 [Local] A : 0 [ Local ] E : 1 [South] E : 1 [South-West] D : 1 [South] D : 2 [South] D : 2 [South-West] A : 3 [South-West] A B CC Routing table Routing table D : 0 [Local] A : 1 [North] E : 0 [Local] E : 1 [East] D D EE D : 1 [West] A : 2 [West] C : 2 [East] C : 1 [North-East] CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (5)  B is the first to send its vector Routing table B : 0 [Local] A : 1 [West] Routing table Routing table C : 1 [East] C : 0 [Local] A : 0 [ Local ] E : 1 [South] E : 1 [South-West] D : 1 [South] D : 2 [South] D : 2 [South-West] A : 3 [South-West] B=0;A=1;C=1;D=2;E=1 A B CC B=0;A=1;C=1;D=2;E=1 Routing table Routing table D : 0 [Local] A : 1 [North] E : 0 [Local] E : 1 [East] D D EE D : 1 [West] A : 2 [West] C : 2 [East] C : 1 [North-East] CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (6) Routing table Routing table B : 0 [Local] Routing table A : 0 [ Local ] A : 1 [West] C : 0 [Local] D : 1 [South] C : 1 [East] E : 1 [South-West] B : 1 [East] E : 1 [South] D : 2 [South-West] C : 2 [East] D : 2 [South] A : 2 [West] E : 2 [East] B : 1 [West] A B CC Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 1 [East] D D EE A : 2 [West] C : 1 [North-East] C : 2 [East] B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (6) Routing table Routing table B : 0 [Local] Routing table A : 0 [ Local ] A : 1 [West] C : 0 [Local] D : 1 [South] C : 1 [East] E : 1 [South-West] B : 1 [East] E : 1 [South] D : 2 [South-West] C : 2 [East] D : 2 [South] A : 2 [West] E : 2 [East] B : 1 [West] A B CC A=0;B=1;C=2;D=1;E=2 Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 1 [East] D D EE A : 2 [West] C : 1 [North-East] C : 2 [East] B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors example (7) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 1 [West] E : 1 [South-West] B : 1 [East] C : 1 [East] D : 2 [South-West] C : 2 [East] E : 1 [South] A : 2 [West] E : 2 [East] D : 2 [South] B : 1 [West] A B CC Routing table D : 0 [Local] Routing table A : 1 [North] E : 0 [Local] E : 1 [East] D : 1 [West] C : 2 [East] D D EE A : 2 [West] C : 1 [North-East] B : 2 [North] B : 1 [North]  All routers know how to reach all other routers  Routing tables are stable  If a distance vector is sent by one router, it will not cause any change to the routing table of other routers in the network CNPP/2008.4. © O. Bonaventure, 2007
  • Distance vectors Link failures  How to deal with link failures ? A B CC DD EE  Two problems must be solved for failures  How to detect that the link has failed ?  How to indicate to all routers that they should update their routing table since the paths that use link A-B do not work anymore ? CNPP/2008.4. © O. Bonaventure, 2007
  • Detection of link failures  Two types of solutions  rely on failure information from datalink or physical layer  fast and reliable  unfortunately not supported by all datalink/physical layers  ask each router to regularly send its distance vector (e.g. every 30 seconds)  If a router does not receive a refresh for a route in a distance vector from one of its neighbours during some time (e.g. 90 seconds), it assumes that the route is not available anymore CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ?  All routes that use a failed link are marked with an infinite cost Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A:∞ E : 1 [South-West] B:∞ C : 1 [East] D : 2 [South-West] C:∞ E : 1 [South] A : 2 [West] D : 2 [South] B : 1 [West] E:∞ A B CC Routing table A=0;B=∞;C=∞;D=1;E=∞ D : 0 [Local] Routing table A : 1 [North] E : 0 [Local] E : 1 [East] D : 1 [West] C : 2 [East] D D EE A : 2 [West] C : 1 [North-East] B : 2 [North] B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (2)  Reception of a distance vector Received(Vector V[],link l) { /* received vector from link l */ for each destination=d in V[] { if (d isin R[]) { if ( ((V[d].cost+l.cost) < R[d].cost) OR ( R[d].link == l) ) { /* better route or change to current route */ R[d].cost=V[d].cost+l.cost; R[d].link=l; } } else { /* new route */ R[d].cost=V[d].cost+l.cost; R[d].link=l; } } CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (3) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A:∞ E : 1 [South-West] B:∞ C : 1 [East] D : 2 [South-West] C:∞ E : 1 [South] A : 2 [West] D : 2 [South] B : 1 [West] E:∞ A B CC Routing table A=0;B=∞;C=∞;D=1;E=∞ D : 0 [Local] Routing table A : 1 [North] E : 0 [Local] E : 1 [East] D : 1 [West] C : 2 [East] D D EE A : 2 [West] C : 1 [North-East] B : 2 [North] B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (3) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A:∞ E : 1 [South-West] B:∞ C : 1 [East] D : 2 [South-West] C:∞ E : 1 [South] A : 2 [West] D : 2 [South] B : 1 [West] E:∞ A B CC Routing table A=0;B=∞;C=∞;D=1;E=∞ D : 0 [Local] Routing table A : 1 [North] E : 0 [Local] E : 1 [East] D : 1 [West] C : 2 [East] D D EE A : 2 [West] C : 1 [North-East] B : 2 [North] B : 1 [North]  D must remove from its routing tables all the routes that it learned from its North link and are announced now with an ∞ cost CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (4) Routing table Routing table Routing table C : 0 [Local] A : 0 [ Local ] B : 0 [Local] D : 1 [South] E : 1 [South-West] A:∞ D : 2 [South-West] B:∞ C : 1 [East] C:∞ A : 2 [West] E : 1 [South] B : 1 [West] E:∞ D : 2 [South] A B CC Routing table D : 0 [Local] Routing table A : 1 [North] E : 0 [Local] E : 1 [East] D : 1 [West] C : 2 [East] D D EE A : 2 [West] C : 1 [North-East] B:∞ B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (4) Routing table Routing table Routing table C : 0 [Local] A : 0 [ Local ] B : 0 [Local] D : 1 [South] E : 1 [South-West] A:∞ D : 2 [South-West] B:∞ C : 1 [East] C:∞ A : 2 [West] E : 1 [South] B : 1 [West] E:∞ D : 2 [South] A B CC Routing table D=0;B= ∞;A=1;C=2;E=11 D : 0 [Local] Routing table A : 1 [North] E : 0 [Local] E : 1 [East] D : 1 [West] C : 2 [East] D D EE A : 2 [West] C : 1 [North-East] B:∞ B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (5) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A:∞ E : 1 [South-West] B:∞ C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A : 2 [West] E : 2 [South] D : 2 [South] B : 1 [West] B=0;A=∞;C=1;E=1;D=2 A B CC Routing table B=0;A=∞;C=1;E=1;D=2 D : 0 [Local] Routing table A : 1 [North] E : 0 [Local] E : 1 [East] D : 1 [West] C : 2 [East] D D EE A : 2 [West] C : 1 [North-East] B:∞ B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (6) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A:∞ E : 1 [South-West] B:∞ C : 1 [East] D : 2 [South-West] E : 1 [South] A : ∞∞ C : 3 [South] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table D : 0 [Local] A : 1 [North] E : 1 [East] C : 2 [East] D D EE Routing table B:∞ E : 0 [Local] D : 1 [West] A : 2 [West] C : 1 [North-East] B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (6) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A:∞ E : 1 [South-West] B:∞ C : 1 [East] D : 2 [South-West] E : 1 [South] A : ∞∞ C : 3 [South] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table E=0;A=2;D=1;C=1;B=1 D : 0 [Local] E=0;A=2;D=1;C=1;B=1 A : 1 [North] E : 1 [East] C : 2 [East] D D EE Routing table B:∞ E : 0 [Local] E=0;A=2;D=1;C=1;B=1 D : 1 [West] A : 2 [West] C : 1 [North-East] B : 1 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (7) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B:∞ C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table A=1;B=2;C=2;D=1;E=1 Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 1 [East] A : 2 [West] C : 2 [East] D D EE C : 1 [North-East] B : 1 [North] B : 2 [East] CNPP/2008.4. © O. Bonaventure, 2007
  • How to update the routing table ? (7) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B:∞ C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table A=1;B=2;C=2;D=1;E=1 Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 1 [East] A : 2 [West] C : 2 [East] D D EE C : 1 [North-East] B : 1 [North] B : 2 [East]  Failure has been recovered, all routers are now reachable again from any router CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 1 [East] A : 2 [West] C : 2 [East] D D EE C : 1 [North-East] B : 1 [North] B : 2 [East] D detects the failure  If it is the first to send its distance vector, failure is detected and router A updates its routing table CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table A=1;B=∞;C=∞;D=1;E=∞ Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 1 [East] A : 2 [West] C : 2 [East] D D EE C : 1 [North-East] B : 1 [North] B : 2 [East] D detects the failure  If it is the first to send its distance vector, failure is detected and router A updates its routing table CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure (2) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table A=0;D=1;B=3;C=3;E=2 Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E:∞ A : 2 [West] C:∞ D D EE C : 1 [North-East] B : 1 [North] B:∞  But if A sends its distance vector before having received or processed Dʼs updated distance vector ... CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure (3)  Upon reception of Aʼs vector, D updates its routing table Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 3 [North] A : 2 [West] C : 4 [North] D D EE C : 1 [North-East] B : 1 [North] B : 4 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure (3)  Upon reception of Aʼs vector, D updates its routing table Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table D=0;A=1;E=3;C=4;B=4 Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 3 [North] A : 2 [West] C : 4 [North] D D EE C : 1 [North-East] B : 1 [North] B : 4 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure (4) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 5 [South] C : 1 [East] D : 2 [South-West] C : 5 [South] E : 1 [South] A: 3 [South-West] E : 4 [South] D : 2 [South] B : 1 [West] A B CC Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 3 [North] A : 2 [West] C : 4 [North] D D EE C : 1 [North-East] B : 1 [North] B : 4 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure (4) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 5 [South] C : 1 [East] D : 2 [South-West] C : 5 [South] E : 1 [South] A: 3 [South-West] E : 4 [South] D : 2 [South] B : 1 [West] A B CC Routing table A=0;D=1;B=5;C=5;E=4 Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 3 [North] A : 2 [West] C : 4 [North] D D EE C : 1 [North-East] B : 1 [North] B : 4 [North] CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure (5) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 5 [South] C : 1 [East] D : 2 [South-West] C : 5 [South] E : 1 [South] A: 3 [South-West] E : 4 [South] D : 2 [South] B : 1 [West] A B CC Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 5[North] A : 2 [West] C : 6 [North] D D EE C : 1 [North-East] B : 1 [North] B : 6 [North]  This problem is called counting to infinity  How can we avoid it ? CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure (5) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 5 [South] C : 1 [East] D : 2 [South-West] C : 5 [South] E : 1 [South] A: 3 [South-West] E : 4 [South] D : 2 [South] B : 1 [West] A B CC Routing table Routing table D : 0 [Local] A=1;D=0;B=6;C=6;E=5 E : 0 [Local] A : 1 [North] D : 1 [West] E : 5[North] A : 2 [West] C : 6 [North] D D EE C : 1 [North-East] B : 1 [North] B : 6 [North]  This problem is called counting to infinity  How can we avoid it ? CNPP/2008.4. © O. Bonaventure, 2007
  • Second link failure (6)  Where does counting to infinity comes form ?  A router announces on a link routes that it has already learned via this link  How to avoid counting to infinity ?  split horizon  each router creates a distance vector for each link  on link i, router does not announce the routers learned over link i Pseudocode Every N seconds: for each link=l { /* one different vector for each link */ Vector=null; for each destination=d in R[] { if (R[d].link<>l) { Vector=Vector+Pair(d,R[d].cost); } } Send(Vector); } CNPP/2008.4. © O. Bonaventure, 2007
  • Split horizon  Back to previous example Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 1 [East] A : 2 [West] C : 2 [East] D D EE C : 1 [North-East] B : 1 [North] B : 2 [East]  A will not pollute Dʼs routing table with split horizon CNPP/2008.4. © O. Bonaventure, 2007
  • Split horizon  Back to previous example Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table A=0 Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : 1 [East] A : 2 [West] C : 2 [East] D D EE C : 1 [North-East] B : 1 [North] B : 2 [East]  A will not pollute Dʼs routing table with split horizon CNPP/2008.4. © O. Bonaventure, 2007
  • Split horizon (2)  D can also send its distance vector Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] E:∞ C : 1 [East] D : 2 [South-West] C:∞ E : 1 [South] A: 3 [South-West] B:∞ D : 2 [South] B : 1 [West] A B CC Routing table D=0;B=∞;C=∞;E=∞ Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E:∞ A : 2 [West] C:∞ D D EE C : 1 [North-East] B : 1 [North] B:∞  Does split horizon allows to avoid all counting to infinity problems ? CNPP/2008.4. © O. Bonaventure, 2007
  • Split horizon with poisoning  Improvement  Instead of not advertising a route over the link from which it was learned, advertise it with an infinite cost Pseudocode Every N seconds: for each link=l { /* one different vector for each link */ Vector=null; for each destination=d in R[] { if (R[d].link<>l) { Vector=Vector+Pair(d,R[d].cost); } else { Vector=Vector+Pair(d,∞); } } Send(Vector); } CNPP/2008.4. © O. Bonaventure, 2007
  • Split horizon with poisoning (2)  Back to previous example Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : ∞∞ A : 2 [West] C : ∞∞ D D EE C : 1 [North-East] B : 1 [North] B : ∞∞ CNPP/2008.4. © O. Bonaventure, 2007
  • Split horizon with poisoning (2)  Back to previous example Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] D : 1 [South] A : 3 [South] E : 1 [South-West] B : 3 [South] C : 1 [East] D : 2 [South-West] C : 3 [South] E : 1 [South] A: 3 [South-West] E : 2 [South] D : 2 [South] B : 1 [West] A B CC Routing table A=0;D=∞; B=∞;C=∞;E=∞ Routing table D : 0 [Local] E : 0 [Local] A : 1 [North] D : 1 [West] E : ∞∞ A : 2 [West] C : ∞∞ D D EE C : 1 [North-East] B : 1 [North] B : ∞∞ CNPP/2008.4. © O. Bonaventure, 2007
  • Limitations to split horizon Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] B:∞∞ A : 1 [West] E : 1 [South-West] C:∞∞ C : 1 [East] A : 2 [West] E : 1 [South] B : 1 [West] E:∞∞ A B CC Routing table E : 0 [Local] A : 2 [North] C : 1 [North-East] B : 1 [North] EE CNPP/2008.4. © O. Bonaventure, 2007
  • Limitations to split horizon Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] B:∞∞ A : 1 [West] E : 1 [South-West] C:∞∞ C : 1 [East] A : 2 [West] E : 1 [South] B : 1 [West] E:∞∞ A=∞;B=0; C=1;E=∞ A B CC Routing table A=∞;B=0; C=1;E=∞ E : 0 [Local] A : 2 [North] C : 1 [North-East] B : 1 [North] EE CNPP/2008.4. © O. Bonaventure, 2007
  • Limitations to split horizon Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] B:∞∞ A : 1 [West] E : 1 [South-West] C:∞∞ C : 1 [East] A : 2 [West] E : 1 [South] B : 1 [West] E:∞∞ A=∞;B=0; C=1;E=∞ A B CC Routing table A=∞;B=0; C=1;E=∞ E : 0 [Local] A : 2 [North] A=2;B=1; C=0;E=∞ C : 1 [North-East] B : 1 [North] EE CNPP/2008.4. © O. Bonaventure, 2007
  • Limitations to split horizon (2) Routing table Routing table Routing table A : 0 [ Local ] B : 0 [Local] C : 0 [Local] B : ∞∞ A : 1 [West] E : 1 [South-West] C:∞∞ C : 1 [East] A : 2 [West] E : 1 [South] B : 1 [West] E:∞∞ A B CC Routing table after Bʼs vector A=∞;B=0; C=1;E=∞ E : 0 [Local] A=2;B=1; C=0;E=∞ A:∞ C : 1 [North-East] B : 1 [North] EE Routing table after Cʼs vector E : 0 [local]  E will send its own distance vector A : 3 [North-East]  B will discover a new route towards A via E C : 1 [North-East] and will advertise it to C B : 1 [North]  New count to infinity problem CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer  Basics  Routing  Static routing  Distance vector routing  Link state routing  IP : Internet Protocol  Routing in IP networks CNPP/2008.4. © O. Bonaventure, 2007
  • Link state routing  Idea  Instead of distributing summaries of routing tables, wouldnʼt it be better to distribute network map ?  How to build such as network map ?  Each router must discover its neighbours  It should be possible to associate a cost to each link since all links are not equal  Each router sends its local topology to all routes and assembles the information received from other routers  Routers build the network graph and used Dijkstraʼs algorithm to compute shortest paths CNPP/2008.4. © O. Bonaventure, 2007
  • Neighbour discovery  How does a router discover its neighbours ?  By manual configuration  Unreliable and difficult to manage  By using HELLO packets  Every N seconds, each router sends a HELLO packet on each link with its address  Neighbours replay by sending their own address  Periodic transmission allows to verify that the link remains up and detect failures A B CNPP/2008.4. EE © O. Bonaventure, 2007
  • Neighbour discovery  How does a router discover its neighbours ?  By manual configuration  Unreliable and difficult to manage  By using HELLO packets  Every N seconds, each router sends a HELLO packet on each link with its address  Neighbours replay by sending their own address  Periodic transmission allows to verify that the link remains up and detect failures A B B:HELLO CNPP/2008.4. EE © O. Bonaventure, 2007
  • Neighbour discovery  How does a router discover its neighbours ?  By manual configuration  Unreliable and difficult to manage  By using HELLO packets  Every N seconds, each router sends a HELLO packet on each link with its address  Neighbours replay by sending their own address  Periodic transmission allows to verify that the link remains up and detect failures A:HELLO A B B:HELLO E:HELLO CNPP/2008.4. EE © O. Bonaventure, 2007
  • How to determine link costs ?  Principle  one cost is associated with each link direction  Commonly configured link costs  Unit cost  simplest solution but only suitable for homogeneous networks  Cost depends on link bandwidth  high cost for low bandwidth links  low cost for high bandwidth links  Cost depends on link delays  often used to avoid satellite links  Cost based on measurements  Use HELLO to measure link rtt  allows to track link load, but be careful if the measurement is not stable enough as each delay change will cause a topology change ... CNPP/2008.4. © O. Bonaventure, 2007
  • Assembling the network topology  How to assemble the network topology  By receiving HELLOs, each routers builds its local part of the network map  Each router summarises its local topology inside one link state packet that contains  router identification  pairs (neighbour identification,cost to reach neighbour)  When should a router send its link state packet ?  in case of modification to its local topology  allows to inform all other routers of the change  Every N seconds  allows to refresh information in all routers and makes sure that if an invalid information was stored on a router due to memory errors it will not remain in the router forever CNPP/2008.4. © O. Bonaventure, 2007
  • How to distribute the link state packets ? CNPP/2008.4. © O. Bonaventure, 2007
  • How to distribute the link state packets ?  Naive solution  Each router sends one packet to each other router in the network  This solution can only work if  All routers know the address of all other routers in network  All routers already have routing tables that allow them to forward packets to any destination CNPP/2008.4. © O. Bonaventure, 2007
  • How to distribute the link state packets ?  Naive solution  Each router sends one packet to each other router in the network  This solution can only work if  All routers know the address of all other routers in network  All routers already have routing tables that allow them to forward packets to any destination  Realistic solution  Does not rely on pre-existing routing tables  Each router must receive entire topology  First solution  Each router sends local topology in link state packet and sends it to all its outgoing links  When a router receives an LSP, it forwards it to all its outgoing links except the link from which it received it CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding Links Links Links A-B : 1 A-B : 1 B-C : 1 B-E : 1 C-E : 1 A-D : 1 B-C : 1 A B CC Links A-D : 1 D-E : 1 D D EE Links E-D : 1 E-B : 1 E-C : 1  Assumes that all links have a unit cost CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding Links Links Links A-B : 1 A-B : 1 B-C : 1 B-E : 1 C-E : 1 A-D : 1 B-C : 1 A B CC LSP : E [D:1];[B:1];[C:1] LSP : E [D:1];[B:1];[C:1] Links A-D : 1 D-E : 1 D D EE Links E-D : 1 E-B : 1 E-C : 1 LSP : E [D:1];[B:1];[C:1]  Assumes that all links have a unit cost CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (2) Links Links B-C : 1 A-B : 1 C-E : 1 Links B-E : 1 A-B : 1 B-E : 1 B-C : 1 D-E : 1 A-D : 1 E-D : 1 E-C : 1 A B CC Links A-D : 1 D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1 CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (2) Links Links B-C : 1 A-B : 1 C-E : 1 Links B-E : 1 A-B : 1 B-E : 1 B-C : 1 D-E : 1 A-D : 1 E-D : 1 E-C : 1 A B CC LSP : E [D:1];[B:1];[C:1] Links A-D : 1 D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1 CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (2) Links Links B-C : 1 A-B : 1 C-E : 1 Links B-E : 1 A-B : 1 B-E : 1 B-C : 1 D-E : 1 A-D : 1 E-D : 1 E-C : 1 LSP : E [D:1];[B:1];[C:1] A B CC LSP : E [D:1];[B:1];[C:1] Links A-D : 1 D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1 CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (2) Links Links B-C : 1 A-B : 1 C-E : 1 Links B-E : 1 A-B : 1 B-E : 1 B-C : 1 D-E : 1 A-D : 1 E-D : 1 E-C : 1 LSP : E [D:1];[B:1];[C:1] A B CC LSP : E [D:1];[B:1];[C:1] Links A-D : 1 LSP : E [D:1];[B:1];[C:1] D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1 CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (2) Links Links B-C : 1 A-B : 1 C-E : 1 Links B-E : 1 A-B : 1 B-E : 1 B-C : 1 D-E : 1 A-D : 1 E-D : 1 E-C : 1 LSP : E [D:1];[B:1];[C:1] A B CC LSP : E [D:1];[B:1];[C:1] Links A-D : 1 LSP : E [D:1];[B:1];[C:1] D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1  How to ensure that an LSP will not loop ? CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (3)  How to avoid LSP flooding loops ?  A router should not reflood an LSP that it has already and flooded  Solution  LSP contents  sequence number  incremented every time an LSP is generated by a router  address of LSP originator  pairs address:distance for all neighbours of the originator  Each router must store the last LSP received from each router of the network  A received LSP is processed and flooded only if is it more recent than the LSP stored in the LSDB CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (4) Links A-B : 1 Links B-E : 1 B-C : 1 Links C-E : 1 A-B : 1 B-C : 1 A-D : 1 LSPs LSPs LSPs A B CC Links A-D : 1 D-E : 1 D D EE Links E-D : 1 E-B : 1 LSPs E-C : 1 LSPs E-0 [D:1];[B:1];[C:1] CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (4) Links A-B : 1 Links B-E : 1 B-C : 1 Links C-E : 1 A-B : 1 B-C : 1 A-D : 1 LSPs LSPs LSPs A B CC LSP : E-0 [D:1];[B:1];[C:1] LSP : E-0 [D:1];[B:1];[C:1] Links A-D : 1 D-E : 1 D D EE Links E-D : 1 LSP : E-0 [D:1];[B:1];[C:1] E-B : 1 LSPs E-C : 1 LSPs E-0 [D:1];[B:1];[C:1] CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (5) LSPs Links Links LSPs B-C : 1 E-0 [D:1];[B:1];[C:1] E-0 [D:1];[B:1];[C:1] Links A-B : 1 C-E : 1 A-B : 1 B-E : 1 B-E : 1 A-D : 1 B-C : 1 D-E : 1 E-D : 1 E-C : 1 LSPs A B CC Links A-D : 1 D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1 LSPs E-0 [D:1];[B:1];[C:1] LSPs E-0 [D:1];[B:1];[C:1]  Thanks to its LSP table  A can detect that it received same LSP via B and D  C can detect that it received same LSP via B and E CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (5) LSPs Links Links LSPs B-C : 1 E-0 [D:1];[B:1];[C:1] E-0 [D:1];[B:1];[C:1] Links A-B : 1 C-E : 1 A-B : 1 B-E : 1 B-E : 1 A-D : 1 B-C : 1 D-E : 1 E-D : 1 E-C : 1 LSPs A B CC LSP : E-0 [D:1];[B:1];[C:1] Links A-D : 1 D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1 LSPs E-0 [D:1];[B:1];[C:1] LSPs E-0 [D:1];[B:1];[C:1]  Thanks to its LSP table  A can detect that it received same LSP via B and D  C can detect that it received same LSP via B and E CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (5) LSPs Links Links LSPs B-C : 1 E-0 [D:1];[B:1];[C:1] E-0 [D:1];[B:1];[C:1] Links A-B : 1 C-E : 1 A-B : 1 B-E : 1 B-E : 1 A-D : 1 B-C : 1 D-E : 1 E-D : 1 E-C : 1 LSP : E-0 [D:1];[B:1];[C:1] LSPs A B CC LSP : E-0 [D:1];[B:1];[C:1] Links A-D : 1 D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1 LSPs E-0 [D:1];[B:1];[C:1] LSPs E-0 [D:1];[B:1];[C:1]  Thanks to its LSP table  A can detect that it received same LSP via B and D  C can detect that it received same LSP via B and E CNPP/2008.4. © O. Bonaventure, 2007
  • LSP flooding (5) LSPs Links Links LSPs B-C : 1 E-0 [D:1];[B:1];[C:1] E-0 [D:1];[B:1];[C:1] Links A-B : 1 C-E : 1 A-B : 1 B-E : 1 B-E : 1 A-D : 1 B-C : 1 D-E : 1 E-D : 1 E-C : 1 LSP : E-0 [D:1];[B:1];[C:1] LSPs A B CC LSP : E-0 [D:1];[B:1];[C:1] Links A-D : 1 LSP : E-0 [D:1];[B:1];[C:1] D-E : 1 Links B-E : 1 E-C : 1 D D EE E-D : 1 E-B : 1 E-C : 1 LSPs E-0 [D:1];[B:1];[C:1] LSPs E-0 [D:1];[B:1];[C:1]  Thanks to its LSP table  A can detect that it received same LSP via B and D  C can detect that it received same LSP via B and E CNPP/2008.4. © O. Bonaventure, 2007
  • Full topology Links LSPs Links LSPs A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] B-E, E-B : 1 Links LSPs B-E, E-B : 1 A-0 [D:1];[B:1] A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] A-0 [D:1];[B:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] E-D, D-E : 1 B-E, E-B : 1 A-0 [D:1];[B:1] E-D, D-E : 1 C-0 [B:1] [E:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] C-0 [B:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1 E-D, D-E : 1 C-0 [B:1] [E:1] A-D, D-A : 1 E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1 LSPs A B CC E-0 [D:1];[B:1];[C:1] A-0 [D:1];[B:1] B-0 [A:1] [C:1] [E:1] C-0 [B:1] [E:1] D-0 [A:1] [E:1] Links D D EE A-B, B-A : 1 B-E, E-B : 1 Links B-C, C-B : 1 LSPs A-B, B-A : 1 E-D, D-E : 1 E-0 [D:1];[B:1];[C:1] B-E, E-B : 1 E-C, C-E : 1 A-0 [D:1];[B:1] B-C, C-B : 1 A-D, D-A : 1 B-0 [A:1] [C:1] [E:1] E-D, D-E : 1 C-0 [B:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1 CNPP/2008.4. © O. Bonaventure, 2007
  • How to deal with link failures ? Links LSPs Links LSPs A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] B-E, E-B : 1 Links LSPs B-E, E-B : 1 A-0 [D:1];[B:1] A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] A-0 [D:1];[B:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] E-D, D-E : 1 B-E, E-B : 1 A-0 [D:1];[B:1] E-D, D-E : 1 C-0 [B:1] [E:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] C-0 [B:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1 E-D, D-E : 1 C-0 [B:1] [E:1] A-D, D-A : 1 E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1 LSPs A B CC E-0 [D:1];[B:1];[C:1] A-0 [D:1];[B:1] B-0 [A:1] [C:1] [E:1] C-0 [B:1] [E:1] D-0 [A:1] [E:1] Links D D EE A-B, B-A : 1 B-E, E-B : 1 Links B-C, C-B : 1 LSPs A-B, B-A : 1 E-D, D-E : 1 E-1 [D:1];[C:1] B-E, E-B : 1 E-C, C-E : 1 A-0 [D:1];[B:1] B-C, C-B : 1 A-D, D-A : 1 B-0 [A:1] [C:1] [E:1] E-D, D-E : 1 C-0 [B:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1  Two-way connectivity check  A link is only considered useable if both directions have CNPP/2008.4. been advertised © O. Bonaventure, 2007
  • How to deal with link failures ? Links LSPs Links LSPs A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] B-E, E-B : 1 Links LSPs B-E, E-B : 1 A-0 [D:1];[B:1] A-B, B-A : 1 E-0 [D:1];[B:1];[C:1] A-0 [D:1];[B:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] E-D, D-E : 1 B-E, E-B : 1 A-0 [D:1];[B:1] E-D, D-E : 1 C-0 [B:1] [E:1] B-C, C-B : 1 B-0 [A:1] [C:1] [E:1] C-0 [B:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1 E-D, D-E : 1 C-0 [B:1] [E:1] A-D, D-A : 1 E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1 LSPs A B CC E-0 [D:1];[B:1];[C:1] A-0 [D:1];[B:1] B-0 [A:1] [C:1] [E:1] C-0 [B:1] [E:1] D-0 [A:1] [E:1] LSP : E-1 [D:1];[C:1] Links D D EE A-B, B-A : 1 LSP : E-1 [D:1];[C:1] B-E, E-B : 1 Links B-C, C-B : 1 LSPs A-B, B-A : 1 E-D, D-E : 1 E-1 [D:1];[C:1] B-E, E-B : 1 E-C, C-E : 1 A-0 [D:1];[B:1] B-C, C-B : 1 A-D, D-A : 1 B-0 [A:1] [C:1] [E:1] E-D, D-E : 1 C-0 [B:1] [E:1] E-C, C-E : 1 D-0 [A:1] [E:1] A-D, D-A : 1  Two-way connectivity check  A link is only considered useable if both directions have CNPP/2008.4. been advertised © O. Bonaventure, 2007
  • Router failures CNPP/2008.4. © O. Bonaventure, 2007
  • Router failures  What happens if a router fails ?  All its interfaces become unusable and do not reply anymore to HELLO packets CNPP/2008.4. © O. Bonaventure, 2007
  • Router failures  What happens if a router fails ?  All its interfaces become unusable and do not reply anymore to HELLO packets  What happens when the router reboots ?  It will send its LSP with its sequence number set to zero  If older LSPs from same router were still in network, then the new LSP will not be flooded CNPP/2008.4. © O. Bonaventure, 2007
  • Router failures  What happens if a router fails ?  All its interfaces become unusable and do not reply anymore to HELLO packets  What happens when the router reboots ?  It will send its LSP with its sequence number set to zero  If older LSPs from same router were still in network, then the new LSP will not be flooded  Solution  Add "age" field inside each LSP  Each router must decrement age regularly  even for the LSPs stored in its LSDB  LSP having age=0 is too old and must be deleted  Each router must flood regularly its own LSP with age>0 to ensure that it remains inside network CNPP/2008.4. © O. Bonaventure, 2007
  • Improvements to LSP flooding  Avoid sending twice same LSP on a link  When an LSP needs to be flooded on a link, wait some time to let other router flood the LSP  reduces number of LSPs exchanged on a link but  increases flooding time  Reliable flooding  CRC inside each LSP to detect transmission errors  Acknowledgements on each link for the LSPs exchanged on this link  each transmission is protected by a timer  Link state database exchange/synchronisation  Routers can compare the content of their LSDB and exchange only missing LSPs form neighbour  useful when the router boots and wants to receive quickly CNPP/2008.4. all LSPs from the network © O. Bonaventure, 2007
  • Computation of routing table  Principle  Each router uses the received LSPs to build a graph and then computes the shortest spanning tree rooted on itself  From this spanning tree, it is easy to compute the routing table D=2 D=3 R2 R5 D=10 D=3 D=3 R6 R1 D=1 D=6 D=5 R3 R4 Routing table R1 : West R2 : North R4 : East R5 : East R6 : East CNPP/2008.4. © O. Bonaventure, 2007
  • Dijkstraʼs shortest path  Computing the shortest path tree  At the beginning, the tree only contains the root node  Adjacent routers are placed with the cost of their link in the candidates list  Candidate router with lowest cost is chosen and added to the tree  Consider the neighbours of the chosen candidate router and update the candidate router list if  one of the new neighbours was not already in the candidates list  one of the new neighbours was already in the candidates list but with a longer path than the one in the current list  Algorithm continues with the new candidates list and ends when all routers belong to shortest path tree CNPP/2008.4. © O. Bonaventure, 2007
  • Dijkstraʼs shortest path (2) D=2 D=3 R2 R5 D=10 D=3 D=3 R6 R1 D=1 D=6 D=5 R3 R4 1) Routers : [R1, R2, R4, R5,R6] ; Candidates : [ - ] ; Tree : R3 2) Routers : [R5, R6] ; Candidates : [R1(5) ; R2(3) ; R4 (1) ] selected candidate : R4 New tree : R3 - R4 New Candidates ? [R1(5) ; R2 (3) ; R5(R4-4) ; R6(R4-7) ] 3) Routers [ - ] Selected candidate : R2 ; New tree : R2 - R3 - R4 New Candidates ? [R1(5) ; R5(R4-4) ; R6 (R4-7) ] 4) Selected candidate : R5 ; New tree : R2 - R3 - R4 - R5 New candidates ? [R1(5) ; R6(R4-7) ] 5) ... CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer  Basics  Routing  Static routing  Distance vector routing  Link state routing  IP : Internet Protocol  IP version 4  IP version 6  Routing in IP networks CNPP/2008.4. © O. Bonaventure, 2007
  • IP : Internet Protocol Network layer IP LLC Datalink layer Eth. PPP HDLC 802.3 802.5 FDDI Physical layer  Internet network layer  provides unreliable connectionless service  some packets can be lost  packets can suffer from transmission errors  packets can be misordered CNPP/2008.4. IPv4 is defined in RFC791 © O. Bonaventure, 2007
  • Basic principles  Datagram mode C A PPP E R1 FDDI R2 Ethernet B D  Each host is identified by one IP address (encoded as 32 bits number)  Each host knows how to reach at least one router  Routers know how to reach other routers CNPP/2008.4. © O. Bonaventure, 2007
  • Basic principles (2) Ethernet Ethernet A B PPP C R IP IP IP IP IP IP Eth Eth PPP PPP Eth Eth  Endhost  equipment able to send and receive packets originated by or destined to it  Router  equipment able to send and receive packets originated by or destined to it  equipment able to forward toward theirs destination packets that it did not originate CNPP/2008.4. © O. Bonaventure, 2007
  • IP Addressing CNPP/2008.4. © O. Bonaventure, 2007
  • IP Addressing  Utilisation of IP address  identify a host/router that implements IP  usually, one IP address identifies one (physical) interface on one endhost or router  (physical) interface is access point to datalink layer  usually endhosts have a single interface  routers have more than one interface  Encoding of 32 bits IP address  10001010 00110000 00011010 00000001  138 . 48 . 26 . 1 CNPP/2008.4. © O. Bonaventure, 2007
  • IP Addressing  Utilisation of IP address  identify a host/router that implements IP  usually, one IP address identifies one (physical) interface on one endhost or router  (physical) interface is access point to datalink layer  usually endhosts have a single interface  routers have more than one interface  Encoding of 32 bits IP address  10001010 00110000 00011010 00000001  138 . 48 . 26 . 1  How to allocate IP addresses to hosts in a campus network  Naive solution  First come first served CNPP/2008.4. © O. Bonaventure, 2007
  • Naive IP addressing A C E PPP: 10.0.0.1 FDDI : 10.0.0.4 Ethernet : 10.0.0.7 Routes Routes Routes 10.0.0.2 : PPP 10.0.0.1 : via 10.0.0.3 10.0.0.1 : via 10.0.0.6 10.0.0.3 : via 10.0.0.2 10.0.0.2 : via 10.0.0.3 10.0.0.2 : via 10.0.0.6 10.0.0.4 : via 10.0.0.2 10.0.0.3 : FDDI 10.0.0.3 : via 10.0.0.6 10.0.0.5 : via 10.0.0.2 10.0.0.5 : FDDI 10.0.0.4 : via 10.0.0.6 10.0.0.6 : via 10.0.0.2 10.0.0.6 : via 10.0.0.5 10.0.0.5 : Ethernet 10.0.0.7 : via 10.0.0.2 10.0.0.7 : via 10.0.0.5 10.0.0.6 : via 10.0.0.6 C A E R1 FDDI R2 Ethernet R1 PPP : 10.0.0.2 FDDI : 10.0.0.3 R2 Routes FDDI : 10.0.0.5 10.0.0.1 : PPP Ethernet : 10.0.0.6 10.0.0.4 : FDDI Routes 10.0.0.5 : FDDI 10.0.0.1 : via 10.0.0.3 10.0.0.6 : via 10.0.0.5 10.0.0.2 : via 10.0.0.3 10.0.0.7 : via 10.0.0.5 10.0.0.3 : FDDI 10.0.0.4 : FDDI 10.0.0.7 : Ethernet CNPP/2008.4. © O. Bonaventure, 2007
  • Hierarchical allocation of IP addresses  Allocation of IP addresses  one address per interface  each address composed of two parts 1. subnetwork identifier  M high order bits of IP address 2. equipment identifier inside the subnetworks  32-M bits low order bits of IP address Example 10001010 00110000 00011010 00000001 subnetwork id host id Notation 138.48.26.1/23 or 138.48.26.1 255.255.254.0  All hosts that belong to the same subnetwork can directly exchange frames through datalink layer CNPP/2008.4. © O. Bonaventure, 2007
  • IP addressing : examples A C PPP: 10.0.0.1/30 FDDI : 11.0.0.10/22 E Routes Routes Ethernet : 12.0.0.10/24 11.0.0.0/22 : via 10.0.0.2 10.0.0.0/30 : via 11.0.0.1 Routes 12.0.0.0/24 : via 10.0.0.2 12.0.0.0/24 : via 11.0.0.2 10.0.0.0/30 : via 12.0.0.1 11.0.0.0/22 : via 12.0.0.1 PPP C A 10.0.0.0/30 E R1 FDDI 11.0.0.0/22 R2 Ethernet 12.0.0.0/24 R1 PPP : 10.0.0.2/30 B FDDI : 11.0.0.1/22 R2 FDDI : 11.0.0.2/22 D Routes 12.0.0.0/24 : via 11.0.0.2 Ethernet : 12.0.0.1/24 Routes 10.0.0.0/30 : via 11.0.0.1/22  Drawbacks of subnetworks  most subnetworks are not fully occupied  a campus network will need more IP addresses than the number of hosts attached to the network CNPP/2008.4. © O. Bonaventure, 2007
  • IP addresses CNPP/2008.4. © O. Bonaventure, 2007
  • IP addresses  Most addresses are allocated by IANA  and the regional registries RIPE, ARIN, ... CNPP/2008.4. © O. Bonaventure, 2007
  • IP addresses  Most addresses are allocated by IANA  and the regional registries RIPE, ARIN, ...  But some addresses play a special role  127.0.0.1  Loopback address on each host  Allows to reach servers on the local host  10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16  used for private networks (not directly attached to Internet)  218.0.0.0/8 - 223.0.0.0/8 and 240.0.0.0/8 - 255.0.0.0/8  reserved for further utilization  224.0.0.0/8 - 239.0.0.0/8  used by IP multicast  255.255.255.255  broadcast address  0.0.0.0  used when a host is booting and does not yet know its address CNPP/2008.4. © O. Bonaventure, 2007
  • IP Packets  IP packet format 32 bits Total length of IP header encoded Total Length as 16 bits integer Maximum length : 64 KBytes Header : 20 bytes Source Address Destination Address Optional header extension Payload [0 to 65515 bytes]  How can we transmit a 64 KBytes packet ? CNPP/2008.4. © O. Bonaventure, 2007
  • Transmission of long IP packets  Principe  Each host and each router can fragment packets  Each fragment is a complete IP packet that contains source and destination IP addresses  Only the destination host performs reassembly Long packet Source IP address Destination IP address Source IP address Payload [part 1] Destination IP address Payload Source IP address Destination IP address Payload [part 2] CNPP/2008.4. © O. Bonaventure, 2007
  • Transmission of long IP packets (2) Ethernet 11.0.0/24 Max: 1500 bytes FDDI Token 12.0.0.0/24 Ring R2 Max: 4478 bytes 10.0.0.0/24 R1 >4Kbytes CNPP/2008.4. © O. Bonaventure, 2007
  • Transmission of long IP packets (2) Ethernet 11.0.0/24 Max: 1500 bytes FDDI Token 12.0.0.0/24 Ring R2 Max: 4478 bytes 10.0.0.0/24 R1 >4Kbytes 2000 bytes Source sends one 2000 bytes packet inside one frame CNPP/2008.4. © O. Bonaventure, 2007
  • Transmission of long IP packets (2) Ethernet 11.0.0/24 Max: 1500 bytes FDDI Token 12.0.0.0/24 Ring R2 Max: 4478 bytes 10.0.0.0/24 R1 >4Kbytes 2000 bytes 1480 bytes 520 bytes R1 fragments the received packet and creates two packets Source sends one 2000 bytes packet inside one frame CNPP/2008.4. © O. Bonaventure, 2007
  • Transmission of long IP packets (2) Ethernet 11.0.0/24 Max: 1500 bytes FDDI Token 12.0.0.0/24 Ring R2 Max: 4478 bytes 10.0.0.0/24 R1 >4Kbytes 1480 bytes 1480 bytes 2000 bytes 520 bytes 520 bytes R2 forwards the R1 fragments the two fragments received packet and independently creates two packets Source sends one 2000 bytes packet inside one frame CNPP/2008.4. © O. Bonaventure, 2007
  • Transmission of long IP packets (2) Ethernet 11.0.0/24 Max: 1500 bytes FDDI Token 12.0.0.0/24 Ring R2 Max: 4478 bytes 10.0.0.0/24 R1 >4Kbytes 1480 bytes 1480 bytes 2000 bytes 520 bytes 520 bytes R2 forwards the R1 fragments the two fragments received packet and independently Destination reassembles creates two packets the two received fragments to Source sends one recover the original 2000 bytes 2000 bytes packet packet inside one frame CNPP/2008.4. © O. Bonaventure, 2007
  • How to deal with limited MTU links ?  IP fragmentation  Fragment the payload of IP packet  Each fragment must be number to recover from misordering 32 bits Total length M FragmentOffset 20 bytes Source IP address Destination IP address Payload CNPP/2008.4. © O. Bonaventure, 2007
  • How to deal with limited MTU links ?  IP fragmentation  Fragment the payload of IP packet  Each fragment must be number to recover from misordering This is the length of the fragment 32 bits Total length M FragmentOffset 20 bytes Source IP address Destination IP address Payload CNPP/2008.4. © O. Bonaventure, 2007
  • How to deal with limited MTU links ?  IP fragmentation  Fragment the payload of IP packet  Each fragment must be number to recover from misordering This is the length of the fragment 32 bits Total length Offset (position) of the first byte of the payload of this fragment in the payload of the M FragmentOffset original IP packet. 20 bytes Source IP address Destination IP address Payload CNPP/2008.4. © O. Bonaventure, 2007
  • How to deal with limited MTU links ?  IP fragmentation  Fragment the payload of IP packet  Each fragment must be number to recover from misordering This is the length of the fragment 32 bits Total length Offset (position) of the first byte of the payload of this fragment in the payload of the M FragmentOffset original IP packet. 20 bytes Source IP address Destination IP address More Bit =1 if all fragments besides last one =0 in the last fragment of an IP Payload packet CNPP/2008.4. © O. Bonaventure, 2007
  • Fragmentation : example Ethernet 11.0.0/24 Max: 1500 bytes 2000 bytes R1 Length : 2020 M=0 Offset=0 Source : 10.0.0.10 Destination : 12.0.0.22 Contents CNPP/2008.4. © O. Bonaventure, 2007
  • Fragmentation : example Ethernet 11.0.0/24 Max: 1500 bytes 2000 bytes 1480 bytes R1 520 bytes F Length : 1500 r a M=1 Offset=0 g m Source : 10.0.0.10 e Destination : 12.0.0.22 Length : 2020 n M=0 Offset=0 t Contents [part 1] 1 Source : 10.0.0.10 Destination : 12.0.0.22 F Length : 540 r Contents a M=0 Offset=1480 g m Source : 10.0.0.10 e Destination : 12.0.0.22 n t 2 Contents [part 2] CNPP/2008.4. © O. Bonaventure, 2007
  • Reassembly  Issues  When does the destination has received all fragments ?  Last fragment contains bit More=0  How to handle lost fragments ?  the IP packet will not be reassembled by destination and received fragments of this packet will be discarded  How to deal with misordering  Offset field allows to reorder fragments from same packet  But misordering can cause fragments from multiple packets to be mixed  Each fragment must contain an identification of the original packet from which is was created CNPP/2008.4. © O. Bonaventure, 2007
  • Packets and fragments identification Ethernet 11.0.0/24 Max: 1500 bytes 2000 bytes 1480 bytes R1 520 bytes Packet identification is chosen by the sender to ensure that two packets sent by F Length : 1500 the same host do not use the same r a Identification: 1234 M=1 Offset=0 identification within a short period of time. g m Source : 10.0.0.10 e Destination : 12.0.0.22 Length : 2020 n Identification: 1234 M=0 Offset=0 t Content [part 1] 1 Source : 10.0.0.10 Destination : 12.0.0.22 F Length : 540 r Content a Identification: 1234 M=0 Offset=1480 g m Source : 10.0.0.10 e Destination : 12.0.0.22 n t 2 Content [part 2] CNPP/2008.4. © O. Bonaventure, 2007
  • How to avoid fragmentation ?  Problem  How can a host determine the maximum packet size that he can use to reach a destination ? Solution  Instead of performing fragmentation, the router could indicate the maximum packet size that it supports Ethernet Token 11.0.0/24 Ring Max: 1500 bytes FDDI 10.0.0.0/24 12.0.0.0/24 >4Kbytes R2 Max: 4478 bytes R1 2000 bytes Size Max: 1500 bytes  Knowing this maximum packet size, the endhost can send correctly sized packets CNPP/2008.4. © O. Bonaventure, 2007
  • Transmission errors  How should IP react to transmission errors ?  Transmission error inside packet content  some applications may continue to work despite this error  IP : no detection of transmission errors in packet payload  Transmission error inside packet header  could cause more problems  imagine that the transmission error changes the source or destination IP address  IP uses a checksum to detect transmission errors in header  16 bits checksum (same as TCP/UDP) computed only on header  each router and each end host verifies the chacksum of all packets that it receives. A packet with an errored header is immediately discarded CNPP/2008.4. © O. Bonaventure, 2007
  • Transient and permanent loops CNPP/2008.4. © O. Bonaventure, 2007
  • Transient and permanent loops  Problem  Loops can occur in an IP network  permanent loops due to configuration errors  transient loops while routing tables are being updated CNPP/2008.4. © O. Bonaventure, 2007
  • Transient and permanent loops  Problem  Loops can occur in an IP network  permanent loops due to configuration errors  transient loops while routing tables are being updated  Solution  Each packet contains a Time-to-Live (TTL) that indicates the maximum number of intermediate routers that the packet can cross  many hosts set the initial TTL of their packets to 32 or 64  each router checks the TTL of all packets  If TTL=1, packet is discarded and source is notified  If TTL>1, packet is forwarded and TTL is decremented by at least 1  routers thus must recompute checksum of all forwarded packets  Utilisation of TTL is a means to bound the lifetime of packets inside the Internet CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format 32 bits Ver IHL DS Total length Identification Flags FragmentOffset TTL Protocol Checksum 20 bytes Source IP address Destination IP address Options Payload CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format IP version used to encode header - current version is 4 - IP version 6 is being deployed 32 bits Ver IHL DS Total length Identification Flags FragmentOffset TTL Protocol Checksum 20 bytes Source IP address Destination IP address Options Payload CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format Header length (default 20 bytes) IP version used to encode header Maximum : 64 bytes for entire header - current version is 4 including options - IP version 6 is being deployed 32 bits Ver IHL DS Total length Identification Flags FragmentOffset TTL Protocol Checksum 20 bytes Source IP address Destination IP address Options Payload CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format Header length (default 20 bytes) IP version used to encode header Maximum : 64 bytes for entire header Differentiated Services Byte used to - current version is 4 including options specify Quality of Service expected - IP version 6 is being deployed for this packet 32 bits Ver IHL DS Total length Identification Flags FragmentOffset TTL Protocol Checksum 20 bytes Source IP address Destination IP address Options Payload CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format Header length (default 20 bytes) IP version used to encode header Maximum : 64 bytes for entire header Differentiated Services Byte used to - current version is 4 including options specify Quality of Service expected - IP version 6 is being deployed for this packet 32 bits Packet identification Ver IHL DS Total length used for fragmentation and reassembly Identification Flags FragmentOffset TTL Protocol Checksum 20 bytes Source IP address Destination IP address Options Payload CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format Header length (default 20 bytes) IP version used to encode header Maximum : 64 bytes for entire header Differentiated Services Byte used to - current version is 4 including options specify Quality of Service expected - IP version 6 is being deployed for this packet 32 bits Packet identification Ver IHL DS Total length used for fragmentation and reassembly Identification Flags FragmentOffset TTL Protocol Checksum 20 bytes Binary flags Source IP address More Destination IP address Don't Fragment : Packet cannot be fragmented by Options intermediate routers Payload CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format Header length (default 20 bytes) IP version used to encode header Maximum : 64 bytes for entire header Differentiated Services Byte used to - current version is 4 including options specify Quality of Service expected - IP version 6 is being deployed for this packet 32 bits Packet identification Ver IHL DS Total length used for fragmentation and reassembly Identification Flags FragmentOffset TTL Protocol Checksum Time to Live 20 bytes Source IP address Binary flags More Destination IP address Don't Fragment : Packet cannot be fragmented by Options intermediate routers Payload CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format Header length (default 20 bytes) IP version used to encode header Maximum : 64 bytes for entire header Differentiated Services Byte used to - current version is 4 including options specify Quality of Service expected - IP version 6 is being deployed for this packet 32 bits Packet identification Ver IHL DS Total length used for fragmentation and reassembly Identification Flags FragmentOffset TTL Protocol Checksum Time to Live 20 bytes Source IP address Binary flags More Destination IP address Don't Fragment : Packet cannot be fragmented by Options intermediate routers Allows to identify the “user” above the IP layer (e.g. UDP, TPC, ...) Plays similar role to TCP port Payload numbers CNPP/2008.4. © O. Bonaventure, 2007
  • IP header format Header length (default 20 bytes) IP version used to encode header Maximum : 64 bytes for entire header Differentiated Services Byte used to - current version is 4 including options specify Quality of Service expected - IP version 6 is being deployed for this packet 32 bits Packet identification Ver IHL DS Total length used for fragmentation and reassembly Identification Flags FragmentOffset TTL Protocol Checksum Time to Live 20 bytes Source IP address Binary flags More Destination IP address Don't Fragment : Packet cannot be fragmented by Options intermediate routers Allows to identify the “user” above the IP layer (e.g. UDP, TPC, ...) Plays similar role to TCP port Payload numbers Optional header extension CNPP/2008.4. © O. Bonaventure, 2007
  • IP Options  Sample IP header options  Strict source route option  allows the source to list IP addresses of all intermediate routers to reach destination between source and destination  Loose source route option  allows the source to list IP addresses of some intermediate routers to reach destination between source and destination  Record route option  allows each router to insert its IP address in the header  rarely used because limited header length  Router alert  allows the source to indicate to routers that there is something special to be done when processing this packet Constraint : maximum header size with option 64 bytes CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Strict source routing RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Destination : D Strict Path : RA,RB,RD source routing RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Source : S Destination : D Destination : D Strict Path : RA,RB,RD Path : RA,RB,RD source routing RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Source : S Source : S Destination : D Destination : D Strict Destination : D Path : RA,RB,RD Path : RA,RB,RD Path : RA,RB,RD source routing RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Source : S Source : S Destination : D Destination : D Strict Destination : D Path : RA,RB,RD Path : RA,RB,RD Path : RA,RB,RD source routing Source : S Destination : D Path : RA,RB,RD RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Source : S Source : S Destination : D Destination : D Strict Destination : D Path : RA,RB,RD Path : RA,RB,RD Path : RA,RB,RD source routing Source : S Destination : D Path : RA,RB,RD RB S RA D RC RD Loose source routing RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Source : S Source : S Destination : D Destination : D Strict Destination : D Path : RA,RB,RD Path : RA,RB,RD Path : RA,RB,RD source routing Source : S Destination : D Path : RA,RB,RD RB S RA D RC RD Source : S Destination : D Path : RB Loose source routing RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Source : S Source : S Destination : D Destination : D Strict Destination : D Path : RA,RB,RD Path : RA,RB,RD Path : RA,RB,RD source routing Source : S Destination : D Path : RA,RB,RD RB S RA D RC RD Source : S Source : S Destination : D Path : RB Destination : D Path : RB Loose source routing RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Source : S Source : S Destination : D Destination : D Strict Destination : D Path : RA,RB,RD Path : RA,RB,RD Path : RA,RB,RD source routing Source : S Destination : D Path : RA,RB,RD RB S RA D RC RD Source : S Source : S Destination : D Path : RB Destination : D Path : RB Loose Source : S Destination : D source routing Path : RB RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • IP Source Routing Source : S Source : S Source : S Destination : D Destination : D Strict Destination : D Path : RA,RB,RD Path : RA,RB,RD Path : RA,RB,RD source routing Source : S Destination : D Path : RA,RB,RD RB S RA D RC RD Source : S Source : S Destination : D Path : RB Destination : D Path : RB Loose Source : S Destination : D source routing Path : RB Source : S Destination : D Path : RB RB S RA D RC RD CNPP/2008.4. © O. Bonaventure, 2007
  • Operation of an IP endhost  Required information on an IP endhost  IP addresses of its interfaces  For each address, the subnet mask allows the endhost to determine the addresses that are directly reachable through the interface  (small) routing table  Directly connected subnets  From the subnet mask of its own IP addresses  Default router  Router used to reach any unknown address  By convention, default route is 0.0.0.0/0  Other subnets known by endhost  Could be manually configured or learned through routing protocols are special packets (see later) CNPP/2008.4. © O. Bonaventure, 2007
  • IP address configuration  How does a host know its IP address  Manual configuration  Used in many small networks  Server-based autoconfiguration RARP  DHCP  Dynamic Host Configuration Protocol  Principle  When it attaches to a subnet, endhost broadcasts a request to find DHCP server  DHCP server replies and endhost can contact it to obtain IP address  DHCP server allocates an IP address for some time period and can also provide additional information (subnet, default router, DNS resolver, ...)  DHCP servers can be configured to always provide the same IP address to a given endhost or not  Endhost reconfirms its allocation regularly  Serverless autoconfiguration  CNPP/2008.4. Used by IPv6 © O. Bonaventure, 2007
  • Operation of an IP router  Required information on an IP router  IP addresses of its interfaces  For each address, the subnet mask allows the endhost to determine the addresses that are directly reachable through the interface  Routing table  Directly connected subnets  From the subnet mask of its own IP addresses  Other known subnets  Usually learned via routing protocols, sometimes manually configured  Default router  Router used to reach any unknown address  By convention, default route is 0.0.0.0/0 CNPP/2008.4. © O. Bonaventure, 2007
  • Operation of an IP router (2)  Operations performed for each packet 1. Check whether the packetʼs destination address is one of the routerʼs addresses  If yes, packet reached destination 2. Query Forwarding Information Base that contains  list of directly connected networks with masks  list of reachable networks and intermediate router 3. Lookup the most specific route in FIB  For each route A.B.C.D/M via Rx  compare M higher order bits of destination address with M higher order bits of routes to find longest match  forward packet along this route CNPP/2008.4. © O. Bonaventure, 2007
  • Forwarding Information Base Lookup  How to find most specific route ?  similar to longest prefix match in a text  Trie Subnet Prefix ext-hop N 138.48.0.0 16 A {}* F 139.165.0.0 16 B 139.165.16.0 24 C 138.48 139.165 138.48.232.0 24 E 138.48.32.200 32 G A B 0.0.0.0 0 F (138.48.*) (139.165.*) 232 16 32 Null E C Cost of lookup (138.48.232.*) (139.165.16*) f(average length of prefixes) 200  comparisons G  memory accesses (138.48.33.200) caches for most frequently used routes CNPP/2008.4. © O. Bonaventure, 2007
  • Example Internet 12.0.0.0/8 138.48.1.2 138.48.1.1 Local addresses 11.0.0.1 ; 138.48.0.1 ; 192.168.1.1 ; 10.0.0.1 138.48.0.1 Routing table 192.168.1.1 138.48.0.0/16 |North] 11.0.0.1 R 11.0.0.0/8 [West] 10.0.0.1 192.168.1.0/24 [East] 11.0.1.1 10.0.0.0/8 [South] 4.0.0.0/8 via 11.0.1.1 [West] 4.10.11.0/24 via 10.0.1.1 [South] 10.0.1.1 12.0.0.0/8 via 138.48.1.2 [North] 0.0.0.0/0 via 138.48.1.1 [North] 4.0.0.0/8 4.10.11.0/ 24 CNPP/2008.4. © O. Bonaventure, 2007
  • Handling IP packets in error  Problem  What should a router/host do when it receives an errored packet  Example  Packet whose destination is not the current endhost  Packet containing a header with invalid syntax  Packet received with TTL=1  Packet destined to protocol not supported by host  Solutions  Ignore and discard the errored packet  Send a message to the packetʼs source to warn it about the problem  ICMP : Internet Control Message Protocol  ICMP messages are sent inside IP packets by routers (mainly) and hosts  To avoid performance problems, most hosts/routers limit the amount of ICMP messages that they send CNPP/2008.4. ICMP is defined in RFC792 © O. Bonaventure, 2007
  • Sample ICMP messages  Routing error  Destination unreachable  Final destination of packet cannot be reached  Network unreachable for entire subnet  Host unreachable for an individual host  Protocol/Port unreachable for protocol/port on a reachable host  Redirect  The packet was sent to an incorrect first-hop router and should have been instead sent to another first-hop router  Error in the IP header  Parameter Problem  Incorrect format of IP packet  TTL Exceeded  Router received packet with TTL=1  Fragmentation  the packet should have been fragmented, but its DF flag was true CNPP/2008.4. © O. Bonaventure, 2007
  • ICMP messages 32 bits Ver IHL DS Total length Identification Flags FragmentOffset IP header TTL Protocol Checksum Source IP address Destination IP address Type Code Checksum ICMP header Data Ver IHL DS Total length Identification Flags FragmentOffset TTL Protocol Checksum Copy of the beginning of Source IP address the IP header that caused the error Destination IP address First 64 bits of payload CNPP/2008.4. © O. Bonaventure, 2007
  • ICMP messages 32 bits Protocol=1 for ICMP Ver IHL DS Total length Identification Flags FragmentOffset IP header TTL Protocol Checksum Source IP address Destination IP address Type Code Checksum ICMP header Data Ver IHL DS Total length Identification Flags FragmentOffset TTL Protocol Checksum Copy of the beginning of Source IP address the IP header that caused the error Destination IP address First 64 bits of payload CNPP/2008.4. © O. Bonaventure, 2007
  • ICMP messages 32 bits Protocol=1 for ICMP Ver IHL DS Total length Identification Flags FragmentOffset IP header TTL Protocol Checksum Source IP address Destination IP address Type Code Checksum ICMP header Type and Code indicate the type of Data error detected  Destination unreachable Ver IHL DS Total length  network unreachable  host unreachable Identification Flags FragmentOffset  protocol unreachable  port unreachable TTL Protocol Checksum  fragmentation needed Copy of the beginning of Source IP address  source route failed the IP header that  Redirect caused the error Destination IP address  Parameter problem  Time exceeded First 64 bits of payload  TTL exceeded  reassembly time exceeded  Echo requEast et Echo reply CNPP/2008.4. © O. Bonaventure, 2007
  • ICMP messages 32 bits Protocol=1 for ICMP Ver IHL DS Total length Identification Flags FragmentOffset covers entire ICMP message IP header TTL Protocol Checksum Source IP address Destination IP address Type Code Checksum ICMP header Type and Code indicate the type of Data error detected  Destination unreachable Ver IHL DS Total length  network unreachable  host unreachable Identification Flags FragmentOffset  protocol unreachable  port unreachable TTL Protocol Checksum  fragmentation needed Copy of the beginning of Source IP address  source route failed the IP header that  Redirect caused the error Destination IP address  Parameter problem  Time exceeded First 64 bits of payload  TTL exceeded  reassembly time exceeded  Echo requEast et Echo reply CNPP/2008.4. © O. Bonaventure, 2007
  • ICMP messages 32 bits Protocol=1 for ICMP Ver IHL DS Total length Identification Flags FragmentOffset covers entire ICMP message IP header TTL Protocol Checksum Additional information about Source IP address error, type of error Destination IP address Type Code Checksum ICMP header Type and Code indicate the type of Data error detected  Destination unreachable Ver IHL DS Total length  network unreachable  host unreachable Identification Flags FragmentOffset  protocol unreachable  port unreachable TTL Protocol Checksum  fragmentation needed Copy of the beginning of Source IP address  source route failed the IP header that  Redirect caused the error Destination IP address  Parameter problem  Time exceeded First 64 bits of payload  TTL exceeded  reassembly time exceeded  Echo requEast et Echo reply CNPP/2008.4. © O. Bonaventure, 2007
  • Usage of ICMP messages  Examples  destination unreachable  the router sending this message did not have a route to reach the destination  time exceeded  the router sending the message received an IP packet with TTL=0  used by traceroute  redirect  to reach destination, another router must be used and ICMP message provides address of this router  echo request / echo reply  used by ping  fragmentation impossible  the packet should have been fragmented by the router sending the ICMP message by this packet had "Don't Fragment" set to true CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer  Basics  Routing  Static routing  Distance vector routing  Link state routing  IP : Internet Protocol  IP version 4  IP version 6  Routing in IP networks CNPP/2008.4. © O. Bonaventure, 2007
  • Issues with IPv4  Late 1980s  Exponential growth of Internet  1990  Other network protocols exist  Governments push for CLNP  1992  Most class B networks will soon be assigned  Networking experts warn that IPv4 address space could become exhausted CNPP/2008.4. © O. Bonaventure, 2008
  • Issues with IPv4 (2)  How to solve the exhaustion of class B addresses ?  Short term solution  Define Classless Interdomain Routing (CIDR) and introduce the necessary changes in routers  Deployment started in 1994  Long term solution  Develop Internet Protocol - next generation (IPng)  call for proposals RFC1550, Dec 1993  Criteria for choix, RFC1719 and RFC1726, Dec. 1994  Proposed solutions  TUBA - RFC1347, June 1992  PIP – RFC1621, RFC1622, May 1994  CATNIP – RFC1707, October 1994  SIP – RFC1710, October 1994  NIMROD – RFC1753, December 1994 CNPP/2008.4.  ENCAPS – RFC1955, June 1996 © O. Bonaventure, 2008
  • Issues with IPv4 (3)  Implementation issues - 1990s  IPv4 packet format is complex  IP forwarding is difficult in hardware  Missing functions - 1990s  IPv4 requires lots of manual configuration  Competing protocols (CLNP, Appletalk, IPX, ...) already supported autoconfiguration in 1990s  How to support Quality of Service in IP ?  Integrated services and Differentiated services did not exist then  How to better support security in IP ?  Security problems started to appear but were less important than today  How to better support mobility in IP ?  GSM started to appear and some were dreaming of CNPP/2008.4. mobile devices attached to the Internet © O. Bonaventure, 2008
  • Main motivation today IPv4 address exhaustion CNPP/2008.4. Source http://www.potaroo.net/tools/ipv4/index.html © O. Bonaventure, 2008
  • Main motivation today IPv4 address exhaustion CNPP/2008.4. Source http://www.potaroo.net/tools/ipv4/index.html © O. Bonaventure, 2008
  • IPv6 addresses IPv4 IP version 6 CNPP/2008.4. © O. Bonaventure, 2008
  • IPv6 addresses IPv4 IP version 6  Each IPv6 address is encoded in 128 bits  3.4 x 10^38 possible addressable devices  340,282,366,920,938,463,463,374,607,431,768,211,456  ∼ 5 x 10^28 addresses per person on the earth  6.65 x 10^23 addresses per square meter  Looks unlimited.... today CNPP/2008.4. © O. Bonaventure, 2008
  • IPv6 addresses IPv4 IP version 6  Each IPv6 address is encoded in 128 bits  3.4 x 10^38 possible addressable devices  340,282,366,920,938,463,463,374,607,431,768,211,456  ∼ 5 x 10^28 addresses per person on the earth  6.65 x 10^23 addresses per square meter  Looks unlimited.... today  Why 128 bits ?  Some wanted variable size addresses  to support IPv4 and 160 bits OSI NSAP  Some wanted 64 bits  Efficient for software, large enough for most needs  Hardware implementers preferred fixed size CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 addressing architecture  Three types of IPv6 addresses  Unicast addresses  An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address  Anycast addresses  An identifier for a set of interfaces. A packet sent to an  anycast address is delivered to the “nearest” one of the interfaces identified by that address  Multicast addresses  An identifier for a set of interfaces. A packet sent to a multicast address is delivered to all interfaces identified by that address. CNPP/2008.4. © O. Bonaventure, 2008
  • Representation of IPv6 addresses  How can we write a 128 bits IPv6 address ?  Hexadecimal format  FEDC:BA98:7654:3210:FEDC:BA98:7654:3210  1080:0:0:0:8:800:200C:417A  Compact hexadecimal format  Some IPv6 addresses contain lots of zero  use "::" to indicate one or more groups of 16 bits of zeros. The "::" can only appear once in an address  Examples  1080:0:0:0:8:800:200C:417A = 1080::8:800:200C:417A  FF01:0:0:0:0:0:0:101 = FF01::101  0:0:0:0:0:0:0:1 = ::1 CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 unicast addresses  Special addresses  Unspecified address : 0:0:0:0:0:0:0:0 (aka ::)  Loopback address : 0:0:0:0:0:0:0:1 (aka ::1)  Global unicast addresses  Addresses will be allocated hierarchically 128 bits N bits M bits 128-N-M bits global routing prefix subnet ID interface ID CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 unicast addresses  Special addresses  Unspecified address : 0:0:0:0:0:0:0:0 (aka ::)  Loopback address : 0:0:0:0:0:0:0:1 (aka ::1)  Global unicast addresses  Addresses will be allocated hierarchically 128 bits N bits M bits 128-N-M bits global routing prefix subnet ID interface ID Can be used to identify the ISP responsible for this address CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 unicast addresses  Special addresses  Unspecified address : 0:0:0:0:0:0:0:0 (aka ::)  Loopback address : 0:0:0:0:0:0:0:1 (aka ::1)  Global unicast addresses  Addresses will be allocated hierarchically 128 bits N bits M bits 128-N-M bits global routing prefix subnet ID interface ID Can be used to identify the ISP responsible for this address A subnet in this ISP or CNPP/2008.4. a customer of this ISP © O. Bonaventure, 2008
  • The IPv6 unicast addresses  Special addresses  Unspecified address : 0:0:0:0:0:0:0:0 (aka ::)  Loopback address : 0:0:0:0:0:0:0:1 (aka ::1)  Global unicast addresses  Addresses will be allocated hierarchically 128 bits N bits M bits 128-N-M bits global routing prefix subnet ID interface ID Can be used to identify the Usually 64 bits ISP responsible for this address Based on MAC Address A subnet in this ISP or CNPP/2008.4. a customer of this ISP © O. Bonaventure, 2008
  • Allocation of IPv6 addresses  IANA controls all IP addresses and delegates assignments of blocks to Regional IP Address Registries (RIR)  RIPE, ARIN, APNIC, AFRINIC, ...  An organisation can be allocated two different types of IPv6 addresses  Provider Independent (PI) addresses  Usually allocated to ISPs or very large enterprises directly by RIRs  Default size is /32  Provider Aggregatable (PA) addresses  Smaller prefixes, assigned by ISPs from their PI block  Size  /48 in the general case, except for very large subscribers  /64 when t one and only one subnet is needed by design  /128 when it is absolutely known that one and only one device is CNPP/2008.4. © O. Bonaventure, 2008 connecting.
  • The IPv6 link-local addresses  Used by hosts and routers attached to the same LAN to exchange IPv6 packets when they donʼt have/need globally routable addresses 128 bits 10 bits 54 bits 64 bits FE80 0000000000.....00000000000 interface ID  Each host must generate one link local address for each of its interfaces  Each IPv6 host will use several IPv6 addresses  Each routers must generate one link local address for each of its interfaces CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 multicast addresses  An IPv6 multicast address identifies a group a receivers 128 bits 8 bits 4 bits 4 bits 112 bits 11111111 flags scope Group ID CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 multicast addresses  An IPv6 multicast address identifies a group a receivers 128 bits 8 bits 4 bits 4 bits 112 bits 11111111 flags scope Group ID Permanent Address Temporary Address CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 multicast addresses  An IPv6 multicast address identifies a group a receivers 128 bits 8 bits 4 bits 4 bits 112 bits 11111111 flags scope Group ID Node local-scope Permanent Address Link-local scope Temporary Address Subnet local-scope Site local-scope Organisation local-scope Global scope CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 multicast addresses  An IPv6 multicast address identifies a group a receivers 128 bits 8 bits 4 bits 4 bits 112 bits 11111111 flags scope Group ID Node local-scope Permanent Address Link-local scope Temporary Address Subnet local-scope Site local-scope Organisation local-scope Global scope  Well known groups  All endsystem automatically belong to the FF02::1 group  All routers automatically belong to the FF02::2 group CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 anycast addresses  Definition  An IPv6 anycast address is an address that is assigned to more than one interface (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance.  Usage  Multiple redundant servers using same address  Example DNS resolvers and DNS servers  Representation  IPv6 anycast addresses are unicast addresses  Required subnet anycast address n bits 128-n bits IPv6 subnet prefix 00000000000000000000000 CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 packet format  Simplified packet format  Fields aligned on 32 bits boundaries to ease implementation 32 bits Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Same as TTL in IPv4 Source IPv6 address (128 bits) Destination IPv6 address (128 bits)  No checksum in IPv6 header  rely on datalink and transport CNPP/2008.4. checksums Bonaventure, 2008 © O.
  • The IPv6 packet format  Simplified packet format  Fields aligned on 32 bits boundaries to ease implementation 32 bits Version=6 Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Same as TTL in IPv4 Source IPv6 address (128 bits) Destination IPv6 address (128 bits)  No checksum in IPv6 header  rely on datalink and transport CNPP/2008.4. checksums Bonaventure, 2008 © O.
  • The IPv6 packet format  Simplified packet format  Fields aligned on 32 bits boundaries to ease implementation 32 bits Version=6 Ver Tclass Flow Label Same as DSCP Payload Length NxtHdr Hop Limit Same as TTL in IPv4 Source IPv6 address (128 bits) Destination IPv6 address (128 bits)  No checksum in IPv6 header  rely on datalink and transport CNPP/2008.4. checksums Bonaventure, 2008 © O.
  • The IPv6 packet format  Simplified packet format  Fields aligned on 32 bits boundaries to ease implementation Unclear utilisation 32 bits Version=6 Ver Tclass Flow Label Same as DSCP Payload Length NxtHdr Hop Limit Same as TTL in IPv4 Source IPv6 address (128 bits) Destination IPv6 address (128 bits)  No checksum in IPv6 header  rely on datalink and transport CNPP/2008.4. checksums Bonaventure, 2008 © O.
  • The IPv6 packet format  Simplified packet format  Fields aligned on 32 bits boundaries to ease implementation Unclear utilisation 32 bits Version=6 Ver Tclass Flow Label Same as DSCP Payload Length NxtHdr Hop Limit Same as TTL in IPv4 Size of packet content in bytes Source IPv6 address (128 bits) Destination IPv6 address (128 bits)  No checksum in IPv6 header  rely on datalink and transport CNPP/2008.4. checksums Bonaventure, 2008 © O.
  • The IPv6 packet format  Simplified packet format  Fields aligned on 32 bits boundaries to ease implementation Unclear utilisation 32 bits Version=6 Ver Tclass Flow Label Same as DSCP Payload Length NxtHdr Hop Limit Same as TTL in IPv4 Size of packet content in bytes Source IPv6 address (128 bits) Used to identify the type of the next header found in the packet payload More functionality than Protocol field in IPv4 Destination IPv6 address (128 bits)  No checksum in IPv6 header  rely on datalink and transport CNPP/2008.4. checksums Bonaventure, 2008 © O.
  • Sample IPv6 packets 32 bits Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address (128 bits) Destination IPv6 address (128 bits) Source port Destination port Length Checksum UDP CNPP/2008.4. © O. Bonaventure, 2008
  • Sample IPv6 packets 32 bits Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address (128 bits) UDP Destination IPv6 address (128 bits) Source port Destination port Length Checksum UDP CNPP/2008.4. © O. Bonaventure, 2008
  • Sample IPv6 packets 32 bits 32 bits Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address (128 bits) Source IPv6 address (128 bits) Destination IPv6 address UDP (128 bits) Destination IPv6 address (128 bits) Source port Destination port Sequence number Source port Destination port Acknowledgment number Length Checksum THL Reserved Flags Window Checksum Urgent pointer UDP TCP CNPP/2008.4. © O. Bonaventure, 2008
  • Sample IPv6 packets 32 bits 32 bits Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address (128 bits) Source IPv6 address TCP (128 bits) Destination IPv6 address UDP (128 bits) Destination IPv6 address (128 bits) Source port Destination port Sequence number Source port Destination port Acknowledgment number Length Checksum THL Reserved Flags Window Checksum Urgent pointer UDP TCP CNPP/2008.4. © O. Bonaventure, 2008
  • Sample IPv6 packets 32 bits 32 bits Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address (128 bits) Source IPv6 address TCP (128 bits) Destination IPv6 address UDP (128 bits) Destination IPv6 address (128 bits) Source port Destination port Sequence number Source port Destination port Acknowledgment number Length Checksum THL Reserved Flags Window Checksum Urgent pointer UDP TCP  Identification of a TCP connection  IPv6 source, IPv6 destination, Source and Destination ports CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 extension headers CNPP/2008.4. © O. Bonaventure, 2008
  • The IPv6 extension headers  Several types of extension headers  Hop-by-Hop Options  contains information to be processed by each hop  Routing (Type 0 and Type 2)  contains information affecting intermediate routers  Fragment  used for fragmentation and reassembly  Destination Options  contains options that are relevant for destination  Authentication  for IPSec  Encapsulating Security Payload  for IPSec  Each header must be encoded as n*64 bits CNPP/2008.4. © O. Bonaventure, 2008
  • Hop-by-hop and destination option headers  TLV format of these options NxtHdr HLen Type Len Data (var. length) CNPP/2008.4. © O. Bonaventure, 2008
  • Hop-by-hop and destination option headers  TLV format of these options NxtHdr HLen Type Len Data (var. length)  Two leftmost bits  How to deal with unknown option ?  00 ignore and continue processing  01 silently discard packet  10 discard packet and send ICMP parameter problem back to source  11 discard packet and send ICMP parameter problem to source if destination isnʼt multicast  Third bit  Can option content be changed en-route  Five rightmost bits  Type assigned by IANA CNPP/2008.4. © O. Bonaventure, 2008
  • IPv6 jumbograms  IPv6 packet format only supports 64 KBytes packets  packet size is encoded in 16 bits field  on most hosts throughput increases with packet size  Hop-by-hop jumbogram option  Increases packet size to 32 bits  when used, packet size in IPv6 header should be set to zero NxtHdr HLen C2 Len:4 Packet size CNPP/2008.4. © O. Bonaventure, 2008
  • IPv6 jumbograms  IPv6 packet format only supports 64 KBytes packets  packet size is encoded in 16 bits field  on most hosts throughput increases with packet size  Hop-by-hop jumbogram option  Increases packet size to 32 bits  when used, packet size in IPv6 header should be set to zero C2 : 11 0 00020 NxtHdr HLen C2 Len:4 11 -> ICMP must be sent Packet size if option is unrecognised 0 -> content of option does not change en-route CNPP/2008.4. © O. Bonaventure, 2008
  • Packet fragmentation CNPP/2008.4. © O. Bonaventure, 2008
  • Packet fragmentation  IPv4 used packet fragmentation on routers  All hosts must handle 576+ bytes packets  experience showed fragmentation is costly for routers and difficult to implement in hardware  PathMTU discovery is now widely implemented CNPP/2008.4. © O. Bonaventure, 2008
  • Packet fragmentation  IPv4 used packet fragmentation on routers  All hosts must handle 576+ bytes packets  experience showed fragmentation is costly for routers and difficult to implement in hardware  PathMTU discovery is now widely implemented  IPv6  IPv6 requires that every link in the internet have an MTU of 1280 octets or more  otherwise link-specific fragmentation and reassembly must be provided at a layer below IPv6  Routers do not perform fragmentation  Only end hosts perform fragmentation and reassembly by using the fragmentation header  But PathMTU discovery should avoid fragmentation most of the time CNPP/2008.4. © O. Bonaventure, 2008
  • A fragmented IPv6 packet First fragment Second (and last) fragment 32 bits 32 bits Ver Tclass Flow Label Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Payload Length NxtHdr Hop Limit Source IPv6 address Source IPv6 address (128 bits) (128 bits) 44:fragment 44:fragment Destination IPv6 address Destination IPv6 address (128 bits) (128 bits) True Nxt Hdr Zero Frag. Offset 0 M Nxt Hdr Zero Frag. Offset 0 M Fragment identification = 1234 Fragment identification = 1234 False UDP Source port Destination port None Length Checksum (end of UDP segment) UDP (first part) CNPP/2008.4. © O. Bonaventure, 2008
  • ICMPv6  Provides the same functions as ICMPv4, and more  Types of ICMPv6 messages  Destination unreachable  Packet too big  Used for PathMTU discovery  Time expired (Hop limit exhausted)  Traceroute v6  Echo request and echo reply  Pingv6  Multicast group membership  Router advertisments  Neighbor discovery  Autoconfiguration CNPP/2008.4. © O. Bonaventure, 2008
  • ICMPv6 packet format Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address (128 bits) Destination IPv6 address (128 bits) Type Code Checksum Message body CNPP/2008.4. © O. Bonaventure, 2008
  • ICMPv6 packet format Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address 58 for ICMPv6 (128 bits) Destination IPv6 address (128 bits) Type Code Checksum Message body CNPP/2008.4. © O. Bonaventure, 2008
  • ICMPv6 packet format Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address 58 for ICMPv6 (128 bits) Covers ICMPv6 message and part of IPv6 header Destination IPv6 address (128 bits) Type Code Checksum Message body CNPP/2008.4. © O. Bonaventure, 2008
  • ICMPv6 packet format Ver Tclass Flow Label Payload Length NxtHdr Hop Limit Source IPv6 address 58 for ICMPv6 (128 bits) Covers ICMPv6 message and part of IPv6 header Destination IPv6 address  Type (128 bits)  ICMPv6 error messages (0<type<127)  1 Destination Unreachable Type Code Checksum  3 Time Exceeded  2 Packet Too Big Message body  4 Parameter Problem  100 Private experimentation  101 Private experimentation  127 Reserved for expansion  ICMPv6 informational messages:  128 Echo Request  129 Echo Reply  200 Private experimentation  201 Private experimentation  255 Reserved for expansion CNPP/2008.4. of ICMPv6 informational Bonaventure, 2008 © O.
  • Middleboxes  The original TCP/IP architecture only defined hosts and routers  Todayʼs networks contain devices that  process  analyse  and possibly modify IP packets  Examples  Firewall  Network Address Translator  Traffic shaper  Deep Packet Inspection  Intrusion Detection System  Load balancer CNPP/2008.4. © O. Bonaventure, 2007
  • Firewall  Problem B A R F Internet entreprise network  How to control the packets entering the entreprise network ?  only allow external access to some servers  allow internal clients to use web  allow smtp (inbound and outbound) only on some dedicated servers  ... CNPP/2008.4. © O. Bonaventure, 2007
  • Firewalls (2)  Principle  Firewall analyses all packet headers  rules specify which packets should be accepted and rejected 32 bits 32 bits Ver IHL ToS Total length Ver IHL ToS Total length Identification Flags Fragment Offset Identification Flags Fragment Offset TTL Protocol Checksum TTL Protocol Checksum Source IP address Source IP address Destination IP address Destination IP address TCP Source port Destination port Source port Destination port Sequence number Length Checksum Acknowledgment number THL Reserved Flags Window UDP Checksum Urgent pointer CNPP/2008.4. © O. Bonaventure, 2007
  • Firewalls : example  Wifi UCLouvain  Outbound  Standard IPSec VPN...  SSH: TCP/22  HTTP: TCP/80, HTTPS: TCP/443  IMAP2+4: TCP/143, IMAP3: TCP/220, IMAPS: TCP/ 993, POP: TCP/110, POP3S: TCP/995, SMTPS: TCP/ 465, SMTP submit with STARTTLS: TCP/587  Passive (S)FTP: TCP/21  RDP: TCP/3389  IPv6 Tunnel Broker service: IP protocol 41  Inbound  OpenVPN 2.0: UDP/1194, IPsec NAT-Traversal UDP/ 4500, PPTP VPN: IP protocol 47 (GRE), Standard IPSec VPN: IP protocols 50 (ESP) and 51 (AH)  IPv6 Tunnel Broker service: IP protocol 41 CNPP/2008.4. © O. Bonaventure, 2007
  • Network Address Translator  Problem  Limited number of public IPv4 addresses  Solution  Use private addresses inside enterprise and home networks  Use one or a few public addresses  translate packets sent to public Internet 192.168.10.11 B A R+N Internet 192.168.10.1 130.104.228.200 192.168.10.10 CNPP/2008.4. © O. Bonaventure, 2007
  • Simple enterprise NAT Internal network public Internet 192.168.0.0/16 R+N 130.104.228.200 - 130.104.228.254  Operation  Mapping table Internal address <-> public address  Packet arrival from internal network  Packet arrival from public network CNPP/2008.4.  How long should mapping remain ? © O. Bonaventure, 2007
  • Single address NAT Internal network public Internet 192.168.0.0/16 R+N 130.104.228.200  Single address NAT  NAT translates IP addresses and TCP/UDP port numbers Private address Protocol Port inside public address Port outside 192.168.10.10 UDP 2340 130.104.228.200 4567 192.168.10.10 TCP 512 130.104.228.200 520 192.168.10.11 TCP 1024 130.104.228.200 2048 CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer  Basics  Routing  IP : Internet Protocol  Routing in IP networks  Internet routing organisation  Intradomain routing : RIP  Intradomain routing : OSPF  Interdomain routing : BGP CNPP/2008.4. © O. Bonaventure, 2007
  • Internet organisation  Internet is an internetwork with a large number of Autonomous Systems (AS)  an AS is a set of routers that are managed by the same administrative entity  Examples : BELNET, UUNET, SKYNET, ...  about 20000 ASes in 2007  Autonomous Systems are interconnected to allow the transmission of IP packets from any source to any destination  On the Internet, most packets need to travel through several transit Autonomous Systems CNPP/2008.4. © O. Bonaventure, 2007
  • Organisation of the Internet  Internet is composed of about 30.000 autonomous routing domains  A domain is a set of routers, links, hosts and local area networks under the same administrative control  A domain can be very large...  AS568: SUMNET-AS DISO-UNRRA contains 73154560 IP addresses  A domain can be very small...  AS2111: IST-ATRIUM TE Experiment a single PC running Linux...  Domains are interconnected in various ways  The interconnection of all domains should in theory allow packets to be sent anywhere  Usually a packet will need to cross a few ASes to reach its destination CNPP/2008.4. © O. Bonaventure, 2003
  • Types of domains  Transit domain  A transit domain allows external domains to use its own infrastructure to send packets to other domains T1 T2 S4 S1 S2 T3 S3  Examples  UUNet, OpenTransit, GEANT, Internet2, RENATER, EQUANT, BT, Telia, Level3,... CNPP/2008.4. © O. Bonaventure, 2003
  • Types of domains (2)  Stub domain  A stub domain does not allow external domains to use its infrastructure to send packets to other domains  A stub is connected to at least one transit domain  Single-homed stub : connected to one transit domain  Dual-homed stub : connected to two transit domains T1 T2 S4 S1 S2 T3 S3  Content-rich stub domain  Large web servers : Yahoo, Google, MSN, TF1, BBC,...  Access-rich stub domain  ISPs providing Internet access via CATV, ADSL, ... CNPP/2008.4. © O. Bonaventure, 2003
  • Sample network : Belnet CNPP/2008.4. © O. Bonaventure, 2007
  • Sample network : GEANT CNPP/2008.4. © O. Bonaventure, 2007
  • A large worldwide network : UUNet CNPP/2008.4. © O. Bonaventure, 2007
  • Internet routing  Interior Gateway Protocol (IGP)  Routing of IP packets inside each domain  Only knows topology of its domain Domain4 Domain2 Domain1 Domain3  Exterior Gateway Protocol (EGP)  Routing of IP packets between domains  Each domain is considered as a blackbox CNPP/2008.4. © O. Bonaventure, 2003
  • Intradomain routing  Goal  Allow routers to transmit IP packets along the best path towards their destination  best usually means the shortest path  Shortest measured in seconds or as number of hops  sometimes best means the less loaded path  Allow to find alternate routes in case of failures  Behaviour  All routers exchange routing information  Each domain router can obtain routing information for the whole domain  The network operator or the routing protocol selects the cost of each link CNPP/2008.4. © O. Bonaventure, 2003
  • Three types of Interior Gateway Protocols  Static routing  Only useful in very small domains  Distance vector routing  Routing Information Protocol (RIP)  Still widely used in small domains despite its limitations  Link-state routing  Open Shortest Path First (OSPF)  Widely used in enterprise networks  Intermediate System- Intermediate-System (IS-IS)  Widely used by ISPs CNPP/2008.4. © O. Bonaventure, 2003
  • Network layer  Basics  Routing  IP : Internet Protocol  Routing in IP networks  Internet routing organisation  Intradomain routing : RIP  Intradomain routing : OSPF  Interdomain routing : BGP CNPP/2008.4. © O. Bonaventure, 2007
  • RIP Routing Information Protocol  Simple routing protocol that relies on distance vectors  Defined in RFC2453  Principle  Each router periodically sends its distance vectors  default period : 30 seconds  distance vector is sent in UDP message with TTL=1 to all routers in local subnets (via IP multicast )  Optional extension : send a distance vector when the routing table changes  simple solution : send distance vector after each change  but some links flaps...  solution : send a distance vector if routing table changed and we did not send another vector within the last 5 seconds CNPP/2008.4. © O. Bonaventure, 2007
  • RIP : message format Version  1 : Prehistoric  2 : Usable 32 bits "Command"  1 : Request Cmd Version Vide  2 : Response 0xFFFF Auth Type Authentication Optional. Configure all routers 16 octets Mot de Passe with the same password. Slightly improves security Route Entry [1] Distance vector One Route Entry (20 bytes) for each route to be advertised Route Entry [N]  RIP messages are sent by UDP  port 520 CNPP/2008.4. © O. Bonaventure, 2007
  • RIP : Route Entries AFI : Address Family Identifier  type of addresses used  2= Ipv4 Marker, rarely used AFI Route tag IP Address Address and mask Mask of destination RIP entry : 20 bytes Next Hop IP Address of nexthop Metric Distance (16= ∞)  Default route  IP Address = 0.0.0.0, Mask = 0  Each RIP message can contain up to 25 route entries (24 with authentication)  If the routing table is larger than 25 entries, router will need to send several RIP messages CNPP/2008.4. © O. Bonaventure, 2007
  • RIP timers  Operation  At each expiration of its 30-sec timer, each router sends its distance vector and restarts its timer  Problem  After a power failure, all routers might restart at same time and have synchronised RIP timers  Each router will need to process bursts of RIP messages  Solution  Add some randomness to the timers  Restart timer after random[27.5, 32.5] instead of 30 seconds  commonly used technique to avoid synchronisation problems in distributed protocols CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer  Basics  Routing  IP : Internet Protocol  Routing in IP networks  Internet routing organisation  Intradomain routing : RIP  Intradomain routing : OSPF  Interdomain routing : BGP CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF  Standardised link state routing protocol  Operation  Router startup  HELLO packets to discover neighbours  Update of routing tables  Link state packets  acknowledgements, sequence numbers, age  periodic transmission  transmission upon link changes  Database description  provides the list of sequence numbers of all LSPs stored by router  Link state Request  used when a router boots to request link state packets from neighbours CNPP/2008.4. OSPF is defined in RFC2328 © O. Bonaventure, 2007
  • OSPF details  Routers are often attached to LANs  How to describe a LAN full of routers as a graph R R R R 138.48.4.1 138.48.4.11 138.48.4.21 138.48.4.31 138.48.4.21 138.48.4.11 138.48.4.31  Drawbacks  Graph contains many links 138.48.4.1  Routers need to exchange lots of HELLOs  Does not really describe the LAN  a failure of the LAN would cause a disconnection of all CNPP/2008.4. routers while the graph indicates a redundantBonaventure, 2007 © O. topology
  • OSPF details (2)  Solution  represent the LAN as a star with one router acting as the LAN  Designated router  One router is elected in the LAN to originate link state packets for the LAN  Adjacent router  Maintain adjacencies with the designated router R R R R 138.48.4.1 138.48.4.11 138.48.4.21 138.48.4.31 138.48.4.21 LAN 138.48.4.11 138.48.4.31 138.48.4.1 CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF details (3) CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF details (3)  OSPF in large networks  avoid too large routing tables in OSPF routers CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF details (3)  OSPF in large networks  avoid too large routing tables in OSPF routers  Solution  Divide network in areas  Backbone area : network backbone  all routers connected to two or more areas belong to the backbone area  All non-backbone areas must be attached to the backbone area  at least one router inside each area must be attached to the backbone CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF details (3)  OSPF in large networks  avoid too large routing tables in OSPF routers  Solution  Divide network in areas  Backbone area : network backbone  all routers connected to two or more areas belong to the backbone area  All non-backbone areas must be attached to the backbone area  at least one router inside each area must be attached to the backbone  OSPF routing must allow any router to send packets to any other router CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF details (4) R1 C R5 Stub AREA 1 D R3 E R4 RA AREA 0 RC RB R7 R8 AREA 2 D R9 E R10 CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF details (4) R1 C R5 Stub AREA 1 Inside each non-backbone area  Routers exchange link state packets to distribute the topology of the area  D R3 Routers do not know the topology of E R4 other areas, but each router knows how to reach the backbone area RA AREA 0 RC RB R7 R8 AREA 2 D R9 E R10 CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF details (4) R1 C R5 Stub AREA 1 Inside each non-backbone area  Routers exchange link state packets to distribute the topology of the area  D R3 Routers do not know the topology of E R4 other areas, but each router knows how to reach the backbone area RA AREA 0 RC Inside backbone area  Routers exchange link state packets to RB distribute the topology of the backbone area  Each router knows how to reach the other R7 areas and distance vectors are used to R8 distribute inter-area routes AREA 2 D R9 E R10 CNPP/2008.4. © O. Bonaventure, 2007
  • OSPF areas : Example Routes learned by R4  192.168.1.0/24, distance 3 (via RA)  192.168.10.0/24, distance 3 (via RA) 10.0.1.0/24 10.0.0.0/24 R5 Routes chosen par RA  192.168.1.0/24, distance 3 (via RB)  192.168.10.0/24, distance 3 (via RC) R4 AREA 1 Distance vectors advertised by RB in backbone area RA  192.168.1.0/24, distance 2 AREA 0 and 192.168.10.0/24, distance 3 RC RB Distance vectors advertised by RB in backbone area  192.168.1.0/24, distance 3 R7 R8 and 192.168.10.0/24, distance 2 192.168.1.0/24 192.168.10.0/24 D R9 E R10 AREA 2 CNPP/2008.4. © O. Bonaventure, 2007
  • Areas OSPF : Example (2) 10.0.1.0/24 10.0.0.0/24 R5 Distance vector advertised by RA in the backbone area 10.0.0.0/24, distance 1 and 10.0.1.0/24, distance 2 R4 AREA 1  or 10.0.0.0/23, distance 2 RA AREA 0 RC RB R7 R8 192.168.1.0/24 192.168.10.0/24 D R9 E R10 AREA 2 CNPP/2008.4. © O. Bonaventure, 2007
  • Network layer  Basics  Routing  IP : Internet Protocol  Routing in IP networks  Internet routing organisation  Intradomain routing : RIP  Intradomain routing : OSPF  Interdomain routing : BGP CNPP/2008.4. © O. Bonaventure, 2007
  • Interdomain routing  Goals  Allow to transmit IP packets along the best path towards their destination through several transit domains while taking into account the routing policies of each domain without knowing the detailed topology of those domains  From an interdomain viewpoint, best path often means cheapest path  Each domain is free to specify inside its routing policy the domains for which it agrees to provide a transit service and the method it uses to select the best path to reach each destination CNPP/2008.4. © O. Bonaventure, 2003
  • Types of interdomain links  Two types of interdomain links  Private link  Usually a leased line between two routers belonging to the two connected domains R1 R2 DomainA DomainB  Connection via a public interconnection point  Usually Gigabit or higher Ethernet switch that interconnects routers belonging to different domains R2 R3 Physical link Interdomain link R1 R4 CNPP/2008.4. © O. Bonaventure, 2003
  • Routing policies  In theory BGP allows each domain to define its own routing policy...  In practice there are two common policies  customer-provider peering  Customer c buys Internet connectivity from provider P  shared-cost peering  Domains x and y agree to exchange packets by using a direct link or through an interconnection point CNPP/2008.4. © O. Bonaventure, 2003
  • Customer-provider peering AS1 AS2 $ $ $ Customer Provider AS3 AS4 $ $ AS7  Principle  Customer sends to its provider its internal routes and the routes learned from its own customers  Provider will advertise those routes to the entire Internet to allow anyone to reach the Customer  Provider sends to its customers all known routes  Customer will be able to reach anyone on the Internet CNPP/2008.4. © O. Bonaventure, 2003
  • Shared-cost peering AS1 AS2 $ $ $ Shared-cost Customer-provider AS3 AS4 $ $ AS7  Principle  PeerX sends to PeerY its internal routes and the routes learned from its own customers  PeerY will use shared link to reach PeerX and PeerX's customers  PeerX's providers are not reachable via the shared link  PeerY sends to PeerX its internal routes and the routes learned from its own customers  PeerX will use shared link to reach PeerY and PeerY's customers  PeerY's providers are not reachable via the shared link CNPP/2008.4. © O. Bonaventure, 2003
  • Customer-provider peering : example AS1 AS2 $ $ $ Customer-provider AS3 AS4 $ $  AS7-AS4 peering link AS7  AS7 advertises its routes to AS4  AS4 advertises to AS7 all its routes  AS4-AS2 peering link  AS4 advertises its own routes et those of its customers (AS7)  AS2 advertises to AS2 all known routes CNPP/2008.4. © O. Bonaventure, 2007
  • Shared-cost peering : example AS1 AS2 $ $ $ Shared-cost Customer-provider AS3 AS4 $ $ AS7  AS3-AS4 peering link  AS3 advertises its own routes  AS4 advertises its own routes and those received from its clients (AS7)  AS1-AS2 peering link  AS1 advertises its own routes and those received from its clients (AS3 and AS4)  AS1 advertises its own routes and those received from its CNPP/2008.4. clients (AS4) © O. Bonaventure, 2007
  • Routing policies  A domain specifies its routing policy by defining on each BGP router two sets of filters for each peer  Import filter  Specifies which routes can be accepted by the router among all the received routes from a given peer  Export filter  Specifies which routes can be advertised by the router to a given peer  Filters can be defined in RPSL  Routing Policy Specification Language  defined in RFC2622 and examples in RFC2650  See also http://www.ripe.net/ripencc/pub-services/whois.html CNPP/2008.4. © O. Bonaventure, 2003
  • RPSL  Simple import policies  Syntax  import: from AS# accept list_of_AS  Examples  Import: from Belgacom accept Belgacom WIN  Import: from Provider accept ANY  Simple export policies  Syntax  Export: to AS# announce list_of_AS  Example  Export: to Customer announce ANY  Export: to Peer announce Customer1 Customer2 CNPP/2008.4. © O. Bonaventure, 2003
  • Routing policies Simple example with RPSL AS1 AS2 $ $ $ Shared-cost Customer-provider AS3 AS4 $ $ Import policy for AS4 Import: from AS3 accept AS3 AS7 import: from AS7 accept AS7 import: from AS1 accept ANY import: from AS2 accept ANY Import policy for AS7 Export policy for AS4 Import: from AS4 accept ANY export: to AS3 announce AS4 AS7 export: to AS7 announce ANY Export policy for AS4 export: to AS1 announce AS4 AS7 export: to AS4 announce AS7 export: to AS2 announce AS4 AS7 CNPP/2008.4. © O. Bonaventure, 2003
  • The organisation of the Internet CNPP/2008.4. © O. Bonaventure, 2003
  • The organisation of the Internet  Tier-1 ISPs  Dozen of large ISPs interconnected by shared-cost  Provide transit service  Uunet, Level3, OpenTransit, ...  Tier-2 ISPs  Regional or National ISPs  Customer of T1 ISP(s)  Provider of T3 ISP(s)  shared-cost with other T2 ISPs  France Telecom, BT, Belgacom  Tier-3 ISPs  Smaller ISPs, Corporate Networks, Content providers  Customers of T2 or T1 ISPs  shared-cost with other T3 ISPs CNPP/2008.4. © O. Bonaventure, 2003
  • The Border Gateway Protocol  Principle  Path vector protocol  BGP router advertises its best route to each destination AS5 1.0.0.0/8 AS1 AS2 AS4 CNPP/2008.4. BGP is defined in RFC4271 © O. Bonaventure, 2003
  • The Border Gateway Protocol  Principle  Path vector protocol  BGP router advertises its best route to each destination AS5 1.0.0.0/8 AS1 AS2  prefix:1.0.0.0/8  ASPath: AS1 AS4 CNPP/2008.4. BGP is defined in RFC4271 © O. Bonaventure, 2003
  • The Border Gateway Protocol  Principle  Path vector protocol  BGP router advertises its best route to each destination  prefix:1.0.0.0/8 AS5  ASPath: AS1 1.0.0.0/8 AS1 AS2  prefix:1.0.0.0/8  ASPath: AS1 AS4 CNPP/2008.4. BGP is defined in RFC4271 © O. Bonaventure, 2003
  • The Border Gateway Protocol  Principle  Path vector protocol  BGP router advertises its best route to each destination  prefix:1.0.0.0/8 AS5  ASPath: AS1 1.0.0.0/8 AS1 AS2  prefix:1.0.0.0/8  prefix:1.0.0.0/8  ASPath: AS1  ASPath: AS4:AS1 AS4 CNPP/2008.4. BGP is defined in RFC4271 © O. Bonaventure, 2003
  • The Border Gateway Protocol  Principle  Path vector protocol  BGP router advertises its best route to each destination  prefix:1.0.0.0/8 AS5  ASPath: AS1 1.0.0.0/8 AS1 AS2  prefix:1.0.0.0/8  ASPath: ::AS2:AS4:AS1  prefix:1.0.0.0/8  prefix:1.0.0.0/8  ASPath: AS1  ASPath: AS4:AS1 AS4 CNPP/2008.4. BGP is defined in RFC4271 © O. Bonaventure, 2003
  • The Border Gateway Protocol  Principle  Path vector protocol  BGP router advertises its best route to each destination  prefix:1.0.0.0/8 AS5  ASPath: AS1 1.0.0.0/8 AS1 AS2  prefix:1.0.0.0/8  ASPath: ::AS2:AS4:AS1  prefix:1.0.0.0/8  prefix:1.0.0.0/8  ASPath: AS1  ASPath: AS4:AS1 AS4  ... with incremental updates  Advertisements are only sent when their content changes CNPP/2008.4. BGP is defined in RFC4271 © O. Bonaventure, 2003
  • BGP : Principles of operation  Principles  BGP relies on the incremental exchange of path vectors AS3 R1 BGP session BGP Msgs R2 AS4 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP : Principles of operation  Principles  BGP relies on the incremental exchange of path vectors BGP session established over AS3 TCP connection between peers R1 BGP session BGP Msgs R2 AS4 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP : Principles of operation  Principles  BGP relies on the incremental exchange of path vectors BGP session established over AS3 TCP connection between peers R1 BGP session Each peer sends all its active routes BGP Msgs R2 AS4 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP : Principles of operation  Principles  BGP relies on the incremental exchange of path vectors BGP session established over AS3 TCP connection between peers R1 BGP session Each peer sends all its active routes BGP Msgs R2 AS4 As long as the BGP session remains up Incrementally update BGP routing tables CNPP/2008.4. © O. Bonaventure, 2003
  • BGP : Principles of operation (2)  Simplified model of BGP  2 types of BGP path vectors  UPDATE  Used to announce a route towards one prefix  Content of UPDATE  Destination address/prefix  Interdomain path used to reach destination (AS-Path)  Nexthop (address of the router advertising the route)  WITHDRAW  Used to indicate that a previously announced route is not reachable anymore  Content of WITHDRAW  Unreachable destination address/prefix CNPP/2008.4. © O. Bonaventure, 2003
  • Conceptual model of a BGP router BGP Adj-RIB-In BGP Loc-RIB Peer[N] BGP Adj-RIB-Out All BGP Msgs acceptable from Peer[N] Peer[N] BGP Msgs Peer[1] routes to Peer[N] Import filter BGP Msgs from Peer[1] Attribute Peer[1] manipulation BGP Decision BGP Msgs Process Export filter to Peer[1] Attribute One best manipulation Import filter(Peer[i]) route to each Determines which BGM Msgs destination are acceptable from Peer[i] Export filter(Peer[i]) Determines which routes can be sent to Peer[i] BGP Routing Information Base Contains all the acceptable routes learned from all Peers + internal routes  BGP decision process selects the best route towards each destination CNPP/2008.4. © O. Bonaventure, 2003
  • Where do the routes advertised by BGP routers come from ?  Learned from another BGP router  Each BGP router advertises best route towards each destination  Static route  Configured manually on the router  Ex : The BGP router at UCL advertises 130.104.0.0/16  Drawback  Requires manual configuration  Advantage  BGP advertisements are stable  Learned from an intradomain routing protocol  BGP might try to aggregate the route before advertising it  Advantage :  BGP advertisements correspond to network status  Drawback  Routing instabilities inside a domain might propagate in CNPP/2008.4. Internet © O. Bonaventure, 2007
  • BGP : Session Initialization Initialize_BGP_Session(RemoteAS, RemoteIP) { /* Initialize and start BGP session */ /* Send BGP OPEN Message to RemoteIP on port 179*/ /* Follow BGP state machine */ /* advertise local routes and routes learned from peers*/ foreach (destination=d inside RIB) { B=build_BGP_UPDATE(d); S=apply_export_filter(RemoteAS,B); if (S<>NULL) { /* send UPDATE message */ send_UPDATE(S,RemoteAS, RemoteIP) } } /* entire RIB was sent */ /* new UPDATE will be sent only to reflect local or distant changes in routes */ ... } CNPP/2008.4. © O. Bonaventure, 2007
  • Events during a BGP session 1. Addition of a new route to RIB  A new internal route was added on local router  static route added by configuration  Dynamic route learned from IGP  Reception of UPDATE message announcing a new or modified route 2. Removal of a route from RIB  Removal of an internal route  Static route is removed from router configuration  Intradomain route declared unreachable by IGP  Reception of WITHDRAW message 3. Loss of BGP session  All routes learned from this peer removed from RIB CNPP/2008.4. © O. Bonaventure, 2003
  • Export and Import filters BGPMsg Apply_export_filter(RemoteAS, BGPMsg) { /* check if Remote AS already received route */ if (RemoteAS isin BGPMsg.ASPath) BGPMsg==NULL; /* Many additional export policies can be configured : */ /* Accept or refuse the BGPMsg */ /* Modify selected attributes inside BGPMsg */ } BGPMsg apply_import_filter(RemoteAS, BGPMsg) { /* check that we are not already inside ASPath */ if (MyAS isin BGPMsg.ASPath) BGPMsg==NULL; /* Many additional import policies can be configured : */ /* Accept or refuse the BGPMsg */ /* Modify selected attributes inside BGPMsg */ } CNPP/2008.4. © O. Bonaventure, 2003
  • BGP : Processing of UPDATES Recvd_BGPMsg(Msg, RemoteAS) { B=apply_import_filer(Msg,RemoteAS); if (B==NULL) /* Msg not acceptable */ exit(); if IsUPDATE(Msg) { Old_Route=BestRoute(Msg.prefix); Insert_in_RIB(Msg); Run_Decision_Process(RIB); if (BestRoute(Msg.prefix)<>Old_Route) { /* best route changed */ B=build_BGP_Message(Msg.prefix); S=apply_export_filter(RemoteAS,B); if (S<>NULL) /* announce best route */ send_UPDATE(S,RemoteAS); else if (Old_Route<>NULL) send_WITHDRAW(Msg.prefix); } ... CNPP/2008.4. © O. Bonaventure, 2003
  • BGP : Processing of WITHDRAW Recvd_Msg(Msg, RemoteAS) ... if IsWITHDRAW(Msg) { Old_Route=BestRoute(Msg.prefix); Remove_from_RIB(Msg); Run_Decision_Process(RIB); if (Best_Route(Msg.prefix)<>Old_Route) { /* best route changed */ B=build_BGP_Message(d); S=apply_export_filter(RemoteAS,B); if (S<>NULL) /* still one best route */ send_UPDATE(S,RemoteAS, RemoteIP); else if(Old_Route<>NULL)/* no best route anymore */ send_WITHDRAW(Msg.prefix,RemoteAS,RemoteIP); } } } CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A first example  Initial updates AS10 AS30 AS20 R1 R2 R3 BGP 194.100.0.0/24 194.100.1.0/24 BGP BGP R4 AS40 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A first example  Initial updates AS10 AS30 AS20 R1 R2 R3 BGP 194.100.0.0/24 194.100.1.0/24 BGP BGP UPDATE  prefix:194.100.0.0/24,  NextHop:R1  ASPath: AS10 R4 AS40 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A first example  Initial updates UPDATE  prefix:194.100.0.0/24,  NextHop:R1  ASPath: AS10 AS10 AS30 AS20 R1 R2 R3 BGP 194.100.0.0/24 194.100.1.0/24 BGP BGP UPDATE  prefix:194.100.0.0/24,  NextHop:R1  ASPath: AS10 R4 AS40 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A first example  Initial updates UPDATE  prefix:194.100.0.0/24,  NextHop:R1  ASPath: AS10 AS10 AS30 AS20 R1 R2 R3 BGP 194.100.0.0/24 194.100.1.0/24 BGP BGP UPDATE UPDATE  prefix:194.100.0.0/24,  prefix:194.100.0.0/24,  NextHop:R1  NextHop:R4  ASPath: AS40:AS10  ASPath: AS10 R4 AS40 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A first example  Initial updates UPDATE UPDATE  prefix:194.100.0.0/24,  prefix:194.100.0.0/24,  NextHop:R1  NextHop:R2  ASPath: AS20:AS10  ASPath: AS10 AS10 AS30 AS20 R1 R2 R3 BGP 194.100.0.0/24 194.100.1.0/24 BGP BGP UPDATE UPDATE  prefix:194.100.0.0/24,  prefix:194.100.0.0/24,  NextHop:R1  NextHop:R4  ASPath: AS40:AS10  ASPath: AS10 R4 AS40 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A first example  Initial updates UPDATE UPDATE  prefix:194.100.0.0/24,  prefix:194.100.0.0/24,  NextHop:R1  NextHop:R2  ASPath: AS20:AS10  ASPath: AS10 AS10 AS30 AS20 R1 R2 R3 BGP 194.100.0.0/24 194.100.1.0/24 BGP BGP UPDATE UPDATE  prefix:194.100.0.0/24,  prefix:194.100.0.0/24,  NextHop:R1  NextHop:R4  ASPath: AS40:AS10  ASPath: AS10 R4 AS40  What happens if link AS10-AS20 goes down ? CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP 194.100.1.0/24 194.100.2.0/23  Main Path attributes of UPDATE message  NextHop : IP address of router used to reach destination  ASPath : Path followed by the route advertisement CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP 194.100.1.0/24 194.100.2.0/23 UPDATE  prefix:194.100.0.0/24,  NextHop:195.100.0.1  ASPath: AS10  Main Path attributes of UPDATE message  NextHop : IP address of router used to reach destination  ASPath : Path followed by the route advertisement CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP 194.100.1.0/24 194.100.2.0/23 UPDATE  prefix:194.100.0.0/24,  NextHop:195.100.0.1  ASPath: AS10 UPDATE  prefix:194.100.2.0/23,  NextHop:195.100.0.2  ASPath: AS20  Main Path attributes of UPDATE message  NextHop : IP address of router used to reach destination  ASPath : Path followed by the route advertisement CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example (2) AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP BGP 194.100.1.0/24 194.100.2.0/23 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example (2) AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP BGP 194.100.1.0/24 194.100.2.0/23 UPDATE  prefix:194.100.0.0/24  NextHop:195.100.0.5  ASPath: AS20:AS10 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example (2) AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP BGP 194.100.1.0/24 194.100.2.0/23 UPDATE  prefix:194.100.0.0/24  NextHop:195.100.0.5  ASPath: AS20:AS10 UPDATE  prefix:194.100.2.0/23  NextHop:195.100.0.5  ASPath: AS20 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example (2) AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP BGP 194.100.1.0/24 194.100.2.0/23 UPDATE  prefix:194.100.0.0/24  NextHop:195.100.0.5  ASPath: AS20:AS10 UPDATE  prefix:194.100.2.0/23  NextHop:195.100.0.5  ASPath: AS20 UPDATE  prefix:194.100.1.0/24,  NextHop:195.100.0.6  ASPath: AS30 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example (2) AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP BGP 194.100.1.0/24 194.100.2.0/23 UPDATE  prefix:194.100.0.0/24  NextHop:195.100.0.5  ASPath: AS20:AS10 UPDATE  prefix:194.100.2.0/23  NextHop:195.100.0.5  ASPath: AS20 UPDATE UPDATE  prefix:194.100.1.0/24,  prefix:194.100.1.0/24,  NextHop:195.100.0.6  NextHop:195.100.0.2  ASPath: AS20;AS30  ASPath: AS30 CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP A second example (3) AS10 AS20 AS30 195.100.0.0/30 195.100.0.4/30 R1 195.100.0.1 195.100.0.2 R2 195.100.0.5 195.100.0.6 R3 194.100.0.0/24 BGP 194.100.1.0/24 194.100.2.0/23 WITHDRAW  prefix:194.100.1.0/24 CNPP/2008.4. © O. Bonaventure, 2003
  • How to prefer some routes over others ? RA RB AS2 Backup: 2Mbps Primary: 34Mbps R1 AS1  How to ensure that packets will flow on primary link ? RA RB AS3 AS2 R3 Expensive R5 AS5 Cheap AS4 AS1 R1 R2  How to prefer cheap link over expensive link ? CNPP/2008.4. © O. Bonaventure, 2003
  • How to prefer some routes over others (2) ? BGP RIB All acceptable Peer[N] Peer[N] routes BGP Msgs BGP Msgs from Peer[N] to Peer[N] Peer[1] BGP Decision Peer[1] Import filter Process Export filter BGP Msgs Attribute Attribute BGP Msgs from Peer[1] manipulation One best manipulation to Peer[1] route to each destination Import filter Simplified BGP Decision Process  Selection of acceptable routes  Select routes with highest  Addition of local-pref attribute local-pref inside received BGP Msg  If there are several routes,  Normal quality route : local-pref=100  Better than normal route :local-pref=200 choose routes with the  Worse than normal route :local-pref=50 shortest ASPath  If there are still several routes tie-breaking rule CNPP/2008.4. © O. Bonaventure, 2003
  • How to prefer some routes over others (3) ? RA RB AS2 Backup: 2Mbps Primary: 34Mbps R1 AS1 RPSL-like policy for AS1 RPSL-like policy for AS2 aut-num: AS1 aut-num: AS2 import: from AS2 RA at R1 set localpref=100; import: from AS1 R1 at RA set localpref=100; from AS2 RB at R1 set localpref=200; from AS1 R1 at RB set localpref=200; accept ANY accept AS1 export: to AS2 RA at R1 announce AS1 export: to AS1 R1 at RA announce ANY to AS2 RB at R1 announce AS1 to AS2 R1 at RB announce ANY CNPP/2008.4. © O. Bonaventure, 2003
  • How to prefer some routes over others (4) ? RA RB AS3 AS2 R3 Expensive R5 AS5 Cheap AS4 AS1 R1 R2 RPSL policy for AS1 aut-num: AS1 import: from AS2 RA at R1 set localpref=100; from AS4 R2 at R1 set localpref=200; accept ANY export: to AS2 RA at R1 announce AS1 to AS4 R2 at R1 announce AS1  AS1 will prefer to send packets over the cheap link  But the flow of the packets destined to AS1 will depend on the routing policy of the other domains CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref  In theory  Each domain is free to define its order of preference for the routes learned from external peers 1.0.0.0/8 AS1 Preferred paths for AS3 Preferred paths for AS4 1. AS4:AS1 1. AS3:AS1 2. AS1 2. AS1 AS3 AS4  How to reach 1.0.0.0/8 from AS3 and AS4 ? CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (2)  AS1 sends its UPDATE messages ... 1.0.0.0/8 AS1 AS3 AS4 CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (2)  AS1 sends its UPDATE messages ... 1.0.0.0/8 UPDATE  Prefix:1.0.0.0/8  ASPath: AS1 AS1 AS3 AS4 Preferred paths for AS3 1. AS4:AS1 2. AS1 Routing table for AS3 1.0.0.0/8 ASPath: AS1 (best) CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (2)  AS1 sends its UPDATE messages ... 1.0.0.0/8 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS1 AS1  ASPath: AS1 AS3 AS4 Preferred paths for AS4 Preferred paths for AS3 1. AS3:AS1 1. AS4:AS1 2. AS1 2. AS1 Routing table for AS3 Routing table for AS4 1.0.0.0/8 ASPath: AS1 (best) 1.0.0.0/8 ASPath: AS1 (best) CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (3)  First possibility  AS3 sends its UPDATE first... 1.0.0.0/8 AS1 Preferred paths for AS3 1. AS4:AS1 2. AS1 AS3 AS4 Routing table for AS3 1.0.0.0/8 ASPath: AS1 (best) CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (3)  First possibility  AS3 sends its UPDATE first... 1.0.0.0/8 Preferred paths for AS4 AS1 1. AS3:AS1 2. AS1 Preferred paths for AS3 1. AS4:AS1 2. AS1 AS3 AS4 Routing table for AS3 UPDATE Routing table for AS4 1.0.0.0/8 ASPath: AS1 (best) Prefix:1.0.0.0/8   ASPath: AS3:AS1 1.0.0.0/8 ASPath: AS1 1.0.0.0/8 ASPath:AS3:AS1 (best)  Stable route assignment CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (4)  Second possibility  AS4 sends its UPDATE first... 1.0.0.0/8 AS1 Preferred paths for AS4 1. AS3:AS1 2. AS1 AS3 AS4 Routing table for AS4 1.0.0.0/8 ASPath: AS1 (best) CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (4)  Second possibility  AS4 sends its UPDATE first... 1.0.0.0/8 AS1 Preferred paths for AS4 1. AS3:AS1 Preferred paths for AS3 2. AS1 1. AS4:AS1 2. AS1 AS3 AS4 Routing table for AS3 1.0.0.0/8 ASPath: AS1 UPDATE Routing table for AS4  Prefix:1.0.0.0/8 1.0.0.0/8 ASPath: AS1 (best) 1.0.0.0/8 ASPath: AS4:AS1 (best)  ASPath: AS4:AS1  Another (but different) stable route assignment CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (5)  Third possibility  AS3 and AS4 send their UPDATE together... 1.0.0.0/8 AS1 Preferred paths for AS4 Preferred paths for AS3 1. AS3:AS1 1. AS4:AS1 2. AS1 2. AS1 AS3 AS4 CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (5)  Third possibility  AS3 and AS4 send their UPDATE together... 1.0.0.0/8 AS1 Preferred paths for AS4 Preferred paths for AS3 1. AS3:AS1 1. AS4:AS1 2. AS1 2. AS1 AS3 AS4 UPDATE  Prefix:1.0.0.0/8  ASPath: AS4:AS1 CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (5)  Third possibility  AS3 and AS4 send their UPDATE together... 1.0.0.0/8 AS1 Preferred paths for AS4 Preferred paths for AS3 1. AS3:AS1 1. AS4:AS1 2. AS1 2. AS1 AS3 AS4 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS3:AS1  ASPath: AS4:AS1 CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (5)  Third possibility  AS3 and AS4 send their UPDATE together... 1.0.0.0/8 AS1 Preferred paths for AS4 Preferred paths for AS3 1. AS3:AS1 1. AS4:AS1 2. AS1 2. AS1 AS3 AS4 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS3:AS1  ASPath: AS4:AS1  AS3 prefers the indirect path and will thus send withdraw since the chosen best path is via AS4  AS4 prefers the indirect path and will thus send withdraw CNPP/2008.4.since the chosen best path is via AS3 © O. Bonaventure, 2003
  • Limitations of local-pref (6)  Third possibility (cont.)  AS3 and AS4 send their UPDATE together... 1.0.0.0/8 Preferred paths for AS3 Preferred paths for AS4 1. AS4:AS1 AS1 1. AS3:AS1 2. AS1 2. AS1 AS3 AS4 CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (6)  Third possibility (cont.)  AS3 and AS4 send their UPDATE together... 1.0.0.0/8 Preferred paths for AS3 Preferred paths for AS4 1. AS4:AS1 AS1 1. AS3:AS1 2. AS1 2. AS1 AS3 AS4 WITHDRAW  Prefix:1.0.0.0/8  AS3 learns that the indirect route is not available anymore  AS3 will reannounce its direct route... CNPP/2008.4. © O. Bonaventure, 2003
  • Limitations of local-pref (6)  Third possibility (cont.)  AS3 and AS4 send their UPDATE together... 1.0.0.0/8 Preferred paths for AS3 Preferred paths for AS4 1. AS4:AS1 AS1 1. AS3:AS1 2. AS1 2. AS1 AS3 AS4 WITHDRAW  Prefix:1.0.0.0/8 WITHDRAW  Prefix:1.0.0.0/8  AS3 learns that the indirect route is not available anymore  AS3 will reannounce its direct route...  AS4 learns that the indirect route is not available anymore  AS4 will reannounce its direct route... CNPP/2008.4. © O. Bonaventure, 2003
  • More limitations of local-pref  Unfortunately, interdomain routing may not converge at all in some cases... Preferred paths for AS1 AS1 1. AS3:AS0 2. other paths Preferred paths for AS4 Preferred paths for AS3 AS0 1. AS1:AS0 1. AS4:AS0 2. other paths 2. other paths AS3 AS4  How to reach a destination inside AS0 in this case ? CNPP/2008.4. © O. Bonaventure, 2003
  • local-pref and economical relationships  In practice, local-pref is often used to enforce economical relationships Prov1 Prov2 $ $ Peer1 Peer3 AS1 Peer2 Peer4 $ $ Cust1 Cust2 Shared-cost Local-pref values used by AS1 $ Customer-provider > 1000 for the routes received from a Customer 500 – 999 for the routes learned from a Peer < 500 for the routes learned from a Provider CNPP/2008.4. © O. Bonaventure, 2003
  • Consequence of this utilisation of local-pref  Which route will be used by AS1 to reach AS5 ? AS2 $ AS1 AS3 $ $ $ AS4 AS8 $ $ Shared-cost $ Customer-provider AS6 $ AS5 $ AS7  and how will AS5 reach AS1 ? CNPP/2008.4. © O. Bonaventure, 2003
  • Consequence of this utilisation of local-pref  Which route will be used by AS1 to reach AS5 ? AS2 $ AS1 AS3 $ $ $ AS4 AS8 $ $ Shared-cost $ Customer-provider AS6 $ AS5 $ AS7  and how will AS5 reach AS1 ? CNPP/2008.4. Internet paths are often asymmetrical © O. Bonaventure, 2003
  • BGP and IP Second example 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 BGP 194.100.0.0/23 195.100.0.8/30 BGP AS20 195.100.0.9 195.100.0.4/30 194.100.4.0/23 R4 195.100.0.5  Problem  How can R2 (resp. R4) advertise to R4 (resp. R2) the routes learned from AS10 (resp. AS30) ? CNPP/2008.4. © O. Bonaventure, 2003
  • BGP and IP Second example (2) 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 BGP IGP 194.100.0.0/23 BGP AS20 195.100.0.8/30 195.100.0.9 195.100.0.4/30 194.100.4.0/23 R4 195.100.0.5  First solution  Use IGP (OSPF/ISIS,RIP) to carry BGP routes  Drawbacks  IGP may not be able to support so many routes  IGP does not carry BGP attributes like ASPath ! CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP and eBGP 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 195.100.0.8/30 AS20 iBGP eBGP 195.100.0.9 195.100.0.4/30 194.100.4.0/23 R4 195.100.0.5  Solution  Use BGP to carry routes between all routers of domain  Two different types of BGP sessions  eBGP between routers belonging to different ASes  iBGP between each pair of routers belonging to the same AS  Each BGP router inside ASx maintains an iBGP session with all other BGP routers of ASx (full iBGP mesh)  Note that the iBGP sessions do not necessarily follow physical topology CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP versus eBGP  Differences between iBGP and eBGP  local-pref attribute is only carried inside messages sent over iBGP session  Over an eBGP session, a router only advertises its best route towards each destination  Usually, import and export filters are defined for each eBGP session  Over an iBGP session, a router advertises only its best routes learned over eBGP sessions  A route learned over an iBGP session is never advertised over another iBGP session  Usually, no filter is applied on iBGP sessions CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP and eBGP : Example 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 195.100.0.8/30 AS20 iBGP eBGP 195.100.0.9 195.100.0.4/30 R4 195.100.0.5 194.100.4.0/23 CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP and eBGP : Example UPDATE (via eBGP)  Prefix:194.100.0.0/23,  NextHop:195.100.0.1  ASPath: AS10 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 195.100.0.8/30 AS20 iBGP eBGP 195.100.0.9 195.100.0.4/30 R4 195.100.0.5 194.100.4.0/23 CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP and eBGP : Example UPDATE (via eBGP)  Prefix:194.100.0.0/23,  NextHop:195.100.0.1  ASPath: AS10 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 195.100.0.8/30 AS20 iBGP eBGP 195.100.0.9 195.100.0.4/30 UPDATE (via iBGP)  Prefix:194.100.0.0/23,  NextHop:195.100.0.1 R4 195.100.0.5  ASPath: AS10  Local-pref:1000 194.100.4.0/23 CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP and eBGP : Example UPDATE (via eBGP)  Prefix:194.100.0.0/23,  NextHop:195.100.0.1  ASPath: AS10 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 195.100.0.8/30 AS20 iBGP eBGP 195.100.0.9 195.100.0.4/30 UPDATE (via iBGP)  Prefix:194.100.0.0/23,  NextHop:195.100.0.1 R4 195.100.0.5 UPDATE (via eBGP)  ASPath: AS10  Prefix:194.100.0.0/23,  Local-pref:1000 194.100.4.0/23  NextHop:195.100.0.5  ASPath: AS20:AS10 CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP and eBGP : Example UPDATE (via eBGP)  Prefix:194.100.0.0/23,  NextHop:195.100.0.1  ASPath: AS10 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 195.100.0.8/30 AS20 iBGP eBGP 195.100.0.9 195.100.0.4/30 UPDATE (via iBGP)  Prefix:194.100.0.0/23,  NextHop:195.100.0.1 R4 195.100.0.5 UPDATE (via eBGP)  ASPath: AS10  Prefix:194.100.0.0/23,  Local-pref:1000 194.100.4.0/23  NextHop:195.100.0.5  ASPath: AS20:AS10  Note that the next-hop and the AS-Path of BGP update messages are only updated when sent over an eBGP session CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP and eBGP Packet Forwarding 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 195.100.0.8/30 AS20 iBGP eBGP 195.100.0.9 195.100.0.4/30 BGP routing table of R2 194.100.0.0/23 via 195.100.0.1 194.100.4.0/23 R4 195.100.0.5 IGP routing table of R2 195.100.0.0/30 West BGP routing table of R4 195.100.0.4/30 via 195.100.0.9 194.100.0.0/23 via 195.100.0.1 195.100.0.8/30 South 194.100.0.4/23 via 195.100.0.9 IGP routing table of R4 194.100.2.0/23 North 195.100.0.0/30 via 195.100.0.10 195.100.0.4/30 East 195.100.0.8/30 North 194.100.2.0/23 via 195.100.0.10 194.100.0.4/23 West CNPP/2008.4. © O. Bonaventure, 2003
  • iBGP and eBGP Packet Forwarding (2) 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.10 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 195.100.0.8/30 AS20 iBGP eBGP 195.100.0.9 195.100.0.4/30 194.100.4.0/23 R4 195.100.0.5 BGP routing table of R4 194.100.0.0/23 via 195.100.0.1 Forwarding of R4 IGP routing table of R4 194.100.0.0/23 via 195.100.0.10 195.100.0.0/30 via 195.100.0.10 195.100.0.0/30 via 195.100.0.10 195.100.0.4/30 East 195.100.0.4/30 East 195.100.0.8/30 North 195.100.0.8/30 North 194.100.2.0/23 via 195.100.0.10 194.100.2.0/23 via 195.100.0.10 194.100.4.0/23 West 194.100.4.0/23 West CNPP/2008.4. © O. Bonaventure, 2003
  • Using non-BGP routers 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 R5 AS20 iBGP eBGP 12.0.0.0/8 195.100.0.4/30 194.100.4.0/23 R4 195.100.0.5  Problem  What happens when there are internal backbone routers between BGP routers inside an AS ?  iBGP session between BGP routers is easily established when IGP is running since iBGP runs over TCP connection  How to populate the routing table of the backbone routers to ensure that they will be able to route any IP packet ? CNPP/2008.4. © O. Bonaventure, 2003
  • Using non-BGP routers (2) 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 R5 AS20 iBGP eBGP 195.100.0.4/30 194.100.4.0/23 R4 195.100.0.5  First solution  Use tunnels between BGP routers to encapsulate interdomain packets  GRE tunnel  Needs static configuration and be careful with MTU issues  MPLS tunnel  Can be dynamically established in MPLS enabled backbone CNPP/2008.4. © O. Bonaventure, 2003
  • Using non-BGP routers (3) 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 R5 AS20 iBGP eBGP 12.0.0.0/8 195.100.0.4/30 194.100.4.0/23 R4 195.100.0.5  Second solution  Use IGP (OSPF/IS-IS - RIP) to redistribute interdomain routes to internal backbone routers  Drawbacks  Size of BGP tables may completely overload the IGP  Make sure that BGP routes learned by R2 and injected inside IGP will not be re-injected inside BGP by R4 ! CNPP/2008.4. © O. Bonaventure, 2003
  • Using non-BGP routers (4) 194.100.2.0/23 AS10 AS30 195.100.0.2 R2 195.100.0.0/30 iBGP 195.100.0.6 R1 195.100.0.1 R3 eBGP 194.100.0.0/23 R5 AS20 iBGP eBGP iBGP 12.0.0.0/8 195.100.0.4/30 194.100.4.0/23 R4 195.100.0.5  Third solution  Run BGP on internal backbone routers  Internal backbone routers need to participate in iBGP full mesh  Internal backbone routers receive BGP routes via iBGP but never advertise any routes  Remember : a route learned over an iBGP session is never advertised over another iBGP session CNPP/2008.4. © O. Bonaventure, 2003
  • The roles of IGP and BGP 194.100.2.0/23 AS10 195.100.0.2 R2 195.100.0.0/30 iBGP R1 195.100.0.1 eBGP 194.100.0.0/23 R5 AS20 iBGP iBGP AS30 195.100.0.4/30 R4 195.100.0.6 194.100.4.0/23 R3 eBGP  Role of the IGP inside AS20 12.0.0.0/8  Distribute internal topology and internal addresses R2-R4-R5)  Role of BGP inside AS20  Distribute the routes towards external destinations  IGP must run to allow BGP routers to establish iBGP sessions CNPP/2008.4. © O. Bonaventure, 2003
  • The iBGP full mesh  Drawback  N*(N-1)/2 iBGP sessions for N routers R R R R R R R R R iBGP session CNPP/2008.4. © O. Bonaventure, 2003
  • The BGP decision process BGP RIB All acceptable Peer[N] Peer[N] routes BGP Msgs BGP Msgs from Peer[N] to Peer[N] Peer[1] BGP Decision Peer[1] Import filter Process Export filter BGP Msgs Attribute Attribute BGP Msgs from Peer[1] manipulation One best manipulation to Peer[1] route to each destination BGP Decision Process  Ignore routes with unreachable nexthop  Prefer routes with highest local-pref  Prefer routes with shortest ASPath  Prefer routes with smallest MED  Prefer routes learned via eBGP over routes learned via iBGP  Prefer routes with closest next-hop  Tie breaking rules  Prefer Routes learned from router with lowest router id CNPP/2008.4. © O. Bonaventure, 2003
  • The shortest AS-Path step in the BGP decision process  Motivation  BGP does not contain a real “ metric”  Use length of AS-Path as an indication of the quality of routes  Not always a good indicator R0 R1 RA R2 RB R3 RC R4  Consequence  Internet paths tend to be short, 3-5 AS hops  Many paths converge at Tier-1 ISPs and those ISPs carry lots of traffic CNPP/2008.4. © O. Bonaventure, 2003
  • The prefer eBGP over iBGP step in the BGP decision process  Motivation : hot potato routing  A router should try to get rid of packets sent to external domains as soon as possible AS1 R6's routing table R8 1/8:AS2 via R2 (eBGP,best) C=50 R7's routing table 1/8:AS2 via R3 (iBGP) 1/8:AS2 via R2 (iBGP) C=1 1/8:AS2 via R3 (eBGP, best) R6 R7 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS2  ASPath: AS2  NextHop: R2  NextHop: R3 C=1 C=98 R2 R0 R3 1.0.0.0/8 AS2 CNPP/2008.4. © O. Bonaventure, 2003
  • The prefer eBGP over iBGP step in the BGP decision process  Motivation : hot potato routing  A router should try to get rid of packets sent to external domains as soon as possible AS1 R6's routing table R8 1/8:AS2 via R2 (eBGP,best) C=50 R7's routing table 1/8:AS2 via R3 (iBGP) 1/8:AS2 via R2 (iBGP) C=1 1/8:AS2 via R3 (eBGP, best) R6 R7 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS2  ASPath: AS2  NextHop: R2  NextHop: R3 C=1 C=98 R2 R0 R3 Flow of IP packets towards 1.0.0.0/8 1.0.0.0/8 AS2 CNPP/2008.4. © O. Bonaventure, 2003
  • The closest nexthop step in the BGP decision process  Motivation : hot potato routing  A router should try to get rid of packets sent to external domains as soon as possible Content provider R9 sending to 1.0.0.0/8 R8's routing table 1/8:AS2 via R2 (NH=R7,best) 1/8:AS2 via R3 (NH=R6) R8 AS1 C=50 C=1 R6 R7 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS2  ASPath: AS2  NextHop: R2  NextHop: R3 C=1 C=98 R2 R0 R3 1.0.0.0/8 AS2 © O. Bonaventure, 2003 CNPP/2008.4.
  • The closest nexthop step in the BGP decision process  Motivation : hot potato routing  A router should try to get rid of packets sent to external domains as soon as possible Content provider R9 sending to 1.0.0.0/8 R8's routing table 1/8:AS2 via R2 (NH=R7,best) 1/8:AS2 via R3 (NH=R6) Flow of IP packets R8 AS1 C=50 C=1 R6 R7 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS2  ASPath: AS2  NextHop: R2  NextHop: R3 C=1 C=98 R2 R0 R3 1.0.0.0/8 AS2 © O. Bonaventure, 2003 CNPP/2008.4.
  • The lowest MED step in the BGP decision process  Motivation : cold potato routing  In a multi-connected AS, indicate which entry border router is closest to the advertised prefix  Usually MED= IGP cost Content provider R9 sending to 1.0.0.0/8 R8's routing table 1/8:AS2 via R2 (MED=1,best) 1/8:AS2 via R3 (MED=98) R8 C=50 C=1 AS1 R6 R7 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS2  ASPath: AS2  NextHop: R3  NextHop: R2 C=98 MED: 98  MED : 1 C=1  R2 R0 R3 CNPP/2008.4. 1.0.0.0/8 AS2 © O. Bonaventure, 2003
  • The lowest MED step in the BGP decision process  Motivation : cold potato routing  In a multi-connected AS, indicate which entry border router is closest to the advertised prefix  Usually MED= IGP cost Content provider R9 sending to 1.0.0.0/8 R8's routing table 1/8:AS2 via R2 (MED=1,best) Flow of IP packets 1/8:AS2 via R3 (MED=98) R8 C=50 C=1 AS1 R6 R7 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS2  ASPath: AS2  NextHop: R3  NextHop: R2 C=98 MED: 98  MED : 1 C=1  R2 R0 R3 CNPP/2008.4. 1.0.0.0/8 AS2 © O. Bonaventure, 2003
  • The lowest router id step in the BGP decision process  Motivation  A router must be able to determine one best route towards each destination prefix  A router may receive several routes with comparable attributes towards one destination AS1 R0 1.0.0.0/8 AS2 R2 R3 AS3 UPDATE UPDATE  Prefix:1.0.0.0/8  Prefix:1.0.0.0/8  ASPath: AS2:AS1 R1  ASPath: AS3:AS1  Consequence  A router with a low IP address will be preferred CNPP/2008.4. © O. Bonaventure, 2003
  • Allocation of IP addresses  How to allocate IP addresses  First solution  Objective : Ensure that IP addresses are unique  Rule used by registries  Any organisation can be allocated a unique IP subnet on a FCFS basis  Size of the allocated subnet : three classes  Class A : subnet with 8 bits mask  Class B : subnet with 16 bits mask  Class C : subnet with 24 bits mask  Drawbacks  Too rigid  Class A is too large for most networks and Class C too small  address waste !  Difficult to aggregate prefixes CNPP/2008.4. © O. Bonaventure, 2007
  • Allocation of IP addresses (2)  CIDR  Goals 1. Ensure that IP addresses are unique 2. Allow BGP routers to advertise aggregated prefixes  Rules used by registries  Only Internet Service Providers (and large companies) can obtain IP subnets  Size of allocated subnet is function of current and expected number of customers  An organisation willing to be connected to the Internet must obtain IP addresses from its ISP  Advantage  Improved aggregation of addresses  Drawback  If a company switches from one provider to another, it will need to renumber its IP network - a real pain ! CNPP/2008.4. © O. Bonaventure, 2007
  • Allocation of IP addresses (3) Class-based Routes allocation ... 130.104.0.0/16 : via R0 CIDR-based allocation 138.48.0.0/16 : via R0 139.165.0.0/16 : via R0 164.15.0.0/16 : via R0 R0 R ... ucl.ac.be R0 R 130.104.0.0/16 ucl.ac.be 180.12.0.0/16 Routes fundp.ac.be ... 180.12.0.0/14 : via R0 138.48.0.0/16 B fundp.ac.be B ... E A 180.13.0.0/16 E ulg.ac.be L N L 139.165.0.0/16 N A N Y ulg.ac.be N E N 180.14.0.0/16 E ulb.ac.be T Y 164.15.0.0/16 T E N T ulb.ac.be E 180.15.0.0/16 T CNPP/2008.4. © O. Bonaventure, 2007
  • Internet evolution  Number of Autonomous Systems CNPP/2008.4. Source : http://bgp.potaroo.net © O. Bonaventure, 2007
  • Internet evolution (2)  Size of the BGP routing tables  Number of IPv4 prefixes in default-free routers CNPP/2008.4. Source : http://bgp.potaroo.net © O. Bonaventure, 2007
  • Internet evolution (2)  Size of the BGP routing tables  Number of IPv4 prefixes in default-free routers pre-CIDR fast growth CNPP/2008.4. Source : http://bgp.potaroo.net © O. Bonaventure, 2007
  • Internet evolution (2)  Size of the BGP routing tables  Number of IPv4 prefixes in default-free routers CIDR works well pre-CIDR fast growth CNPP/2008.4. Source : http://bgp.potaroo.net © O. Bonaventure, 2007
  • Internet evolution (2)  Size of the BGP routing tables  Number of IPv4 prefixes in default-free routers CIDR works well Growth is back pre-CIDR fast growth CNPP/2008.4. Source : http://bgp.potaroo.net © O. Bonaventure, 2007
  • Internet evolution (2)  Size of the BGP routing tables  Number of IPv4 prefixes in default-free routers Internet bubble CIDR works well Growth is back pre-CIDR fast growth CNPP/2008.4. Source : http://bgp.potaroo.net © O. Bonaventure, 2007
  • Internet evolution (2)  Size of the BGP routing tables  Number of IPv4 prefixes in default-free routers Internet bubble CIDR works Growth is well back again ! Growth is back pre-CIDR fast growth CNPP/2008.4. Source : http://bgp.potaroo.net © O. Bonaventure, 2007