Routers 1

Tema 2: Internetworking Protocol (IP) 37 Tema 2: Internetworking Protocol (IP) 38
Tabla de Encaminamiento A
A
N1 R4 N10
N1 R4 N10 N3
N9
B
N3 B R1
N9 N4 N6N7
R1 N7 N2
N4 N6 ? R5
N2 N8
? R5 N5
N8 R3
N5 R2 ?
R2 R3
? Para poder tomar esta decisión, cada
Router construye una tabla de
Cada uno de los routers de la red encaminamiento:
debe tomar una decisión: ¿Por dónde
se debe encaminar los paquetes IP para
poder comunicar A con B? Tabla encaminamiento de R2:
Ejemplo: R1 decide encaminar los paq. Para ir hasta ...el mejor camino es
por R2. R2 debe ahora tomar la ... seguir por...
siguiente decisión: ¿Encamino el paquete
por R4 o por R3?. N1 R1
N6 R3
Debemos minimizar un coste (ejemplo: N3 R4
número de hops, retardo medio, etc) N8 R3
N5 local
... ...
STD, Jorge García Vidal STD, Jorge García Vidal
[root@galatzo jorge]# netstat -rn

Kernel IP routing table
Destination Gateway Genmask Flags Iface
..... ..... .....

147.83.35.0 0.0.0.0 255.255.255.0 U eth0
127.0.0.0 0.0.0.0 255.0.0.0 U lo
default 147.83.35.2 0.0.0.0 UG eth0
[root@galatzo jorge]#
147.83.35.2 (default router) ..... .....

Internet Algoritmos de
encaminamiento
.....
galatzo.ac.upc.es exteriores (EGP: BGP4)
.....
..... Sistema Autónomo (AS)
147.83.35.0/24 (número de AS)
..... .....
147.83.35.3 147.83.36.0/24

.....
147.83.35.0 0.0.0.0 255.255.255.0 U eth0
127.0.0.0
0.0.0.0
0.0.0.0
147.83.35.2
255.0.0.0
0.0.0.0
U lo
UG eth0
[root@galatzo jorge]# route add -net 147.83.36.0 gw 147.83.35.3
.....
netmask 255.255.255.0 eth0
147.83.35.0 0.0.0.0 255.255.255.0 U eth0
147.83.36.0 147.83.35.3 255.255.255.0 UG eth0
127.0.0.0 0.0.0.0 255.0.0.0 U lo host: 147.83.37.133/26
0.0.0.0 147.83.35.2 0.0.0.0 UG eth0 Algoritmos de
[root@galatzo jorge]# route del -net 147.83.36.0 gw 147.83.35.3
netmask 255.255.255.0 eth0 encaminamiento
interiores (IGP: RIP, OSPF, IGRP)
Encaminamiento estático Encaminamiento dinámico distribuido:

RIP (Vector de Distancias)
A
A
Tabla
Tabla N1 R4 N10
Encaminamiento
N1
n1
R4 N10
Encaminamiento
N3
n1
n2... B
N3
n2... B N9
N9 R1
R1 N4 N6N7
N4 N6N7 N2
N2 ? R5
? R5 N8
N8 Tabla
Encaminamiento N5 Tabla
Tabla N5 R3
Encaminamiento Tabla
R3 n1 R2 Encaminamiento
?
n1
n2...
R2 Encaminamiento
?
n2... n1
n2...
n1
n2...
Cada router intercambia con los routers

VECINOS de forma periódica información
Los gestores de la internet construyen sobre el coste de comunicación a TODAS
las tablas de encaminamiento las subredes de la red. (ej: cada 30 s)
para cada Router
A partir de la información recibida,
Sencillo, pero lejos del comportamiento cada router actualiza sus tablas de
óptimo y necesidad de mantener encaminamiento
muchas tablas
Algoritmo de Bellman-Ford distribuido
=> Internets pequeñas y sencillas
Ejemplo: N2
N1
Dij (n) = mink ( Dij(n-1), dik+Dkj(n-1))
R1 N3
R4 Tabla de R1 Tabla de R2 Tabla de R3 Tabla de R4
R3
Red Dist. Red Dist. Red Dist. Red Dist.
N4 R2 N5 N1 1 (local) N4 1 (local) N3 1 (local) N2 1 (local)
N3 1 (local) N5 1 (local) N5 1 (local) N3 1 (local)
Tabla de R1 Tabla de R2 Tabla de R3 Tabla de R4 N5 2 (R3) N3 2 (R3) N1 2 (R1) N1 2 (R1)
Red Dist. Red Dist. Red Dist. Red Dist. N2 2 (R4) N2 2 (R4) N5 2 (R3)
N1 1 (local) N4 1 (local) N3 1 (local) N2 1 (local) N4 2 (R2)
N2
N1
N2
N1 R1 N3
Ejemplo: R1 envía en R4
broadcast su tabla de N3 R3
R1 R4
costes por N1 y por N3 R3 N4 R2 N5
N4 R2 N5
Tabla de R1 Tabla de R2 Tabla de R3 Tabla de R4

