lunes, 9 de mayo de 2011
Frame Relay Switching
A continuación uno de los tópicos que antiguamente era considerados como una caja negra para el examen de laboratorio del CCIE® de Routing & Switching. A partir de la versión 4 de este examen, Frame-Relay Switching es un tópico que los candidatos deben manejar y saber configurar. Para el siguiente ejemplo se configura las interfaces seriales de R2 y R3 hacia R1 como se ve en la figura.
R2#sh run int s2/0
Building configuration...
Current configuration : 116 bytes
!
interface Serial2/0
ip address 192.0.2.2 255.255.255.224
encapsulation frame-relay
serial restart-delay 0
end
R3#sh run int s3/0
Building configuration...
Current configuration : 116 bytes
!
interface Serial3/0
ip address 192.0.2.3 255.255.255.224
encapsulation frame-relay
serial restart-delay 0
end
Dado que se está haciendo una configuración back-to-back Frame Relay, los circuitos se mantendrán caídos (down) hasta que o bien se deshabilite el keepalive de las interfaces o bien se configure R1 como frame relay switch como se verá a continuación.
frame switching
!
int s2/0
frame-relay intf-type dce
!
int s3/0
frame-relay intf-type dce
A esta altura obviamente no exitirá información de PVC's en los spokes ya que no se ha configurado nada aún.
R2#sh frame pvc
R2#
R3#sh frame pvc
R3#
Se configurará Frame-Relay Switching con el comando connect (Frame Relay).
R1(config)#connect R2-R3 s2/0 222 s3/0 333
Luego se podrá ver en los spokes que la información de los PVC's disponibles ha sido transmitida.
R2#sh frame pvc
PVC Statistics for interface Serial2/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 222, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0
input pkts 0 output pkts 0 in bytes 0
out bytes 0 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:00:13, last time pvc status changed 00:00:13
R3#sh frame pvc
PVC Statistics for interface Serial3/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 333, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0
input pkts 1 output pkts 1 in bytes 34
out bytes 34 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 1 out bcast bytes 34
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:00:16, last time pvc status changed 00:00:16
Pero no sólo se tendrá eso, dado que no se ha desabilitado frame-relay inverse-arp, se tendrá:
R2#sh frame map
Serial2/0 (up): ip 192.0.2.3 dlci 222(0xDE,0x34E0), dynamic,
broadcast,
CISCO, status defined, active
R3#sh frame map
Serial3/0 (up): ip 192.0.2.2 dlci 333(0x14D,0x50D0), dynamic,
broadcast,
CISCO, status defined, active
...y eso sería todo:
R2#ping 192.0.2.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/41/48 ms
Otra forma sería con el comando frame-relay route:
R1(config)#no connect R2-R3 s2/0 222 s3/0 333
R1(config)#
R1(config-if)#int s2/0
R1(config-if)#frame-relay route 222 interface s3/0 333
R1(config-if)#
R1(config-if)#int s3/0
R1(config-if)#frame-relay route 333 interface s2/0 222
R2#ping 192.0.2.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/44 ms
sábado, 14 de agosto de 2010
Frame Relay Timers
Quizás una de las tareas menos intuitivas dentro del contexto del examen de laboratorio del CCIE® de Routing & Switching sea configurar los timers de Frame-Relay. Principalmente por que los comandos no son fáciles de recordar, además que no es directo distinguir la diferencia entre éstos. A continuación se comentará brevemente los comandos disponibles extraídos de la página de soporte de Cisco, lo que se conocía antiguamente como DocCD.
Entre el router y switch Frame-Relay se correrá LMI, de este modo el router enviará, por defecto, cada 10 segundos un Status Inquire indicando que el tipo de reporte solicitado es un número de secuencia (Sequence Number Exchange), a lo que el switch responde con el mismo mensaje con el número de secuencia incrementado en 1 y así sucesivamente. Esto permite que el switch conozca el estatus del subscritor (keepalive) y viceversa. A su vez, cada 60 segundos, por defecto, el tipo de reporte solicitado será Full Status, al lo que el switch responde con el estado de los PVC, para cada uno de los DLCI configurados en el circuito.
Para modificar estos valores se utilizan los comandos especificados en: Explicitly Configuring the LMI. En particular para cambiar el intervalo en que se envían los mensajes de Status Inquire se utiliza keepalive (LMI) y para modificar el intervalo en que se se solicita un Full Status se utiliza: frame-relay lmi-n391dte.
Además se puede manipular otras variables asociadas a estos valores, pero en su mayoría aplican al lado del Switch (DCE), ver: Setting the LMI Polling and Timer Intervals.
R2(config-if)#frame-relay lmi-?
lmi-n391dte lmi-n392dce lmi-n392dte lmi-n393dce
lmi-n393dte lmi-t392dce lmi-type
Vale la pena señalar que para conexiones back-to-back Frame-Relay entre dos routers, que por ende no utilizarán LMI, será necesario deshabilitarlo con: no keepalive.
Pero si se quisiera tener un keepalive que cubriese el PVC extremo a extremo, es decir de router a router y no sólo router a switch, es necesario configurar: Frame Relay End-to-End Keepalive. Básicamente se configura un map-class Frame-Relay con map-class frame-relay, al que se le especifica la función de keepalive end-to-end con: frame-relay end-to-end keepalive mode, que variará de acuerdo a qué router hace los requerimientos y cuál responde (puede ser bi-direccional también). Luego se aplica el map-class a la interface correspondiente con frame-relay class.
R2(config)#map-class frame-relay NAME
R2(config-map-class)#frame-relay end-to-end keepalive mode ?
bidirectional Set bidirectional mode
passive-reply Set passive-reply mode
reply Set unidirectional reply mode
request Set unidirectional request mode
R2(config-if)#frame-relay class NAME
Los timers para esta funcionalidad se configuran con los comandos detallados abajo:
lunes, 19 de abril de 2010
PPP sobre Frame Relay
El RFC 1973 (PPP in Frame Relay) describe las particularidades de cómo transportar paquetes encapsulados en PPP sobre redes Frame-Relay. El método de cómo se encapsulan protocolos sobre Frame Relay es descrito en el RFC 2427 (Multiprotocol Interconnect over Frame Relay). Cisco a su vez lo describe en; PPP over Frame Relay.
Dentro del contexto del examen CCIE® de Routing & Switching, una de la aplicaciones que debe manejar es la autentificación de circuitos Frame-Relay utilizando PPP. Para esto se debe especificar un virtual template para un determinado DLCI. Ésto se hace con el comando frame-relay interface-dlci [ppp virtual-template-name], para luego configurar los parámetros dentro de interface virtual-template. Por defecto la encapsulación de un virtual template es PPP.
Como ejemplo se utilizará el esquema señalado en la figura de abajo. Para conectarse a R1 se deberá autentificar con PAP (PPP Authentication Protocol, RFC 1334) y a su vez para conectar a R2 se utilizará CHAP (Challenge Handshake Authentication Protocol, RFC 1994). Recordar que la autentificación es un proceso unidireccional en este caso.
Para comenzar simplemente se levantará PPP sobre Frame-Relay sin autentificación y luego se añadirá ésta según se especificó anteriormente.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface s0/0.12
R1(config-subif)#frame-relay interface-dlci 102 ppp virtual-template 2
R1(config-fr-dlci)#interface virtual-template 2
R1(config-if)#ip address 192.0.2.1 255.255.255.0
R1(config-if)#
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface s0/0/0.21
R2(config-subif)#frame-relay interface-dlci 201 ppp virtual-template 1
R2(config-subif)#interface virtual-template 1
R2(config-if)#ip address 192.0.2.2 255.255.255.0
R2(config-if)#
Una rápida verificación probará que todo parece estar funcionando.
R2(config-if)#do ping 192.0.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms
R2(config-if)#
A continuación se configura la autentificación. Se comenzará con PAP, ésto se especifica con el comando ppp authentication en el router que solicitará la autentificación (R1) que contrastará los datos de autentificación en este caso contra los usuarios locales configurados en el router. Con el comando username se configura uno a modo de ejemplo. El router que se autentificará (R2) utilizará los datos que se ingresar con el comando ppp pap sent-username.
R1(config)#interface virtual-template 2
R1(config-if)#ppp authentication pap
R1(config-if)#username USER password ccie.en.espanol
R1(config)#
R2(config)#interface virtual-template 1
R2(config-if)#ppp pap sent-username USER password ccie.en.espanol
R2(config-if)#
Con debug ppp authentication se puede ver el detalle del proceso de autentificación.
R1(config)#
R1(config)#do debug ppp authentication
PPP authentication debugging is on
R1(config)#int s0/0
R1(config-if)#shut
R1(config-if)#
*Mar 3 16:14:35.516: %LINK-5-CHANGED: Interface Serial0/0, changed state to administratively dow
*Mar 3 16:14:35.520: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
*Mar 3 16:14:36.516: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
*Mar 3 16:14:36.520: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
R1(config-if)#no shut
R1(config-if)#
*Mar 3 16:14:48.896: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
*Mar 3 16:14:48.900: Vi1 PPP: Using default call direction
*Mar 3 16:14:48.900: Vi1 PPP: Treating connection as a dedicated line
*Mar 3 16:14:48.900: Vi1 PPP: Session handle[EF000491] Session id[320]
*Mar 3 16:14:48.900: Vi1 PPP: Authorization required
*Mar 3 16:14:50.888: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar 3 16:14:51.888: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar 3 16:15:09.524: Vi1 PPP: Authorization required
*Mar 3 16:15:09.544: Vi1 PAP: I AUTH-REQ id 1 len 25 from "USER"
*Mar 3 16:15:09.544: Vi1 PAP: Authenticating peer USER
*Mar 3 16:15:09.544: Vi1 PPP: Sent PAP LOGIN Request
*Mar 3 16:15:09.548: Vi1 PPP: Received LOGIN Response PASS
*Mar 3 16:15:09.548: Vi1 PPP: Sent LCP AUTHOR Request
*Mar 3 16:15:09.548: Vi1 PPP: Sent IPCP AUTHOR Request
*Mar 3 16:15:09.548: Vi1 LCP: Received AAA AUTHOR Response PASS
*Mar 3 16:15:09.548: Vi1 IPCP: Received AAA AUTHOR Response PASS
*Mar 3 16:15:09.552: Vi1 PAP: O AUTH-ACK id 1 len 5
*Mar 3 16:15:09.560: Vi1 PPP: Sent IPCP AUTHOR Request
*Mar 3 16:15:10.552: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
Se puede observar la autentificación de entrada (I) y el acknowledge de salida (O). En el otro sentido ahora se configurará CHAP.
R2(config-if)#interface Virtual-Template1
R2(config-if)#ppp authentication chap
R2(config-if)#
Apr 19 08:58:58.255: Vi1 PPP: Authorization required
Apr 19 08:58:58.339: Vi1 PAP: Using hostname from interface PAP
Apr 19 08:58:58.339: Vi1 PAP: Using password from interface PAP
Apr 19 08:58:58.339: Vi1 PAP: O AUTH-REQ id 156 len 25 from "USER"
Apr 19 08:58:58.339: Vi1 CHAP: O CHALLENGE id 151 len 23 from "R2"
Apr 19 08:58:58.363: Vi1 PAP: I AUTH-ACK id 156 len 5
Apr 19 08:58:59.251: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
Como se puede apreciar se ha perdido la conexión. Para reestablecerla en R2 se debe configurar contra qué se contrastará la información de autentificación que envíe R1 (CHAP utiliza por defecto el hostname del router como usuario, por ende sólo faltaría el password).
R2(config)#username R1 password cisco
R1 a su vez puede configurar la credencial a enviar configurando el usuario R2 dado wue es el usuario por defecto a utilizar.
R1(config)#username R2 password cisco
R1(config)#
Apr 19 09:04:08.668: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
R1(config)#
O bien puede configurar el password con ppp chap password. Si se desea modificar el usuario se puede hacer con: ppp chap hostname.
R1(config)#interface Virtual-Template2
R1(config-if)#ppp chap password cisco
R1(config-if)#
Apr 19 09:07:04.924: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
R1(config-if)#
Por último notar que existen otros protocolos de autentificación como EAP (Extensible Authentication Protocol, RFC 3748).
R1(config-if)#ppp authentication ?
chap Challenge Handshake Authentication Protocol (CHAP)
eap Extensible Authentication Protocol (EAP)
ms-chap Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
ms-chap-v2 Microsoft CHAP Version 2 (MS-CHAP-V2)
pap Password Authentication Protocol (PAP)
Para EAP se debe señalar explícitamente con ppp eap local que se utilizarán los usuarios locales configurados en el router para contrastar los intentos de autentificación. A su vez en el router que se autentifica, el usuario y password a enviar se configuran con ppp eap identity y ppp eap password respectivamente.
Links de interés:
- Troubleshooting PPP (CHAP or PAP) Authentication (Cisco)
- Configuring and Troubleshooting PPP Password Authentication Protocol (PAP) (Cisco)
- Ooooo… You Want Me to Authenticate WHAT??? (Scott Morris)
- PPP Authentication Using the ppp chap hostname and ppp authentication chap callin Commands (Cisco). En particular notar; Treating connection as a callin - Treating connection as a callout vs Treating connection as a dedicated line en los ejemplos de este post.
martes, 13 de abril de 2010
Doble NAT?
Primero que nada agradecer a Narbik Kocharians y Dan Shechter por el excelente concurso de Troubleshooting que realizaron hace unas semanas (Troubleshooting Challenge lab)... Gracias a éste gané una copia de sus workbooks Advanced Routing and Switching 2.0 WB y Troubleshooting WB :) ...Ahora a trabajar en ellos para alcanzar la meta!
Bueno, uno de los Tickets que me tuvo de cabeza por un buen rato fue el número 9. Enunciaba lo siguiente:
Ticket 9
R6 can NOT ping 24.24.24.3.
You should fix this problem without configuring BGP or any redistribution.
La topología completa se puede ver en; Topología, IGP y BGP. Para la referencia de este post se utilizará la siguiente imagen:
Básicamente R5 y R1 tienen una sesión iBGP, sin embargo no es posible alcanzar los prefijos que R1 le anuncia a R5, puesto que R4 no tiene información de cómo rutear estos destinos.
Desde R5 se puede ver se reciben 6 prefijos desde R1 (136.85.1.1).
R5#sh ip bgp sum | b Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.85.1.1 4 15 21600 21447 12 0 0 2w0d 6
136.85.56.6 4 6 21452 21453 12 0 0 2w0d 0
R5#
Si en particular se revisa el prefijo 24.24.24.3/32 se verá que se conoce a través de R1 con next-hop 136.85.241.24, el que R1 resolverá recursivamente para determinar que la interface de salida es F0/0...hasta ahí, todo bien.
R5#sh ip bgp 24.24.24.3
BGP routing table entry for 24.24.24.3/32, version 11
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
24
136.85.241.24 (metric 66) from 136.85.1.1 (136.85.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R5#R5#sh ip cef 24.24.24.3
24.24.24.3/32
nexthop 136.85.45.44 FastEthernet0/0
R5#
Sin embargo cuando se intenta hacer ping al destino se obtiene un mensaje ICMP que señala que el host es desconocido (Type 3, Code 1).
R5#ping 24.24.24.3 r 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 24.24.24.3, timeout is 2 seconds:
U.
Success rate is 0 percent (0/2)
R5#
Para los que no saben el por qué se ve U.U.U en vez de UUUUU se recomienda leer: Dissecting a U.U.U ping response.
Siguiente paso sería verifican quién origina los mensajes de destino no alcanzable.
*Apr 13 17:52:49.241: IP: s=136.85.45.5 (local), d=24.24.24.3 (FastEthernet0/0), len 100, sending
*Apr 13 17:52:49.241: ICMP type=8, code=0---snip---
*Apr 13 17:52:49.245: IP: s=136.85.45.44 (FastEthernet0/0), d=136.85.45.5, len 56, input feature
*Apr 13 17:52:49.245: ICMP type=3, code=1
Como era de esperar, R4 (136.85.45.44) no sabe cómo rutear los paquetes con destino a 24.24.24.3.
R4#sh ip rou 24.24.24.3
% Network not in table
R4#
¿Qué se puede hacer en este caso?. Bueno, la respuesta enunciada en Challenge lab - Solution, sugiere que se levante LDP entre R5<>R4 y R4<>R1, lo cual por supuesto funciona.
R5#sh ip cef 24.24.24.3
24.24.24.3/32
nexthop 136.85.45.44 FastEthernet0/0 label 16
R5#R5#ping 24.24.24.3 r 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 24.24.24.24, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 56/58/60 ms
R5#
Sin embargo esto no pasó por mi mente en ese momento, si no una solución alternativa que sin embargo no es óptima puesto que sólo corrige el problema para este prefijo en particular, pero de todos modos resuelve el inconveniente enunciado y se explicará a continuación, de manera de mostrar cómo se puede usar NAT de manera extravagante. Para detalles respecto a esta tecnología se sugiere revisar alguno o todos los siguientes links:
- RFC 1631
- How NAT Works (Cisco)
- Understanding NAT address types (Jeremy Stretch)
- NAT Order of Operation (Cisco)
- The Inside and Outside of NAT (Petr Lapukhov)
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int FastEthernet0/0
R4(config-if)#ip nat out
R4(config-if)#
R4(config-if)#int Serial1/0.14
R4(config-subif)#ip nat in
R4(config-subif)#
R4(config-subif)#ip nat inside source static 136.85.134.3 24.24.24.3
R4(config)#
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int Serial1/0.14
R1(config-subif)#ip nat out
R1(config-subif)#int f0/0
R1(config-if)#ip nat in
R1(config-if)#ip nat inside source static 24.24.24.3 136.85.134.3
R1(config)#
Esto corresponde a lo que se muestra en la siguiente figura:
Entonces cuando R5 (y por ende R6 como se solicita originalmente en el Ticket) envía un paquete destinado a 24.24.24.3 llegará a la interface F0/0 de R4. Ahí se aprovechará que el proceso de NAT outside to inside se realiza previo a la decisión de ruteo según se especifica en NAT Order of Operation, entonces 24.24.24.3 se transformará en 136.85.134.3. R4 sabe cómo rutear paquetes destinados a esta dirección y por lo tanto serán enviados a través de su interface Serial1/0.14 con destino R1 (DLCI 401).
R4#sh ip rou 136.85.134.3
Routing entry for 136.85.134.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Serial1/0.14
Route metric is 0, traffic share count is 1
R4#
R4#sh frame map interface Serial1/0.14
Serial1/0.14 (up): point-to-point dlci, dlci 401(0x191,0x6410), broadcast
status defined, active
R4#
Una vez en R1, se repite el proceso de NAT para hacer la conversión inversa. Esta vez se cambia 136.85.134.3 por 24.24.24.3 por ende R1 rutea los paquetes con el destino original de 24.24.24.3 y R1 sí sabe cómo alcanzar ese host. Luego el host sólo tiene que responder los mensajes ICMP al origen de los paquetes, cuya dirección no fue modificada durante el trayecto.
R5#ping 24.24.24.3 r 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 24.24.24.3, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 56/58/60 ms
R5
:)
jueves, 30 de julio de 2009
Chequeo del origen de paquetes IP
A continuación se mostrarán el funcionamiento de uRPF (RFC 3704), el cual Cisco describe en
Understanding Unicast Reverse Path Forwarding y su configuración es detallada en Configuring Unicast Reverse Path Forwarding.
Este mecanismo corresponde a una sencilla herramienta de seguridad que chequea el origen de los paquetes IP, permitiendo descartarlos si por ejemplo el origen no es visible a nivel de la tabla de ruteo por la interface por donde se recibió el paquete, protegiendo la red de ataques que son fácilmente generables como describe Jeremy Stretch en Using uRPF at the access layer to deter DDoS attacks. Otra buena lectura es el RFC 2827; Defeating Denial of Service Attacks which employ IP Source Address Spoofing.
Se utilizará la maqueta de la figura considerando que en primera instancia el link entre R4-R5 estará configurado con la subnet 10.0.0.8/30 para luego pasar a 172.16.0.8/30. Se utilizará EIGRP como protocolo de ruteo.
