Script PERL para generar tráfico en UDP

Siempre que tenemos que probar algún firewall o alguna política de calidad de servicio nos encontramos con el problema de que necesitamos tráfico para ver si las cosas están bien configuradas, para ayudar a este proceso  les dejo un script de {es:Perl|PERL} que les va a generar tráfico en forma de datagramas UDP.



El código del mismo no es mio, sino que lo encontré en la página de  Ivan Pepelnjak y me tomé el trabajo de traducirlo.

#!/usr/bin/perl
use Socket;
use strict;

if ($#ARGV != 3) {
  print "\n$0    \n";
  print "Puerto = 0: usar puertos aleatorios\n";
  print "Tamanio = 0: usar tamanios aleatorios entre 64 y 1024\n";
  print "Duracion = 0: flood que no para nunca\n";
  print "Se deben escribir todos los parametros aunque sea en 0\n\n";
  exit(1);
}

my ($ip,$port,$size,$time) = @ARGV;
my ($iaddr,$endtime,$psize,$pport);

$iaddr = inet_aton("$ip") or die "No puedo resolver el hostname $ip\n";
$endtime = time() + ($time ? $time : 1000000);

socket(flood, PF_INET, SOCK_DGRAM, 17);

print "Floodeando $ip:" . ($port ? $port : "puerto-aleatorio") . " con " .
  ($size ? "$size bytes" : "datagramas de tamanio aleatorio")
  .
  ($time ? " por $time segundos" : "") . "\n";
print "Parar con Ctrl-C\n" unless $time;

for (;time() <= $endtime;) {
  $psize = $size ? $size : int(rand(1024-64)+64) ;
  $pport = $port ? $port : int(rand(65500))+1;
  send(flood, pack("a$psize","flood"), 0, pack_sockaddr_in($pport, $iaddr));}

Obviamente voy a recomendar usar esto sólo para actividades legales que no involucren atacar algún equipo que no sea nuestro.

Nos vemos en el próximo post.

El misterioso caso de EIGRP y la MTU

Me pasa constantemente que cuando estoy leyendo determinadas publicaciones de Cisco Press (incluso del mismo autor) aparecen contradicciones entre diversos enunciados.

Quizás la más llamativa sea la eterna pregunta de si el protocolo de ruteo EIGRP utiliza o no la MTU de las interfaces para calcular las métricas.

Veamos los materiales de referencia que se contradicen:

Libro: CCNA ICND2 Official Exam Certification Guide (CCNA Exams 640-816 and 640-802), Second Edition
Autor: Wendell Odom - CCIE No. 1624
Editorial: Cisco Press
Fecha de publicación: 30 de Agosto del 2007
ISBN-10: 1-58720-181-X
ISBN-13: 978-1-58720-181-3

Capturo un comentario del texto:

Traduzco:

"... Nota: Documentos y libros antiguos solían expresar que EIGRP, y su predecesor, IGRP, ademas podrían usar la MTU como parte de la métrica, pero la MTU no puede ser usada y nunca fue considerada como parte del cálculo. "

Vamos a otro...

Libro: CCIE Routing and Switching Exam Certification Guide, Fourth Edition
Autores: Wendell Odom - CCIE No. 1624; Rus Healy - CCIE No. 15025; Denise Donohue - CCIE No. 9566
Editorial: Cisco Press
Fecha de Publicación: 08 de Diciembre del 2009
ISBN-10: 1-58705-980-0
ISBN-13: 978-1-58705-980-3

Capturo el comentario correspondiente...

Traduzco:

"... Seteando los valores K correctos en el comando metric weights, EIGRP puede además considerar la carga de los enlaces, la confiabilidad y la MTU ..."

Como le estuve dando muchas vueltas a este tema, voy a armar un lab con equipos para sacarme la duda...

Topología del lab:

En este simple ejemplo vamos a publicar dos redes con enlaces intermedios de diferentes MTU y veremos como R1 calcula las métricas de cada una.

Configuraciones Iniciales:

R1:

hostname R1

!