N1 1 (local) N4 1 (local) N3 1 (local) N2 1 (local) N3 1 (local) N5 1 (local) N5 1 (local) N3 1 (local)
N3 1 (local) N5 1 (local) N5 1 (local) N3 1 (local) N5 2 (R3) N3 2 (R3) N1 2 (R1) N1 2 (R1)
N5 2 (R3) N3 2 (R3) N1 2 (R1) N1 2 (R1) N2 2 (R4) N1 3 (R3) N2 2 (R4) N5 2 (R3)
N2 2 (R4) N2 2 (R4) N5 2 (R3) N4 3 (R3) N2 3 (R3) N4 2 (R2) N4 3 (R3)
N4 2 (R2)
Nota: Si la distancia en la tabla es más pequeña que
la anunciada por el router por donde encaminamos,
se actualiza en la tabla con la nueva distancia.

Detalles del funcionamiento de RIP Cuenta a infinito

Cuando R1 Cada 30 s. los routers se N2
intercambian mensajes de enca-
N1
N2 empieza a ejecutar minamiento. Si el enlace entre N3
N1 RIP, envía un R2 y R3 queda roto ...
R1 R4
broadcast en R3
R1 N3
R4 el que pide que N4 R2 N5
R3
los demás routers Tabla de R1 Tabla de R2 Tabla de R3 Tabla de R4
N4 R2 N5 le envíen sus tablas Red Dist. Red Dist. Red Dist. Red Dist.
de costes. N1 1 (local) N4 1 (local) N3 1 (local) N2 1 (local)
Los demás routers contestan con N5 2 (R3) N3 2 (R3) N1 2 (R1) N1 2 (R1)
N2 2 (R4) N1 3 (R3) N2 2 (R4) N5 2 (R3)
mensajes dirigidos a R1. N4 3 (R3) N2 3 (R3) N4 2 (R2) N4 3 (R3)
A partir de ese momento, cada 30 seg.

R1 enviará en broadcast su tabla de N2
costes por los interfaces por los que N1
R3 no recibe noticias de
hayamos activado RIP R1 N3 R2, sin embargo recibe
R4
R3 una tabla de coste de R4
en la que se dice que R4
N4 R2 N5 sabe ir a N4 en 3 saltos...
¿Qué pasa si un router pierde la conexión
a una red?. Los demás routers dejarán Tabla de R1 Tabla de R2 Tabla de R3 Tabla de R4
de recibir mensajes de dicho router. Al Red Dist. Red Dist. Red Dist. Red Dist.
cabo de un cierto tiempo eliminarán las N1 1 (local) N4 1 (local) N3 1 (local) N2 1 (local)
rutas que han aprendido de dicho router N3 2 (local) N5 inf (-) N5 1 (local) N3 1 (local)
(6x30 s = 180 s). N5 2 (R3) N3 inf (-) N1 2 (R1) N1 2 (R1)
N2 2 (R4) N1 inf (-) N2 2 (R4) N5 2 (R3)
N4 3 (R3) N2 inf (-) N4 4 (R4) N4 3 (R3)
Cuenta a infinito
Tabla de R1 N2
Tabla de R2 Tabla de R3 Tabla de R4 N1
Red Dist. Red Dist. Red Dist. Red Dist. N3
R1 R4
R3
N5 2 (R3) N3 2 (R3) N1 2 (R1) N1 2 (R1) N4 R2 N5
N2 2 (R4) N1 3 (R3) N2 2 (R4) N5 2 (R3)
N4 3 (R3) N2 3 (R3) N4 4 (R4) N4 3 (R3)
¡Las distancias de R1, R3 y R4 a N4 irán

creciendo de forma indefinida !
N2 Se forman bucles entre R1 y R3 y entre
N1 R4 y R3.
A continuación R4 y R1
R1 N3 reciben la tabla de costes
R4
R3 de R3 en la que dice que
sabe ir hasta N4 en 4
N4 R2 N5 saltos... En RIP (y en general en cualquier protocolo
de vector de distancias) se debe fijar un
valor de distancia (ej: 16) como “infinito” de
forma que si se alcanza dicho valor se
Red Dist. Red Dist. Red Dist. Red Dist. considera que se ha cortado el camino
N1 1 (local) N4 1 (local) N3 1 (local) N2 1 (local) entre el router y la red
N3 2 (local) N5 inf (-) N5 1 (local) N3 1 (local)
N5 2 (R3) N3 inf (-) N1 2 (R1) N1 2 (R1)
N2 2 (R4) N1 inf (-) N2 2 (R4) N5 2 (R3) Esto limita el diámetro máximo de la red.
N4 5 (R3) N2 inf (-) N4 4 (R4) N4 5 (R3)

Notar que las “malas noticias” viajan

