1. ESCENARIO DE PRUEBAS CISCO ASR1002
El escenario que se ha planteado para la realización de las pruebas es el del apartado 1.1 con los elementos, componentes y características del apartado 1.2. En este escenario se ha intentado simular cual sería el comportamiento del Cisco ASR1002 como Edge router con full BGP con 4 peers.
1.1. Esquemas de Red
1.1.1. Esquema lógico
El siguiente esquema representa el esquema lógico del escenario a simular. En él se aprecia como el router Cisco ASR1002 va a ser el equipo de interconexión entre 4 proveedores de servidos (ISP) y el AS propio
1.1.2. Esquema de red
El siguiente esquema representa los elementos que conforman el escenario para llevar a cabo la simulación y las pruebas sobre el router Cisco ASR1002.
1.2. Elementos que componen el escenario de pruebas
1.2.1. Router Edge Cisco ASR1002
El Cisco Router ASR1002 es el actor principal del siguiente informe. El router ASR1002 es un equipo del fabricante
Cisco del cual existen 2 versiones.
– ASR1002-F (fixed)
– ASR1002.
El equipo que va a ser objeto de análisis es el ASR1002. En la siguiente tabla se indican las principales características del ASR1002 y ASR1002-F donde se pueden observar las diferencias entre uno y otro.
¿Qué función tienen cada uno de los elementos que componen el Router Cisco ASR1000?
– Route Processor: Es el componente encargado de administrar el sistema, ejecutar la IOS y gestionar el plano de control, como por ejemplo serían los protocolos de routing, sesiones SIP, etc. Existen 2 modelos de RP para la serie ASR1000 de Cisco. La RP1 y la RP2. La RP1 viene integrada en los ASR1002 y dispone de 4GB de memoria DRAM. Por otra parte, la RP2 soporta hasta 16GB de memoria y está disponible para los modelos superiores de la serie ASR1000
– ESP: Es la tarjeta encargada de gestionar el tráfico. La RP se encarga de calcular y construir
la tabla de forwarding. Una vez construida se la transfiere a la ESP y esta se encarga de todo el envío de tráfico, la manipulación de los paquetes en caso de ser necesario y la encriptación de los paquetes. Los distintos modelos de ESP son capaces de gestionar velocidades que van desde los 2.5Gbps a 100Gbps. Los equipos ASR1002-F disponen de la ESP integrada y gestionan un tráfico máximo de 2.5Gbps. En cambio, los ASR1002 disponen de 2 modelos que van desde los 5Gbps a los 10Gbps
– SIP: Las tarjetas SIP son los carriers de las SPAs, o dicho de otra forma donde se conectarían
las tarjetas SPAs. En los modelos ASR1002 y ASR1002-F esta tarjeta viene integrada en el chasis y por tanto no se puede ampliar. La capacidad de throughput para estos modelos es de 10Gbps.
– SPAs: Las tarjetas SPAs se encargan de ofrecer una gran variedad de interfaces y conexiones para un extenso número de tecnologías y accesos.
Las características exactas del equipo que se ha utilizado para realizar este documento son las siguientes:
– ASR1002 (SIP10, RP1 integradas en el chasis)
– ESP5
– IOS: asr1000rp1-adventerprisek9.03.10.03.S.153-3.S3-ext.bin
1.2.2. Cisco Catalyst 3750G Switch
El Cisco Catalyst 3750G en el escenario planteado tiene la función de simular una red MAN de acceso de nivel 2 ya que todos los vecinos del BGP van a estar en la misma red y no va a ser necesario que se realice ningún tipo de enrutamiento. En un entorno real aparecerían una serie de conceptos que quedan fuera del alcance de este documento como serian VPLS, VRF, etc.
El equipo exacto que ha utilizado para la simulación y pruebas es:
1.2.3. Host ESXi
El host ESXi es el sistema operativo, desarrollado por VMware, encargado de gestionar las máquinas virtuales donde estarán instalados los Ubuntu server que a su vez serán los encargados de simular los peers BGP con full BGP.
El ESXi está instalado sobre un servidor HP Proliant 160 G5. Las características principales del servidor y el host ESXi son las siguientes:
– HP Proliant G5
– 32GB RAM
– 400GB de disco duro SAS en RAID 5
– Versión del ESXi (VM)
Nota: La instalación del SO ESXi, así como de las máquinas virtuales quedan fuera del alcance de este documento.
1.2.4. PC Windows 7
El PC con Windows 7 va a tener las funciones de generar y recibir tráfico con Iperf versión 3. De esta forma se podrá comprobar la reacción del equipo ASR1002 ante un aumento y si afecta a los peers de BGP o a su rendimiento en general
1.2.5. Servidor físico Ubuntu Server
El último elemento del escenario es un servidor físico HP Proliant DL360 G6 con el sistema operativo Ubuntu server instalado. Este equipo va a ser el encargado al igual que el PC Windows 7 de generar y recibir tráfico para comprobar la reacción del Cisco ASR1002 ante un aumento de tráfico. Las características principales del servidor son:
– HP Proliant 360 G6
– 16GB RAM
– Disco duro de 76GB SAS
– SO Ubuntu Server 16.04
2. DESARROLLO DE LAS PRUEBAS CISCO ASR1002
En los siguientes apartados se van a ir desarrollando las configuraciones y consideraciones necesarias para simular el escenario de pruebas
2.1. Consideraciones previas
2.1.1. Plan de direccionamiento
Para llevar a cabo las pruebas el plan de direccionamiento es el siguiente:
– Red de interconexión entre los ISPs y el ISP propio: 10.90.0.0/16
– Red Interna del ISP propio: 10.42.0.0/16
2.1.1.1. Red de Interconexión
La red de interconexión como se ha comentado en un apartado anterior simula una red MAN de nivel 2. La conexión entre los vecinos BGP de los ISPs y el ISP propio se va a realizar a través de esta red. La asignación de AS e IPs son las siguientes:
2.1.1.2. Red Interna
La red interna va a ser la red que va a conectar el Windows 7 con el ASR1002 para que el tráfico pase a través del ASR1002 y se compruebe que efectos tiene sobre él
2.1.2. Full Routing BGP
2.1.2.1. ¿Qué es?
El protocolo BGP (Border Gateway Protocol) en su definición más básica es el protocolo de routing utilizado entre los sistemas autónomos (AS) para intercambiar información de enrutamiento.
Full routing hacer referencia al intercambio total de todas las redes (prefijos) que circulan por internet entre los distintos sistemas autónomos. La importancia del full routing aparece cuando un ISP está conectado a más de un ISP. De esta forma si cada ISP al que se encuentra conectado le proporciona toda la tabla de rutas de internet (full routing) conocerá porque camino le conviene ir para llegar a una determina red.
2.1.2.2. Tamaño actual
A la fecha de realización de este informe la tabla de rutas de internet tiene un tamaño de 650000 rutas IPv4 y 40000 IPv6 (Las rutas ipv6 quedan fuera de este informe). Este dato es importante ya que es el valor que vamos a simular entre los ISPs representados por las VMs Linux y el ASR1002.
2.1.3. Cisco ASR1002 Router
2.1.3.1. Características técnicas del Cisco ASR1002 Router
En el apartado 1.2.1 ya se han analizado algunas de las características técnicas del ASR1002. En este caso nos centraremos en la RP1 que viene integrada en el equipo. Las capacidades de la RP1 van a determinar las limitaciones del Cisco ASR1002 para el full routing y van a ser el objeto de análisis de este informe.
Si hacemos referencia al data sheet que nos proporciona Cisco para la RP1 indica lo siguiente:
– The Cisco ASR 1002 chassis comes with the Cisco ASR 1000 Series RP1 built into the chassis
– Scalability up to 1,000,000 IPv4 routes or 500,000 IPv6 routes
– BGP RR Scalability up to 5,000,000 IPv4 routes or 3,000,000 IPv6 routes
– Cisco ASR1002 Router: Comes with 4-GB DRAM (default and maximum)
Con estos datos y teniendo en cuenta el valor actual de la tabla de rutas de internet el ASR1002 debe ser capaz de soportar teóricamente el escenario propuesto
2.2. Configuraciones Router Cisco ASR1002
2.2.1. Cisco ASR1002 Router
El primer equipo que vamos a configurar de nuestro escenario de pruebas es el equipo motivo de análisis. Queda fuera del alcance de este documento las configuraciones de seguridad e iniciales del equipo. Nos centraremos única y exclusivamente en las configuraciones ip y BGP.
2.2.1.1. Configuración IP
El Cisco ASR1002 dispone de 4 puertos fijos SFP. Para la realización de las pruebas se han instalado 2 sfps
GLC-T de la marca ARPERS.
Para configurar el interfaz hacia la WAN (ISPs) realizaremos los siguientes pasos
config t
int gi0/0/0
ip adddress 10.90.50.55 255.255.0.0
no shut
Para configurar el interfaz hacia la red interna realizaremos los siguientes pasos
config t
int gi0/0/0
ip adddress 10.42.0.2 255.255.0.0
no shut
2.2.1.2. Configuración BGP
En la configuración del BGP realizaremos una configuración básica sin realizar filtrado de rutas, ni modificando ninguno de los atributos (MED, AS_PATH, etc.)
La configuración para conseguir la adyacencia con los peers BGP es la siguiente:
config t
router bgp 65000
bgp router-id 10.90.50.54
bgp log-neighbor-changes
neighbor 10.90.50.50 remote-as 65001
neighbor 10.90.50.50 description BGP1
neighbor 10.90.50.51 remote-as 65002
neighbor 10.90.50.51 description BGP2
neighbor 10.90.50.52 remote-as 65003
neighbor 10.90.50.52 description BGP3
neighbor 10.90.50.53 remote-as 65004
neighbor 10.90.50.53 description BGP4
Para publicar hacia los peers la red interna se deben realizar las siguientes modificaciones
config t
router bgp 65000
network 10.42.0.0 netmask 255.255.0.0
redistribute connected
Con estas configuraciones ya tendríamos el 50% de la configuración realizada. Nos faltaría por realizar la configuración en los peers BGP sobre las máquinas virtuales del host ESXi.
2.2.2. Máquinas virtuales BGP
Las máquinas virtuales del servidor ESXi son 4 servidores con el sistema operativo de Ubuntu server
14.04. Las 4 máquinas virtuales son equipos clónicos con la lógica diferencia de ips y sistemas autónomos.
Para realizar la configuración del BGP en Linux se va a hacer uso del paquete Quagga.
2.2.2.1. ¿Qué es Quagga?
Haciendo un uso literal de la definición de la Wikipedia:
“Quagga es una suite de software libre para poder usar la familia de sistemas operativos Unix como routers. El mismo provee implementaciones de protocolos como Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Border Gateway Protocol (BGP), and IS-IS. Está diseñado especialmente para NetBSD, FreeBSD, Solaris y Linux.
Actúa como conmutador del GNU Zebra, el cual a su vez es un demonio que se encarga de manejar las tablas de rutas del núcleo. Algunas de sus funciones están mejor adaptadas a Linux, es decir, lo maneja completamente como el demonio conmutador que es. En el caso de los BSDs, hay unas cuantas funciones que no maneja, es decir, no puede aprovechar las bendiciones del mismo.”
2.2.2.2. Instalación y puesta en marcha de Quagga
Para instalar quagga únicamente deberemos ejecutar el siguiente comando con privilegios de root desde un terminal
apt-get install quagga
Una vez finalizada la instalación se activarán los demonios necesarios para que funcione el bgp. Se va a editar el siguiente archivo daemons y se van a modificar los valores tal y como se muestra a continuación:
nano /etc/quagga/daemons
zebra=yes
bgp=yes
2.2.2.3. Configuración del BGP en Quagga
Para configurar el BGP en los distintos servidores se va a configurar un archivo llamado bgpd.conf que
se ubicará en el directorio donde se ha instalado quagga. Normalmente esta ubicación es /etc/quagga.
El contenido del archivo bgpd.conf debe tener un aspecto parecido a esto:
hostname quagga-host
password zebra
enable password zebra
line vty
router bgp 65099
bgp router-id 192.0.2.1
neighbor 192.0.2.2 remote-as 65001
network 70.0.0.0/24
network 70.0.1.0/24
network 70.0.2.0/24
network 70.0.3.0/24
¿Qué ocurre si se quieren configurar 650000 rutas?
Existen varias posibilidades como por ejemplo escribir de forma manual una a una las 650000 rutas con lo que solo se puede decir…suerte. O existe otra posibilidad más viable que es mediante un script. En este caso hemos se ha utilizado como base el script desarrollado por V. Glinsky y cuyo enlace al script es este de aquí
Las modificaciones y pasos para ejecutar el script y generar el archivo bgpd.conf son los siguientes:
– Crear un archivo por ejemplo sudo nano script.pl y copiar el siguiente contenido:
#!/usr/bin/perl
my $host=»quagga-host»; #quagga router name
my $logpass=»zebra»; #login password
my $enable=»zebra»; #enable password
my $myasn=»65001″; #local AS number
my $router_id=»10.90.50.50″; #bgp router-id
my $remote_as=»65000″; #remote-as number
my $remote_ip=»10.90.50.54″; #BGP neighbor ip address
my $route_count=0;
my $max_routes=650000; #max number of routers to generate
open (BGPCONF,’>bgpd.conf’)|| die «Can not open bgpd.conf for writing»;
print BGPCONF «hostname $host\npassword $logpass\nenable password $enable\nline vty \n»;
print BGPCONF «router bgp $myasn\n bgp router-id $router_id\n neighbor $remote_ip remote- as $remote_as\n»;
MAXR: while ($route_count <= $max_routes ) {
$octet1=int(rand(223))+1; #generate 1st octet randomly in 1-223 range, 224 and up is multicust and class E
if ($octet1 ==127) {next;} #need to make sure that 127.X.X.0/24 is excluded
$octet2=0;
while ( $octet2 <= 255 ){
$octet3=0;
while ( $octet3 <= 255 ) {
print BGPCONF » network $octet1\.$octet2\.$octet3\.0/24\n»;
$octet3++;
$route_count++;
if ($route_count == $max_routes) {last MAXR;}
}
$octet2++;
}
}
close BGPCONF;
Los campos y parámetros que debemos adaptar a nuestro escenario son los siguientes
my $router_id=»10.90.50.50″; #bgp router-id
my $remote_as=»65000″; #remote-as number
my $remote_ip=»10.90.50.54″; #BGP neighbor ip address
my $max_routes=650000; #max number of routers to generate
my $myasn=»65001″; #local AS number
En este caso tenemos la configuración para generar el archivo bgpd.conf para el ISP1
– Una vez creado el archivo y guardado el archivo hay que cambiarle los permisos al archivo para permitir la ejecución del script:
sudo chmod +x script.pl
– Ejecutar el script:
sudo ./script.pl
– Ahora se habrá creado un archive bgpd.conf que hay que copiar al directorio /etc/quagga
sudo cp bgpd.conf /etc/quagga/bgp.conf
– Y por último faltaría reiniciar el servicio quagga para que aplique la configuración:
sudo /etc/init.d quagga restart
Si la configuración ha sido correcta se habrá creado la primera adyacencia entre el ASR1002 y la máquina virtual BGP1
Para configurar el resto de adyacencias la configuración en el resto de máquinas va a ser idéntica modificando los parámetros de cada conexión con la excepción de la ejecución del script, que no deberíamos ejecutar en todas las máquinas virtuales
NOTA: Es muy importante que el archivo bgpd.conf contenga las mismas 650000 rutas ya que si no es así puede generar un resultado incorrecto ya que no estaríamos simulando una red con full routing BGP. Es recomendable usar el archivo generado en la primera máquina virtual y copiarlo al resto de máquinas modificando los parámetros del AS propio y el ID BGP.
2.2.3. Resto de configuraciones
2.2.3.1. Otros
Los otros elementos que forman parte del escenario planteado tienen una configuración básica.
Al equipo Windows 7 solo hay que cambiarle la IP. El Cisco Switch 3750 funcionaria con una configuración básica por defecto sin modificar ya que todos los puertos están en acceso
2.3. Comprobaciones
2.3.1. Conectividad IP
Una vez realizada la configuración de los equipos hay que comprobar la conectividad IP entre los distintos equipos. Lanzaremos ping entre los equipos y comprobaremos que si el resultado es correcto. Si alguno de los test no es correcto debe seguirse alguna de las estrategias para determinar dónde está el problema. Una buena estrategia puede ser seguir la capa OSI de abajo a arriba. Empezamos por el nivel físico o nivel 1 hasta llegar a la capa de red o nivel 3.
2.3.2. Conectividad BGP
Tras realizar las comprobaciones de conectividad ip el siguiente paso es revisar el correcto funcionamiento del protocolo BGP. Hay que confirmar las adyacencias entre los vecinos ISP1, ISP2, ISP3 e ISP4 se han realizado correctamente con el ISP Propio. Para comprobarlo se pueden ejecutar los siguientes comandos:
Router#sh ip bgp sum
BGP router identifier 10.90.50.54, local AS number 65000
BGP table version is 1189875, main routing table version 1189875
650000 network entries using 93600000 bytes of memory
2600000 path entries using 208000000 bytes of memory
4/1 BGP path/bestpath attribute entries using 608 bytes of memory
4 BGP AS-PATH entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 301600704 total bytes of memory
BGP activity 919937/269937 prefixes, 2869937/269937 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.90.50.50 4 65001 2779 3006 10842822 0 0 1d12h 650000
10.90.50.51 4 65002 2779 3011 10842822 0 0 1d12h 650000
10.90.50.52 4 65003 2778 3004 10842822 0 0 1d12h 650000
10.90.50.53 4 65004 2778 3009 10842822 0 0 1d12h 650000
En rojo aparece el tiempo que el que la conexión esta activa o inactiva. ¿Cómo conocer si la conexión esta activa o inactiva? Por el valor del campo en azul State/PfxRcd. Si en este campo aparece valores numéricos significa que estamos recibiendo rutas de nuestro vecino. Si por el contrario aparecen estados como Active, Init, OpenSent puede significar que la vecindad no se ha creado todavía o que la adyacencia ha caído. En el ejemplo se puede observar como las 4 vecindades se han creado de forma correcta.
Otra información útil que puede obtenerse con este comando es el número total de redes que se conocen y la cantidad de memoria que están ocupando (texto en verde)
Otro dato importante que se ve con este comando es el número total de caminos que se reciben de los vecinos BGP. En este caso 650000 x 4 = 26000000 (texto en naranja). De los cuales se eligen los
650000 mejores que pasan a la tabla de rutas y que coincide con el valor anterior.
2.3.3. Uso de recursos del equipo Cisco ASR1002 (Memoria CPU)
Es importante mantener un control sobre los recursos del equipo y su uso. El ASR1002 dispone de un comando donde se puede el uso de la memoria de cada uno de los componentes del equipo (RP, ESP, SIP)
Router# show platform software status control-processor brief
Load Average
Slot Status 1-Min 5-Min 15-Min
RP0 Healthy 0.24 0.13 0.09
ESP0 Healthy 0.00 0.00 0.00
SIP0 Healthy 0.00 0.00 0.00
Memory (kB)
Slot Status Total Used (Pct) Free (Pct) Committed (Pct)
RP0 Healthy 3874504 3332588 (86%) 541916 (14%) 2656136 (69%)
ESP0 Healthy 969088 874224 (90%) 94864 (10%) 74350 (77%)
SIP0 Healthy 471832 265728 (56%) 206104 (44%) 234544 (50%)
CPU Utilization
Slot CPU User System Nice Idle IRQ SIRQ IOwait
RP0 0 2.60 2.10 0.00 95.19 0.00 0.10 0.00
ESP0 0 5.79 14.98 0.00 79.22 0.00 0.00 0.00
SIP0 0 1.49 0.79 0.00 97.70 0.00 0.00 0.00
Con este comando se puede observar en primer lugar la carga media de cada uno de los componentes en intervalos de 1,5 y 15 minutos. Hay que destacar de estos primeros valores que si el valor es inferior a 1 el equipo está funcionando correctamente. Si el valor es 1 o superior indica que se ha tenido que esperar para tener acceso a la CPU por lo que puede estar mostrando problemas de sobrecarga.
Después aparece el uso de la memoria de cada uno de los elementos por lo que da una idea de su utilización y espacio libre.
Y por último aparece que uso de la CPU realiza cada uno de los componentes del Cisco ASR1002 Router.
MercadoitIT dispone de amplia gama de routers de marca Cisco, incluido el ASR1002.