interface FastEthernet0/0

 description Enlace a R2

 ip address 192.168.0.1 255.255.255.252

 bandwidth 10000

!

router eigrp 8

 metric weights 0 1 1 1 1 1

 network 192.168.0.0

 no auto-summary

 eigrp router-id 1.1.1.1

!

R2:

hostname R2

!

interface FastEthernet0/0

 description Enlace a R1

 ip address 192.168.0.2 255.255.255.252

 bandwidth 10000

!

interface FastEthernet0/1

 description Enlace a R3

 ip address 192.168.1.1 255.255.255.252

 bandwidth 10000

 ip mtu 1000

!

interface FastEthernet0/2

 description Enlace a R4

 ip address 192.168.1.5 255.255.255.252

 bandwidth 10000

!

router eigrp 8

 metric weights 0 1 1 1 1 1

 network 192.168.0.0

 network 192.168.1.0

 no auto-summary

 eigrp router-id 2.2.2.2

!

R3:

hostname R3

!

interface Loopback3

 ip address 192.168.3.1 255.255.255.0

 ip mtu 1000

!

interface FastEthernet0/0

 description Enlace a R2

 ip address 192.168.1.2 255.255.255.252

 bandwidth 10000

 ip mtu 1000

!

router eigrp 8

 metric weights 0 1 1 1 1 1

 network 192.168.1.0

 network 192.168.3.0

 no auto-summary

 eigrp router-id 3.3.3.3

!

R4:

hostname R4

!

interface Loopback3

 ip address 192.168.4.1 255.255.255.0

!

interface FastEthernet0/0

 description Enlace a R2

 ip address 192.168.1.6 255.255.255.252

 bandwidth 10000

!

router eigrp 8

 metric weights 0 1 1 1 1 1

 network 192.168.1.0

 network 192.168.4.0

 no auto-summary

 eigrp router-id 4.4.4.4

!

Ahora vamos a analizar la tabla de ruteo de R1:

R1#show ip route eigrp 

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      192.168.1.0/30 is subnetted, 2 subnets

D        192.168.1.0 [90/1203] via 192.168.0.2, 00:00:15, FastEthernet0/0

D        192.168.1.4 [90/1203] via 192.168.0.2, 00:00:15, FastEthernet0/0

D     192.168.3.0/24 [90/1703] via 192.168.0.2, 00:00:15, FastEthernet0/0

D     192.168.4.0/24 [90/1703] via 192.168.0.2, 00:00:15, FastEthernet0/0

Hasta ahora las rutas tienen las mismas métricas a pesar del cambio de MTU, vamos a ver las entradas de cada red en la tabla de topología:

R1#sh ip eigrp topology 192.168.3.0

EIGRP-IPv4 Topology Entry for AS(8)/ID(1.1.1.1) for 192.168.3.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1703

  Descriptor Blocks:

  192.168.0.2 (FastEthernet0/0), from 192.168.0.2, Send flag is 0x0

      Composite metric is (1703/1603), route is Internal

      Vector metric:

        Minimum bandwidth is 10000 Kbit

        Total delay is 7000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1000

        Hop count is 2

        Originating router is 3.3.3.3

R1#show ip eigrp topology 192.168.4.0

EIGRP-IPv4 Topology Entry for AS(8)/ID(1.1.1.1) for 192.168.4.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1703

  Descriptor Blocks:

  192.168.0.2 (FastEthernet0/0), from 192.168.0.2, Send flag is 0x0

      Composite metric is (1703/1603), route is Internal

      Vector metric:

        Minimum bandwidth is 10000 Kbit

        Total delay is 7000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 2

        Originating router is 4.4.4.4

Evidentemente y a pesar que con el metric weights obligamos a que EIGRP calcule todas las variables posibles, el MTU  de los enlaces no interviene en el cálculo de la métrica.

Algunos tips de BGP

Algoritmo de selección de la mejor ruta