Cómo aliviar estos problemas: de forma lenta (se detectan cuando
durante varios mensajes no vemos la
“Split Horizon” ruta)
Si un router ha aprendido una ruta
por un cierto interface, cuando “Poison reverse”
envían su tabla de costes por dicho Si R3 detecta que su antigua ruta a N4
interfaz, no incluyen esa ruta en el a través de R2 ya no es válida, envía un
mensaje. mensaje por sus otros interfaces en los
que indica un coste a N4 infinito. De esa
N1,2 forma R1 y R4 tardan menos en saber que
N4,3 la ruta a N4 por R3 ya no es válida
N2 N5,2
N1 N3,1
R1 N3
R4
R3
N4 R2 N5 N2,1 “Triggered Updates”
Si un router ha cambiado su tabla, no
espera 30 s. a enviársela a sus vecinos,
sino que envía los cambios de manera
Por lo tanto por cada interfaz enviaremos (casi) inmediata.
en general una tabla de costes
distinta
RIP: Fue inicialmente implementado en Encaminamiento dinámico distribuido:

el código de BSD (programa routed) OSPF, (Estado del enlace, “Link State”)
A
Formato de los mensajes (UDP puerto 520 orig/dest)
comando versión 0 0
Tabla
familia de direcciones 0 0 N1 R4 N10
Encaminamiento
n1
dirección IP N3n2... B
0 N9
R1
0 N4 N6N7
N2
métrica ? R5
N8
dirección IP Tabla N5 Tabla
Encaminamiento
0 R2 R3
Encaminamiento
0
n1
n2... ? n1
n2...
métrica
etc...
Cada router intercambia con TODOS los
routers información sobre el coste de
Comando: Request (1)/Response (2) a cada subred VECINA cuando se pro-
Versión: (1)
Familia de direcciones: IP (2) duce un cambio.
Las respuestas se envían en broadcast cada 30 s. o A partir de la información recibida,

cada vez que debamos cambiar la tabla de routing. cada router actualiza sus tablas de
encaminamiento .
Utiliza “Split horizon” (opcionalmente con “poison
reverse”) y “triggered updates”.
“Link State Database”
Al no pasar máscaras de red, no podemos distinguir
un host de una subred salvo que usemos en toda la
red la misma máscara (Classfull routing protocol). Algoritmo de Djikstra

N2
Ejemplo: N1
“Flooding”
R1 N3
R4
R3
N4 R2 N5
La técnica de flooding se emplea para
enviar desde un cierto router de la red
N3 1 (local) N5 1 (local) N5 1 (local) N3 1 (local) información al resto de routers de la red.
El router que origina el flooding envia

la info. a cada uno de los vecinos.
Cada router envía las redes a las que se
conecta directamente al resto de routers El resto de routers reenvía esta informa-
de la red... ción a todos sus vecinos (exceptuando
el vecino que le ha enviado dicha info.)
Tabla de R1 Tabla de R2 Tabla de R3 Tabla de R4 Si un router recibe una misma información
Red Dist. Red Dist. Red Dist. Red Dist. de forma repetida, no la reenvía
N5 2 (R3) N3 2 (R3) N1 2 (R1) N1 2 (R1)
N2 2 (R4) N1 3 (R3) N2 2 (R4) N5 2 (R3)
N4 3 (R3) N2 3 (R3) N4 2 (R2) N4 3 (R3)
Ejemplo: R2 envía una información al resto de routers Classless InterDomain Routing (CIDR)
R4 R5 Problemas:
Envía la información a
R1 los routers vecinos
Las direcciones de clase B están agotadas
R3
R2
Las tablas de encaminamiento de los

routers se hacen muy grandes
R4 R5
R1,R4 y R3 envían la
R1 información recibida a
R3
sus routers vecinos, excepto Solución=>
R2 a R2 que es el routerque
les ha enviado la info.
Asignar varios net-id de clase C contíguos
a una única red (“Supernetting”)
El flooding ha acabado:
Los routers R1,R4 y R3 Para simplificar el proceso de encamina-
ya han enviado una vez la miento, los net-id se asignan en bloques
R4 R5 información, por lo que
no lo vuelven a hacer. El a los ISPs siguiendo criterios geográficos
R1
router R5 recibe la info. por (ejemplo, RIPE, en Europa.
R3 dos enlaces. Escoje uno
R2 de los dos mensajes, y
como no tiene vecinos
que no le hayan enviado
algo, no la reenvía.

BGP-4 (Border Gateway Protocol)

192.170.3.0/24
192.171.0.0/16
Permite que los N1 N2
192.170.4.0/24 routers conozcan
..... rutas que deben atravesar AS1
varios SAs (es decir N3
171.1.0.0/16 es un EGP)
192.171.0.0/16 -> e1
192.170.3.0/24 -> e1 11.0.0.0/8 .....
192.170.4.0/24 -> e1
11.0.0.0/8 -> e2 192.170.17.0/24 router exterior ..... N4
171.1.0.0./16 -> e2
192.170.17.0/24 -> e2
N5 IBGP
..... ..... AS2
N6 .....
192.171.0.0/16 -> e1
171.0.0.0/10 -> e2 ..... .....
192.171.3.0/24
AS3
192.171.0.0/16 N8 ..... N7
192.171.4.0/24
..... Los AS tienen asignado .....AS4
un número único, ASN (1..65535).
171.0.32.0/20 El rango 64512...65535 es de uso privado
171.0.0.0/10
Los routers exteriores se intercambian
171.0.2.0/24 informacion sobre las redes que son
accesibles, y de ahí construyen
sus tablas de encaminamiento.
BGP-4 BGP-4
Stub AS: Una única

conexión al resto de N2 Redes accesibles: N2
ASs N1 N1
N1,N2,N3, AS1
AS1 AS1
Transit AS: Varias N3 N3
Redes accesibles:
conexiones. Dispuesto N1,N2,N3, AS2,AS1 .....
a que haya tráfico de ..... N4,N5, AS2
tránsito ..... N4 N7, AS2, AS4 ..... N4
N8, N6, AS2,AS4,AS3
N5 IBGP N5 IBGP
..... .....
N6 ..... ..... ..... AS2 N6 .....
AS2
..... ..... ..... .....

AS3 AS3
N8 ..... N7 N8 ..... N7
.....AS4 .....AS4
Multihomed AS: Varias
conexiones. NO dispuesto a que
haya tráfico de tránsito

N1 N2
AS1
N3
BGP se ejecuta entre routers de
diferentes ASs (EBGP) .....
o entre routers del
mismo AS (IBGP). ..... N4
Los routers que se
intercambian mensajes N1 N2 N5 IBGP
BGP son BGP peers. ..... ..... AS2
AS1 N6 .....
..... .....
N3
AS3
EBGP ..... N8 ..... N7
IBGP
..... N4
.....AS4
N5 IBGP
..... .....
En BPG podemos
N6 ..... AS2 tomar decisiones de routing llamadas
..... ..... “policy-based routing”. Por ejemplo,
AS3 puede decidir que para ir a N4
AS3 no puede pasar por AS4, pero que para
N8 ..... N7 ir a N1, N2 y N3 debe pasar por AS4
.....AS4
Las decisiones de
routing se toman a N1 N2
Si todos los routers del AS ejecutan
partir de atributos IBGP (ej: ISP), no se necesita
presentes en la infomación AS1
ningun mecanismo adicional para
de encaminamiento que N3 que los routers del AS actualicen
se intercambian los routers adecuadamente las tablas de routing.
BGP peers .....
Si no todos los routers del AS
..... N4 ejecutan IBGP (ej: AS conectado a
N5 IBGP varios ISPs), de debe utilizar el
IGP para actualizar adecuadamente
..... ..... AS2
N6 ..... las tablas de routing (ej: OSPF). Debido
..... al tamaño de las tablas de routing
..... se debe usar filtrado para evitar que
AS3 las tablas de routing sean excesivamente
N8 ..... N7 elevadas.
.....AS4 Si un AS tiene una única conexión al

Dos atributos importantes son el exterior, o si su política de encamina-
“next-hop router” y “AS-path”. El miento coincide con la de sus ISP
“next-hop router” da la @IP del router (i.e. me da igual por donde encaminen
del AS a través del cual llegamos al. el tráfico), mejor NO usar BGP.
destino. El “AS-path” da la lista de ASs
para llegar al destino.
Al ir propagando las rutas, modificamos
estos atributos.

Se han definido varios tipos de mensajes

Internet Control Message Protocol (ICMP) ICMP. Por ejemplo:
Es un protocolo que se utiliza Tipo Código Descripción

conjuntamente con IP para señalizar
mensajes de error y otras condiciones 0 0 Echo reply (ping)
que necesitan atención.
3 0 Network unreachable
Los mensajes ICMP se transmiten 3 1 Host unreachable
dentro de datagramas IP 3 2 Protocol unreachable
3 3 Port unreachable
3 4 Frag. needed but D flag set
Cabecera IP (20)
5 0 Redirect for network
Tipo (1) 8 0 Echo reply (ping)
Código(1)
11 0 TTL =0 during transit
Checksum (2) (traceroute)
Contenido Hay unas normas que se deben seguir

al generar paquetes ICMP. Por ejemplo,
un paquete ICMP de error no puede
generar otro paquete ICMP de error
(ej: network unreachable)
ping Network/host/protocol/port unreachable
Enviamos paquetes ICMP “Echo B

request”. El host destino nos debe A R1 R2
responder con paquetes ICMP “Echo
reply”. ..... .....
Se utiliza para comprobar que existe
conectividad entre dos máquinas
Network unreachable:
[root@galatzo jorge]# ping -v beco.ac.upc.es R1 no sabe cómo
PING beco.ac.upc.es (147.83.35.81): 56 data bytes
64 bytes from 147.83.35.81: icmp_seq=0 ttl=255 time=0.5 ms encaminar el mensaje
64 bytes from 147.83.35.81: icmp_seq=1 ttl=255 time=0.5 ms
64 bytes from 147.83.35.81: icmp_seq=5 ttl=255 time=0.5
64 bytes from 147.83.35.81: icmp_seq=6 ttl=255 time=0.5
ms
ms
Host unreachable: No podemos
--- beco.ac.upc.es ping statistics ---
localizar al host dentro de su
7 packets transmitted, 7 packets received, 0% packet loss subred
round-trip min/avg/max = 0.5/0.5/0.5 ms
Podemos estimar el tiempo de tránsito Protocol o port unreachable: El host

(de ida y vuelta) y la tasa de errores no da soporte al protocolo especi-
del camino entre los dos hosts ficado o no tiene abierto el puerto
especificado. (El caso puerto solo UDP)

traceroute
Nos permite saber por qué routers se
126 bytes from galatzo.ac.upc.es (147.83.35.80): Destination Host Unreachable

está llevando a cabo una comunicación
0 0000 40 01 658d 147.83.35.80 147.83.35.222
0 0000 40 01 618d 147.83.35.80 147.83.35.222
0 0000 40 01 5d8d 147.83.35.80 147.83.35.222
0 0000 40 01 598d 147.83.35.80 147.83.35.222
0 0000 40 01 558d 147.83.35.80 147.83.35.222
0 0000 40 01 518d 147.83.35.80 147.83.35.222

Dst Data
Dst Data
Dst Data
Dst Data
Dst Data
Dst Data
TTL (Time To Live) : Cada vez que
un datagrama IP atraviesa un router
se decrementa en 1. Si algún router
recibe TTL=1, se destruye el datagrama y se
Src
Src
Src
Src
Src
Src
envía un paquete ICMP “TTL=0 during
PING 147.83.35.222 (147.83.35.222): 56 data bytes
transit”.
[root@galatzo jorge]# ping -v 147.83.35.222
ID Flg off TTL Pro cks
21 packets transmitted, 0 packets received, 100% packet loss ICMP

--- 147.83.35.222 ping statistics ---
A R1
TTL=1 R2 B
..... .....
4 5 00 5400 6f7f
4 5 00 5400 737f
4 5 00 5400 777f
4 5 00 5400 7b7f
4 5 00 5400 7f7f
4 5 00 5400 837f
Vr HL TOS Len
Vr HL TOS Len
Vr HL TOS Len
Vr HL TOS Len
Vr HL TOS Len
Vr HL TOS Len
TTL=2
.....
TTL=3
Ejemplos
La idea de traceroute es enviar paquetes
con TTL=1, TTL=2, etc, de forma que
[root@galatzo jorge]# traceroute beco.ac.upc.es
los routers intermedios nos envían traceroute to beco.ac.upc.es (147.83.35.81), 30 hops max, 40
paquetes ICMP y podemos identificarlos. byte packets
1 beco (147.83.35.81) 0.486 ms 0.439 ms 0.434 ms
El paquete enviado es un paquete UDP

destinado a un port cogido al hazar, de
forma que el host final nos envía un beco (147.83.35.81)
pquete ICMP “port unreachable”
.....
galatzo(147.83.35.80)
B
A R1 R2 [root@galatzo jorge]# traceroute www.telefonica.es
traceroute to www.telefonica.es (194.224.55.24), 30 hops max, 40
..... ..... byte packets
1 arenys5 (147.83.35.2) 0.776 ms 0.725 ms 0.702 ms

2 phanella.upc.es (147.83.124.128) 2.518 ms 1.660 ms 1.729 ms
3 termcat.cesca.es (193.145.223.9) 3.684 ms 1.148 ms 1.102 ms
4 193.145.223.222 (193.145.223.222) 1.688 ms 1.884 ms 1.684 ms
5 A0-1-1.EB-Madrid00.red.rediris.es (130.206.224.1) 18.652 ms
10.909 ms 18.035 ms
IP (TTL=1); UDP 6 Ibernet-ATM.red.rediris.es (130.206.224.78) 110.227 ms
130.694 ms 113.900 ms
7 194.179.16.66 (194.179.16.66) 91.714 ms 92.894 ms 85.993 ms
8 esifw1.tsai.es (194.224.52.4) 86.608 ms * 147.899 ms
9 esi2.esi.tsai.es (194.224.55.2) 125.511 ms * *
IP (TTL=2); UDP
IP (TTL=3); UDP

¿Qué sucede (probablemente...)?
.....
[root@galatzo jorge]# traceroute www.cisco.com
traceroute to cio-sys.cisco.com (192.31.7.130), 30 hops max, 40 byte
galatzo(147.83.35.80)
packets
1 arenys5 (147.83.35.2) 0.768 ms 0.684 ms 0.698 ms

147.83/16 (upc.es)
4 193.145.223.222 (193.145.223.222) 2.435 ms 3.178 ms 1.793 ms ..... 193.145.223/24 (cesca.es)
11.974 ms 15.546 ms
6 A6-0-0-1.EB-Madrid0.red.rediris.es (130.206.224.74) 17.334 ms
..... .....
26.908 ms 28.304 ms
7 194.69.226.13 (194.69.226.13) 261.393 ms 262.017 ms 258.488 ms
8 194.69.227.37 (194.69.227.37) 251.191 ms 262.695 ms 260.127 ms
9 borderx2-hssi3-0.PompanoBeach.cw.net (204.70.92.121) 532.621 ms 130.206/24 (rediris.es).....
519.488 ms 529.751 ms
10 * * core1-fddi-1.PompanoBeach.cw.net (204.70.92.33) 543.744 ms
11 204.70.12.2 (204.70.12.2) 537.980 ms * *
12 * 204.70.12.1 (204.70.12.1) 512.827 ms 572.145 ms .....
13 ast-bbn1-nap.Atlanta.cw.net (204.70.10.170) 545.150 ms 531.534 .....
ms 539.311 ms
14 h10-1-0.paloalto-br2.bbnplanet.net (4.0.1.197) 695.972 ms
? .....
628.130 ms *
15 * * p2-0.paloalto-nbr2.bbnplanet.net (4.0.2.197) 645.123 ms
16 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) 694.410 ms * *
17 * h1-0.cisco.bbnplanet.net (4.1.142.238) 716.981 ms 620.717 ms
.....
18 * pigpen.cisco.com (192.31.7.9) 687.278 ms * c&w
19 cio-sys.cisco.com (192.31.7.130) 630.708 ms 678.356 ms *
.....
.....
bbn
.....
.....
cisco.com
MTU path discovery
B
A R1 R2
[root@galatzo jorge]# traceroute www.uba.ar
traceroute to www.uba.ar (157.92.4.11), 30 hops max, 40 byte packets ..... .....
1 arenys5 (147.83.35.2) 0.739 ms 0.705 ms 0.701 ms
4 193.145.223.222 (193.145.223.222) 1.650 ms 1.855 ms 2.214 ms
14.926 ms 14.323 ms mtu = 1500 mtu = 530 mtu = 1500
6 A6-0-0-1.EB-Madrid0.red.rediris.es (130.206.224.74) 18.541 ms
15.293 ms 15.461 ms
7 194.69.226.13 (194.69.226.13) 258.023 ms * 248.069 ms Path mtu = 530
8 * * 194.69.226.22 (194.69.226.22) 464.025 ms
9 ciba-coorporativa-ciba.telintar.net.ar (200.10.128.149) 503.934
ms 496.356 ms 492.120 ms
10 ciba-riu-riu.telintar.net.ar (200.10.128.58) 459.074 ms
507.796 ms 474.519 ms Flag D=1; Long=1500
11 rnorte-rsur-512.riu.edu.ar (170.210.0.189) 849.309 ms 864.833
ms 849.845 ms
12 170.210.0.214 (170.210.0.214) 795.604 ms * 871.436 ms ICMP “Frag. needed but
13 * * ccc1-riunorte.riu.edu.ar (170.210.0.194) 861.823 ms
14 * * *
D flag set”; MTU=530
15 sunsite.uba.ar (157.92.4.10) 859.702 ms 887.138 ms *
Flag D=1; Long = 530
Si el paquete ICMP indica MTU=0,