1. Weight (Atributo propietario de Cisco, Default 32768 para rutas originadas localmente, más alto,mejor).
2. Local Preference (Default 100, más alto, mejor).
3. Preferir Rutas Locales (originadas con network o redistribute sobre las agregadas con aggregate-address).
4. AS-PATH (Más corto, mejor).
5. Origen IGP sobre origen EGP sobre origen Incomplete (IGP es cuando se publican con comando network, Incomplete por redistribución).
6. MED Elegir el camino con menor Multi Exit Discriminator (Default 0, como toda métrica, menor es mejor).
7. Preferir eBGP sobre iBGP
8. Preferir menor métrica del IGP al nexthop BGP
9. Ruta más vieja Si las rutas son externas, elegir la que se recibió primero (la más estable).
10. Menor router-id de BGP
11. Menor IP de neighbor

¿Por qué no aparecen las rutas en la tabla?

• Las rutas están marcadas como no sincronizadas en la salida del comando show ip bgp longer-prefixes.

Si la sincronización está habilitada, debe existir un prefijo exacto en la tabla de rutas para que un path iBGP sea considerado válido. Dicha
sincronización está habilitada por defecto en Cisco IOS®. Si la ruta es aprendida desde un neighbor OSPF, el OSPF router ID debe ser el mismo
que el router-id de BGP del neighbor iBGP. Se puede desactivar con el comando:

no synchronization

 Synchronization está deshabilitado por default en los release 12.2(8)T de Cisco IOS y posteriores.

• Las rutas tienen un NEXT_HOP inaccesible.

Recordar que es deseable tener una ruta estática como /32 hacia el NEXT_HOP que publica el neighbor.

• Rutas son publicadas por un neighbor eBGP en donde el AS local figura en el AS-PATH. (Prevención de loops).
• Si está habilitado bgp enforce-first-as y el UPDATE no contiene el AS del neighbor como el primer AS en la AS_SEQUENCE.
• El neighbor utiliza iBGP y no va a enviarme las rutas que aprenda por iBGP desde otro neighbor. Ver iBGP reflectors.

Configuración básica de un neighbor

Es deseable que los vecinos tengan estas configuraciones mínimas:

!El AS del lado remoto debe estar definido.

 neighbor 1.2.3.4 remote-as 65530

!No negociar version hace que el peer levante más rápido.

 neighbor 1.2.3.4 version 4

!Dar una amplia descripción del peering, que sea lo más completa posible.

 neighbor 1.2.3.4 description #Empresa# - #Sitio# - #TelefonoDelSoporte# - #NroDeEnlace# - #PersonaResponsable#

!Hacer el peering contra un aloopback siempre que sea posible.

 neighbor 1.2.3.4 update-source Loopback0

!Habilitar multihop para sesiones eBGP si es que usamos una loopback.

 neighbor 1.2.3.4 ebgp-multihop 10

!Autenticar el peering.

 neighbor 1.2.3.4 password 53kr3TMuyD1f1C1L

!Guardar una copia de los updates recibidos por si queremos actualizar los filtros sin bajar el peer.

 neighbor 1.2.3.4 soft-reconfiguration inbound

!Limitar la cantidad de prefijos aceptados por el peer. Avisar cuando llegue al 90%.

 neighbor 1.2.3.4 maximum-prefix 100 90

!Activar el neighbor en el AFI si es que tenemos configurado no bgp default ipv4-unicast

 neighbor 1.2.3.4 activate

Cosas que deberíamos tener en cuenta:

• Habilitar Non StopForwarding.
• No deben llegar nuestros prefijos por eBGP, ni aunque sean más específicos.
• Hay más de 300.000 rutas en la tabla mundial, tratá de publicar prefijos grandes (/24 como máximo).
• No publicar bogons ni IP’s privadas (rfc1918).
• Las AS-PATH Access List son tus amigas, usalas.
• Las communities son amigas de las AS-PATH ACL, por ende también son tus amigas, usalas.
• Está bueno modificar la distancia administrativa de eBGP para que sea peor que tu IGP.
• Es preferible usar un ADVERTISE-MAP antes que inundar el mundo con AS-PATH prepends.
• Siempre usar bgp dampening.
• El resto del mundo va a usar dampening sobre vos!!!.
• Aplicar communities a la entrada para identificar rutas de cada proveedor.
• Un route-map con description vale más que mil comandos show.
• No redistribuir nunca BGP en IGP.
• No redistribuir nunca IGP en BGP.
• Si inevitablemente se redistribuye IGP en BGP, hacer un route-map con filtrado adecuado y set origin igp.
• Siempre usar límites de largo de AS-PATH.