debemos probar con una long. más
pequeña hasta que no se generen
más paquetes ICMP.

IPv6
Formato de la cabecera IPv6
Principales diferencias con IPv4:
ver Prio flow-label
Payload length Next header Hop limit

Las direcciones son de 128 bits (!)
Las opciones se envían en

cabeceras que se colocan entre la
cabecera IP y las cabeceras de los source IP address
protocolos de transporte
Capacidad de asignación automática

de direcciones. Direcciones “link
local”, “global scope”, etc.
Concepto de flujo (“flow”), lo que destination IP address

permite tener un servicio intermedio
entre orientado a la conexión y no
orientado a la conexión (soporte a
conexiones en tiempo real)
Incorpora mecanismos de seguridad

(IPsec) que también se pueden usar
en IPv4 (AH, ESP, ISAKMP/Oakley).
Domain Name System (DNS) Los nombres de las hosts se organizan

de forma jerárquica
Para los usuarios de las aplicaciones
de Internet, es mucho más cómodo
recordar nombres que recordar
direcciones IP:
www.fib.upc.es ...
org com edu uk es it
147.83.41.11
upc upv
lsi ac
El DNS permite que una aplicación Especial:

pueda de forma sencilla obtener galatzo beco
.arpa
la dirección IP de una máquina a
partir del nombre de una máquina Dominios genéricos:
.com, .gov, .int, .mil, .net, .org
Dominios por paises o regionales:
.es, .uk, .fr, .it, .us, .tv (Islas Tuvalu), ...
Nuevos dominios: .firm, .biz, .name, .pro