¿En qué orden se aplican los filtros en IOS?

El orden de preferencia varía de acuerdo a los atributos que son aplicados para updates entrantes o salientes.

Para updates entrantes:

1. route-map
2. filter-list
3. prefix-list, distribute-list

Para updates salientes:

1. prefix-list, distribute-list
2. filter-list
3. route-map

Los prefix-list y distribute-list son mutualmente excluyentes, y solo un comando (neighbor prefix-list o neighbor distribute-list) puede ser aplicado en cada dirección entrante o saliente para un neighbor en particular.

Obviamente, en lo posible usar route-map dado que es una herramienta más poderosa.

Acerca de los prefix-list:

Un ACL normal no puede chequear la máscara de una red. Solamente puede chequear bits para asegurar una coincidencia, nada más.
Un prefix-list tiene la ventaja sobre un ACL, puede chequear ambas cosas: bits y máscara de red; Ambos deben coincidir paraque la red sea permitida o denegada.
Si existe únicamente un / despues de la red (no hay le o ge) entonces se chequea la máscara de red y el número que sigue a la /.

ip prefix-list test permit 192.168.1.0/24

Entonces en este caso se van a chequear los 24 bits de izquierda a derecha (no importan los últimos 8) Y también se va a chequear que la máscara de red sea de 24 bits. Ambas cosas deben ser ciertas para que se permita la red.
Ahora bien, podemos ser permisivos en cuanto a la máscara de red:

ip prefix-list test permit 192.168.1.0/24 ge 25

Si usamos el le o ge (o ambos) después de la /, entonces vamos a chequear los 24 bits de la red de izquierda a derecha. Si eso coincide entonces matcheamos la máscara de red, que en este caso puede ser mayor o igual que 25 bits.

Mientras los primeros 24 bits de la red coincidan bit a bit,

la máscara puede ser /25, /26, /27, /28,/29, /30, /31, o /32.

En el ejemplo:

ip prefix-list test permit 192.168.1.0/24 le 28

Si los primeros 24 bits coinciden bit a bit, la máscara debe ser menor o igual a 28, pero a partir del /24 definido.

Mientras los primeros 24 bits de la red coincidan bit a bit,

la máscara puede ser /24, /25, /26, /27 o /28.

ip prefix-list test permit 192.168.1.0/24 ge 25 le 28

Obviamente nos da que deben coincidir los primeros 24 bits de la red 192.168.1.0 con una máscara de /25, /26, /27 o /28.

Guardar running-config en un servidor externo

Muchas veces tenemos la necesidad de hacer una copia de la configuración para guardarla en un lugar seguro.

En este breve ejemplo vamos a aprovechar algunos features del IOS 12.3 para:

1. Al momento de grabar la configuración, que se copie automáticamente en un servidor externo.
2. Que se guarde la configuración todos los días a una hora en particular.

Dado que esto es un tip como para -copiar y pegar- voy directamente al grano:

Para guardar una copia de la config en un servidor FTP al momneto de hacer copy running-config startup-config pegamos los siguientes comandos en el modo de configuración global (conf t):

archive

path ftp://usuario:password@ftp.server.com/$h-$t

write-memory

Las variables $h y $t representan el hostname y la hora, por ejemplo quedarían archivos llamados

Router-Mar--4-00:05:40.732-UTC

Ahora vamos a hacer que la config y sus respectivos backups se graben todos los dias a las 00:05:

kron occurrence daily-config-backup at 0:05 recurring

policy-list backup-config

!

kron policy-list backup-config

cli write memory

!

Espero que les sea de utilidad.