.coop, .aero, .museum (Nov 2000)

DNS es una base de datos distribuida

El ICANN es responsable de asegurar que permite realizar el mapeo entre
que los nombres de las máquinas el nombre de una máquina y su
sean únicos. dirección IP.
Para los dominios genéricos (.com, Cuando una aplicación quiere
.org, .net) se delega la responsabilidad realizar este mapeo, utiliza la llamada
en Accredited-Registrars, que procesan a sistema gethostbyname(). Esta
el registro del nombre en Internet y llamada al sistema consulta el
envían la info. necesaria al Internet archivo etc/host. Si no puede
Domain Name Registry, que es el que resolver el mapeo, utiliza DNS
se encarga de mantener la base de para preguntar dicho mapeo a un
datos de un TLD. servidor de DNS.
host A host B
Para los dominios regionales (.es, .uk, .....
etc) se delega a organismos oficiales
de cada país (ejemplo: es-nic). .....
nombre
@IP
Por ejemplo, alquilar un dominio que servidor de nombres
cuelga de un dominio genérico cuesta
en torno a 40 Euros al año, mientras La @ip del servidor de nombres está
que un dominio que cuelga del en /etc/resolv.conf
dominio .es cuesta en torno a los
100 Euros al año.
Evidentemente, el número de posibles

nombres es tan grande, que no puede ¿Quién administra el servidor de DNS?
administrarse de forma centralizada ni
tampoco puede haber un único servidor
hostA.std.com
host A
.....
ISP
zona: subárbol que se
administra separadamente servidor de nombres
servidor web, (www.std.com)
servidor email. (@std.com)
El administrador de una zona es Usuario

hostA.std.com residencial
responsable de mantener un servidor hostA.std.isp.com
de nombres primario y uno o más ppp
servidores de nombres secundarios host A
(back-up) .....
Cuando da de alta a nuevo host en ISP
una zona, el administrador debe aña-
dir la información correspondiente Red de std sl
(nombre, @IP) al servidor de nombres.
Cada cierto tiempo (ej: 3 h), los servidor de nombres
servidores secundarios contactan con servidor web, (www.std.com, www.std.isp.com)
el primario y le piden la nueva info. servidor email (@std.com, @isp.com)
(“zone transfer”).
Tipos de RR
DNS es una BD distribuida. La
BD está organizada en registros A (AAAA en IPv6)
llamados “Resource Records”. La
información guardada en un RR
contiene, entre otras cosas, la www.fib.upc.es -> 147.83.41.11
@IP de un host junto con su nombre.
CNAME (Nombre canonico)
Nombre es un string Nombre
que ident. el dominio. www.std.com -> PC23.std.com
tipo
Tipo identifica el clase
tipo de RR (ej: A : @IP, TTL MX
CNAME: nombre canó- long. RD std.com -> PC2.std.com
nico para un alias, etc)
RData Si enviamos un email a pepe@std.com,
Clase: IN (Internet) nos referimos al mailbox pepe en el
servidor PC2.std.com
TTL: Segundos que debemos
mantener el RR en una cache PTR
RData: Datos del registro (ej: @IP 147.83.41.11-> www.fib.upc.es
para un reg. de tipo A, nombre
canónico para un reg. de tipo CNAME,
etc).
Query recursiva Query iterativa

“root name server” “root name server”
(nota: normalmente n.s n.s
no aceptará la 3 .es .es
query 4
recursiva) Internet 6 Internet
2 2 5
4 3
7 5
6
n.s n.s
8 upc.es 8 7 upc.es
1 1
ftp.upc.es ftp.upc.es
1.- El host A pregunta a su n.s por ftp.upc.es 1.- Pregunta a nuestro n.s por ftp.upc.es
2.- El n.s. pregunta a un “root n.s” 2.- El n.s. pregunta a un “root n.s”
3.- El “root ns” pregunta al ns de la zona .es 3.- El “root n.s” nos indica la @ip de n.s de
4.- El ns de .es pregunta al ns de upc.es... la zona .es
5,6,7,8: La respuesta vuelve 4.- Nuestro ns pregunta al ns de .es
5.- El ns de .es le contesta con la @ip del
ns de .upc.es
En 5,6,7 y 8 la respuesta se guarda en las 6.- Preguntamos a dicho n.s.
caches durante TTL secs. 7,8.- El n.s. nos da la respuesta final...
y guarda en una cache las @ip de los
ns durante el tiempo indicado por TTL.

beco%> nslookup QUESTIONS:

Default Server: gaudi.ac.upc.es www.ecma.ch, type = A, class = IN
Address: 147.83.32.3 ANSWERS:
-> www.ecma.ch
> set d2 type = CNAME, class = IN, dlen = 18
> www.ecma.ch canonical name = internet.ecma.ch
Server: gaudi.ac.upc.es ttl = 84527 (84527)
Address: 147.83.32.3 -> internet.ecma.ch
type = A, class = IN, dlen = 4
;; res_mkquery(0, www.ecma.ch, 1, 1) internet address = 194.38.172.229
------------ ttl = 84527 (84527)
SendRequest(), len 29 AUTHORITY RECORDS:
HEADER: -> ecma.ch
opcode = QUERY, id = 47661, rcode = NOERROR type = NS, class = IN, dlen = 23
header flags: query, want recursion nameserver = cardassian.deckpoint.ch
questions = 1, answers = 0, authority records = 0, ttl = 41327 (41327)
additional = 0 -> ecma.ch
type = NS, class = IN, dlen = 7
QUESTIONS: nameserver = narn.deckpoint.ch
www.ecma.ch, type = A, class = IN ttl = 41327 (41327)
ADDITIONAL RECORDS:
------------ -> cardassian.deckpoint.ch
------------ type = A, class = IN, dlen = 4
Got answer (161 bytes): internet address = 194.38.160.129
HEADER: ttl = 41327 (41327)
opcode = QUERY, id = 47661, rcode = NOERROR -> narn.deckpoint.ch
header flags: response, want recursion, recursion avail. type = A, class = IN, dlen = 4
questions = 1, answers = 2, authority records = 2, internet address = 194.38.160.133
additional = 2 ttl = 84526 (84526)
Tema 2: Internetworking Protocol (IP) 91
Resoluciones inversas
Permiten obtener el nombre de un host

a partir de su dirección IP.
Nueva zona a partir de in-addr.arpa
Ejemplo:
32.83.147.in-addr.arpa
Tiene un NS que (por ejemplo) es el
mismo que el NS del dominio ac.upc.es
Si hacemos una query de
3.32.83.147.in-addr.arpa
Nos contestará dicho NS con el nombre del
host cuya dirección IP es 147.83.32.3
NOTA:
Dominios - +
Direcciones IP + -
STD, Jorge García Vidal

Routers 1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Routers 1

Cargado por

Copyright:

Formatos disponibles

Tema 2: Internetworking Protocol (IP) 37 Tema 2: Internetworking Protocol (IP) 38

Tema 2: Internetworking Protocol (IP) 39 Tema 2: Internetworking Protocol (IP) 40

[root@galatzo jorge]# netstat -rn

..... ..... .....

147.83.35.2 (default router) ..... .....

[root@galatzo jorge]# netstat -rn

Encaminamiento estático Encaminamiento dinámico distribuido:

Cada router intercambia con los routers

STD, Jorge García Vidal STD, Jorge García Vidal

Tema 2: Internetworking Protocol (IP) 43 Tema 2: Internetworking Protocol (IP) 44

Tabla de R1 Tabla de R2 Tabla de R3 Tabla de R4

STD, Jorge García Vidal STD, Jorge García Vidal

Detalles del funcionamiento de RIP Cuenta a infinito

A partir de ese momento, cada 30 seg.

STD, Jorge García Vidal STD, Jorge García Vidal

Tema 2: Internetworking Protocol (IP) 47 Tema 2: Internetworking Protocol (IP) 48

¡Las distancias de R1, R3 y R4 a N4 irán

STD, Jorge García Vidal STD, Jorge García Vidal

Notar que las “malas noticias” viajan

STD, Jorge García Vidal STD, Jorge García Vidal

Tema 2: Internetworking Protocol (IP) 51 Tema 2: Internetworking Protocol (IP) 52

RIP: Fue inicialmente implementado en Encaminamiento dinámico distribuido:

Las respuestas se envían en broadcast cada 30 s. o A partir de la información recibida,

STD, Jorge García Vidal STD, Jorge García Vidal

El router que origina el flooding envia

STD, Jorge García Vidal STD, Jorge García Vidal

Tema 2: Internetworking Protocol (IP) 55 Tema 2: Internetworking Protocol (IP) 56

Las tablas de encaminamiento de los

STD, Jorge García Vidal STD, Jorge García Vidal

BGP-4 (Border Gateway Protocol)

Tema 2: Internetworking Protocol (IP) 59 Tema 2: Internetworking Protocol (IP) 60

Stub AS: Una única

..... ..... ..... .....

STD, Jorge García Vidal STD, Jorge García Vidal

Tema 2: Internetworking Protocol (IP) 63 Tema 2: Internetworking Protocol (IP) 64

.....AS4 Si un AS tiene una única conexión al

STD, Jorge García Vidal STD, Jorge García Vidal

Se han definido varios tipos de mensajes

Es un protocolo que se utiliza Tipo Código Descripción

Contenido Hay unas normas que se deben seguir

STD, Jorge García Vidal STD, Jorge García Vidal

Tema 2: Internetworking Protocol (IP) 67 Tema 2: Internetworking Protocol (IP) 68

ping Network/host/protocol/port unreachable

Enviamos paquetes ICMP “Echo B

Podemos estimar el tiempo de tránsito Protocol o port unreachable: El host

STD, Jorge García Vidal STD, Jorge García Vidal

126 bytes from galatzo.ac.upc.es (147.83.35.80): Destination Host Unreachable

126 bytes from galatzo.ac.upc.es (147.83.35.80): Destination Host Unreachable

126 bytes from galatzo.ac.upc.es (147.83.35.80): Destination Host Unreachable

126 bytes from galatzo.ac.upc.es (147.83.35.80): Destination Host Unreachable

126 bytes from galatzo.ac.upc.es (147.83.35.80): Destination Host Unreachable

0 0000 40 01 618d 147.83.35.80 147.83.35.222

0 0000 40 01 5d8d 147.83.35.80 147.83.35.222

0 0000 40 01 598d 147.83.35.80 147.83.35.222

0 0000 40 01 558d 147.83.35.80 147.83.35.222

0 0000 40 01 518d 147.83.35.80 147.83.35.222

ID Flg off TTL Pro cks

ID Flg off TTL Pro cks

ID Flg off TTL Pro cks

ID Flg off TTL Pro cks

ID Flg off TTL Pro cks

ID Flg off TTL Pro cks

21 packets transmitted, 0 packets received, 100% packet loss ICMP