Comando oculto en Cisco. Deshabilitar negociacion de capacidad BGP

neighbor x.x.x.x dont-capability-negotiate

More info:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/116189-problemsolution-technology-00.html

IoT Cybersecurity

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 2/2)

En este segundo video se muestra como manipular Quagga para que tome decisiones en base al estado del prefijo RPKI. Continuacion de: https://blog.acostasite.com/2015/05/demostracion-de-secuestro-de-prefijos.html

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 1/2)

El video muestra un ejemplo de como ocurre un secuestro de un prefijo de red en Internet y a su vez muestra como RPKI ayudaría a prevenir esta situación

Solucion a: quagga vtysh " Exiting: failed to connect to any daemons."

Situacion:

  Al ejecutar el comando vtysh en el shell de linux para conectarse a los demonios de quagga (bgpd, ospfd, etc) da el siguiente error "Exiting: failed to connect to any daemons"

alejandro@miserver:~$ vtysh -d bgpd

Exiting: failed to connect to any daemons.

alejandro@miserver:~$ vtysh 

Exiting: failed to connect to any daemons.

Solucion:

  La solución es agregar al usuario con el que ejecutas vtysh al grupo quagga, para ello edita el archivo /etc/group.

  La linea en /etc/group debe quedar algo asi:

quagga:x:1003:alejandro

puedes especificar varios haciendo:

quagga:x:1003:alejandro, john

  Lo anterior es necesario porque la conexión a los demonios de quagga los realiza con UNIX domain socket y no todos los usuarios tienen acceso a dichos sockets.

Otra solución:

  Otra solución puede ser durante la compilación especificar el grupo para la creación de los sockets pasando lo siguiente durante el configure:

./configure --enable-vty-group=group

 

  Suerte, espero haya sido útil,

NAT66 en Linux

Hola,

  El dia de hoy voy a hacer un post el cual no deseo que sea tomado de mala manera. Indiscutiblemente no estoy a favor del NAT pero aun asi pienso que es un mecanismo que no desaparecera en IPv6 (se reducira drasticamente) pero siempre existira. En lo posible recomiendo evitar hacer NAT cuando exista la posibilidad.

  Pueden haber muchas razones para implementar NAT66, a) seguramente los clientes acostumbrados a hacer NAT querran hacerlo en IPv6 (suene feo o bonito), b) personas que quieran ocultar su topologia a Internet, c) empresas que consideren NAT como mecanismo para cambiar los IPs de sus redes, d) la tendencia mundial de no permitir tethering en los celulares, e) querer ofrecer IPv6 detras de un dispositivo y mi proveedor no tenga DHCPv6-PD o solo me entregue una red /64, f) alguien que piense que NAT sirve de mecanismo de seguridad, etc, etc, etc, etc.

  En base a lo anterior la intencion de este post no es estar a favor o en contra de NAT, solo deseo indicar que esta disponible en el mundo de IPv6 y ofrecer un sencillo ejemplo. Para bien o para mal puede ser utilizado en algunos escenarios.

Requerimientos:

  El equipo a realizar el NAT66 debe tener:

  - Kernel > 3.9 

  - iptables > 1.4.18

  Ubuntu 14.04 cubre ambos requerimientos "out-of-the-box" y por ello es muy sencillo hacerlo.

  Existen patch para hacer NAT66 en versiones previas pero no lo indicare en este momento.

Escenario:

  Esta es la topologia en la que estoy trabajando. Deseo que "Device 2"  traduzca la direccion IPv6 origen de "Device 1" con la direccion IPv6 de la interfaz saliente (eth2). Con el comando NAT implementado estoy realmente haciendo NAT de toda la subred 2001:db8:12::/48

Configuraciones:

En DEVICE 1:

#ifconfig eth0 inet6 add 2001:db8:12::2/48

#route -A inet6 add default gw 2001:db8:12::1

En DEVICE 2:

Configurar las direcciones IPv6 en el equipo

#ifconfig eth1 inet6 add 2001:db8:12::1/48

#ifconfig eth2 inet6 add 2001:db8:23::1/48

Habilitar enrutamient o IPv6 entre las interfaces:

#sysctl -w net.ipv6.conf.all.forwarding=1

Configurar el NAT66:

#ip6tables -t nat -A POSTROUTING -o eth2 -s 2001:db8:12::/48 -j MASQUERADE

(es de notar que existen muchas otras maneras de hacer NAT con ip6tables)

En DEVICE 3:

#ifconfig eth1 inet6 add 2001:db8:23::2/48

#route -A inet6 add default gw 2001:db8:23::1

  Del lado de Device 3 pueden verificar de muchas maneras que todo funcione, incluso sin ruta por default en Device 3, DEVICE 1 puede llegarle. De igual manera tcpdump, wireshark o una sencilla revision de los logs puedes verificar que efecticamente el NAT esta llevandose a cabo.

  Espero sea de tu utilidad

Publicar prefijos IPv4 sobre una sesión eBGP IPv6

Situación:
  Deseo publicar redes/prefijos IPv4 sobre una sesión eBGP en IPv6

Historia:
  A pesar de no ser común este caso pueden ocurrir en algunas situaciones.

Solución:
  Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6/IPv4). Por ello es posible intercambiar información IPv4 dentro de una sesión eBGP IPv6.

Configuración:
  En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R2 lo aprenda R1).


R1:
!
interface Ethernet0
 ip address 22.22.22.21 255.255.255.252
  ipv6 address 2001:DB8::1/64
!        
router bgp 1
 bgp log-neighbor-changes
 neighbor 2001:DB8::2 remote-as 2
 neighbor 2001:DB8::2 ebgp-multihop 3
 !       
 address-family ipv4
 neighbor 2001:DB8::2 activate
 neighbor 2001:DB8::2 route-map IPv4 in
 no auto-summary
 no synchronization
 exit-address-family

!      
route-map IPv4 permit 5
 set ip next-hop 22.22.22.22
! 
R2:
!
 interface Ethernet0
 ip address 22.22.22.22 255.255.255.252
 half-duplex
 ipv6 address 2001:DB8::2/64
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 2001:DB8::1 remote-as 1
 neighbor 2001:DB8::1 ebgp-multihop 3
 !       
 address-family ipv4
 neighbor 2001:DB8::1 activate
 no auto-summary
 no synchronization
 network 2.2.2.0 mask 255.255.255.0
 exit-address-family
!        

 








"El truco":
  * La sesión eBGP debe ser obligatoriamente multihop, sino, R1 no aprenderá la ruta. Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!). 
  * En R1 quien aprende la ruta debe tener un route-map aplicado cuando aprende las mismas (in) forzando el next-hop con la dirección IPv4 de R2

Mas información:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-mptcl-bgp.html#GUID-06407EF3-4FAD-4519-A2A9-6CC6037288C0
- Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco




Espero sea útil!

Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco

Situación:
  Deseo publicar redes/prefijos IPv6 sobre una sesión eBGP en IPv4

Historia:
  A pesar de no ser común este caso pueden ocurrir en algunas situaciones. En esta oportunidad, tengo un router Cisco con soporte IPv6 (routing) pero su configuración BGP no permite definir neighbors IPv6

Error:
  Mensaje que quizás estas recibiendo y el mismo te trajo a esta página  :)

*Mar  1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar  1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar  1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar  1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0

Solución:
  Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6). Por ello es posible intercambiar información IPv6 dentro de una sesión eBGP IPv4.

Configuración:
  En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R1 lo aprenda R2).


R1:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::1/64
 ipv6 enable
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 1.1.1.2 remote-as 2
 neighbor 1.1.1.2 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.2 activate
 network 2001:db8::/32
 no synchronization
 redistribute static
 exit-address-family
!
ipv6 route 2001:db8::/32 Null0


R2:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::2/64
 ipv6 enable
!
router bgp 2
 no synchronization
 bgp router-id 1.1.1.2
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.1 activate
 neighbor 1.1.1.1 route-map IPv6-NextHop in
 exit-address-family
!
route-map IPv6-NextHop permit 10
 set ipv6 next-hop 2001:db8::1
!

"El truco":
  * La sesión eBGP debe ser obligatoriamente multihop, sino, R2 no aprenderá la ruta (el mismo error que se ve arriba). Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!). 
  * En R2 quien aprende la ruta debe haber un route-map aplicado cuando aprende las rutas (in) forzando el next-hop con la dirección IPv6 de R1

Después de aplicar ebgp-multihop (todo funciona):

*Mar  1 02:01:42.539: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, path 1
*Mar  1 02:01:42.539: BGP(1): 1.1.1.1 rcvd 2800:26::/32
*Mar  1 02:01:42.543: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:01:42.543: BGP(1): Revise route installing 2001:db8::/32 -> 2001:db8::1 (::) to main IPv6 table

Mas información:
- https://supportforums.cisco.com/docs/DOC-21110
- http://ieoc.com/forums/p/15154/130174.aspx
- http://ieoc.com/forums/p/15154/130174.aspx


Espero sea útil!

Enrutamiento asimetrico a traves de Juniper SSG no funciona

Situacion:
   En una red con enrutamiento asimetrico tengo problemas para que dos segmentos diferentes de red se puedan comunicar via TCP, es decir, el ping (el cual es ICMP) responde satisfactoriamente

Topologia Ejemplo:

PC-ORIGEN ---- Router --- FW --- SRV-DESTINO

Sin embargo, el enrutamiento es asimetrico, es decir, en una de las direcciones los paquetes no atraviesan el Firewall Juniper. Una opcion para revisar esto puede ser realizar tracerouter del origen al destino y viceversa, seguramente no son inversamente proporcionales.

Importante: Juniper recomienda arreglar el enrutamiento y no realizar este procedimiento. Claro, no siempre es posible, quizas hay que solucionar rapidamente, probablemente no tenemos acceso a un Router o LAN Switch que este enrutando, etc.

Explicacion:
   Ocurre que Juniper + JunOS es un Firewall Stateful y realiza "chequeo de SYN" por defecto, por elllo, si el Firewall no "ve" un paquete SYN todos los siguientes paquetes TCP seran descartados. Esto es un comportamiento eficiente porque efectivamente el equipo no debe permitir aquellos paquetes de conexiones que teoricamente no han comenzado.
 
Soluciones:
1) Arreglar el enrutamiento y que sea 100% simetrico

2) Deshabilitar "SYN Checking" siguiendo el siguiente procedimeinto:


    root# cli
    root> configure
    [edit]
    root@#set security flow tcp-session no-syn-check


    Con lo anterior es suficiente, sin embargo, si sigue sin funcionar, probablemente sea necesario adicionalmente deshabilitar el chequeo de por ejemplo numeros de secuencias (Sequence Number de TCP). El comando es:

    root@#set security flow tcp-session no-sequence-check  

Mas informacion:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB16110
y
http://www.juniper.net/techpubs/software/junos-security/junos-security95/junos-security-swconfig-security/id-19932.html


Learn more about cloudways promocode woblogger at https://woblogger.com/cloudways-coupon-code/
Learn more about money market account financiallygenius at www.financiallygenius.com

Inter-VLAN Bridging. Bridge entre dos VLANs. Cisco

Hola,
  El día de hoy tuve la necesidad de unir dos VLANs que me estaban entregando dos proveedores Metroethernet, para esta solución puede ser que exista más de una solución y/o una solución diferente. Les dejo la que me funcionó a mi:

  Escenario:
- Proveedor A: VLAN 10
- Proveedor B: VLAN 25
- Subnet de prueba: 10.22.1.176/29
- Ambas proveedores llegan a un LAN Switch Cisco
- El Inter-VLAN Bridging se hace un router Cisco 7200

  Topología:

  LAN Switch Cisco ---- (vlan 10) Proveedor A
                                  |-- (vlan 25) Proveedor B
                                  | -- (vlan trunk) Cisco Router


  Solución:

a) Paso 1:
   Para al topología planteada -quizás no es necesario en otra topología- es importante manejar Trunking entre el LAN Switch y el Router Cisco. Incluso, el LAN Switch puede manejar correctamente trunking hace el proveedor A y B sin afectar el funcionamiento de esta solución.

Lado del LAN Switch



interface FastEthernet0/3
 description Hacia Router cisco
 switchport mode trunk
end

Lado Router:



interface GigabitEthernet0/1
 no ip address
 media-type rj45
 speed auto
 duplex auto
 negotiation auto
end

interface GigabitEthernet0/1.10

 description  Hacia Proveedor A

 encapsulation dot1Q 10

end

interface GigabitEthernet0/1.25

 description  Hacia Proveedor B

 encapsulation dot1Q 25

end

b) Paso 2:

   Ahora bien, los comandos que hacen "la magia" del Bridging entre las dos VLANs son - SOLO DEL LADO DEL ROUTER -:


!START HERE


bridge irb


interface BVI1

 ip address 10.22.1.179 255.255.255.248
!

interface GigabitEthernet0/1.10

 description  Hacia Proveedor A

 encapsulation dot1Q 10

 bridge-group 1

end

interface GigabitEthernet0/1.25

 description  Hacia Proveedor B

 encapsulation dot1Q 25

 bridge-group 1

end

bridge 1 protocol ieee
bridge 1 route ip

!END HERE


  La única limitante (son en algunos escenarios) que puedo apreciar en la configuración anterior es aquella donde el proveedor no permita configurar alguna dirección IP en el router Cisco. Notese que en el ejemplo existe una interfaz virtual BVI (Bridge Group Virtual Interface) la cual es una subred utilizada dentro de las VLANs (VID 10 y VID 25)


Espero sea de alguna utilidad para alguien,


Más información:
- Understanding Issues Related to Inter-VLAN Bridging
- Understanding and Configuring VLAN Routing and Bridging on a Router Using the IRB Feature

Historico de tablas BGP. ¿Hijack de mi red?

Descripcion:
Si eres un administrador de routers que manejen tablas BGP (probablemente un ISP) quizás publicas tus propios prefijos/subredes a tu upstream provider desde tu Sistema Autonomo (AS).
Ahora bien, debes saber que tu mismo prefijo o uno muy similar (quizás un prefijo más grande o chico) puede ser -por algún error o ataque- publicado desde otro AS en otra parte del mundo. Lamentablemente esto es algo que ocurre y hay que estar preparado.

Problema:
Pienso haber sufrido un hijack de mis prefijos IP (publicadas desde un AS diferente al mio) y necesito verificarlo.
Para este inconveniente te recomiendo utilizar un routeview especificamente la herramienta BGPlay. BGPplay me permito decir que es una herramienta excelente y gratuita realizada en Java que permite buscar un prefijo y el te indicará cualquier cambio en los ultimos 10 días.
Para utilizar BGPPlay:
1) Dirigete a la pagina http://bgplay.routeviews.org/
2) Haz click sobre el boton "Start BGPlay"
3) Luego se cargará el applet de Java, allí indicas cual es tu prefijo un rango de fecha donde deseas consultar
4) Hacer click sobre Ok
5) Analizar los resultados


Recomendación:
Tener Alarmas!; para ello deseo sugerirte el sitio web: http://www.bgpmon.net/ . BGPmon es un sitio gratis dedicado al monitoreo y analisis de tablas BGP. Lo más significativo que tiene es que puedes indicar cuales son tus prefijos, tu AS y en caso de existir algún cambio ellos te envian un correo. Por ejemplo puedes configurar las siguientes alarmas:
- En caso de existir algún otro AS que comienza a publicar algún prefijo tuyo te enviaran un correo
- Redes nuevas
- Cambios significativos de path
- Redes subneteadas
- Retiro/withdraw de redes

Suerte, espero sea de tu utilidad,

Tunel GRE entre Cisco y Linux (Debian)

Situación:
Deseo crear un tunel GRE entre en un equipos Linux y un router Cisco

Procedimiento:

a) Del lado del linux:

Lo primero que hay que hacer es levantar el modulo ip_gre del lado del Linux:
#modprobe ip_gre

Luego,necesitamos definir ante todo, el nombre de la interfaz, y la dirección que este va a tener, en mi caso, decidi que la interfaz se llamara "Core2", y usare la dirección IP 7.7.7.0/30 (OJO, esta es una dirección IP PUBLICA!!!!!!, es conveniente usar direcciones IP privadas, ejm: 10.0.0.0/8, en mi caso, esto se monto en un laboratorio).

Ejecutamos los siguientes comandos

ip tunnel add Core2 mode gre local 8.8.8.1 remote 9.9.9.2 dev eth0
ip add ad dev Core2 7.7.7.1/32
ip link set dev Core2 up


Local hace referencia a la interfaz en nuestro linux (eth0 que tiene el IP 8.8.8.1) por donde sale el trafico, si manejamos una sola interfaz, en este caso usaríamos la dirección IP de la interfaz que tenemos configurado, si manejamos dos interfaces, es conveniente usar la interfaz por donde sabemos que el trafico hacia la otra punta del tunel va a salir. (usar un traceroute)

Remote hace referencia a la dirección IP del peer, esta tendría que ser la dirección contra la que vamos a levantar el tunnel


Ahora, vemos como queda la configuracion de la interfaz

#ifconfig Core2
Core2 Link encap:UNSPEC HWaddr C8-2F-97-7E-05-08-00-00-00-00-00-00-00-00-00-00
inet addr:7.7.7.1 P-t-P:7.7.7.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1
RX packets:134 errors:0 dropped:0 overruns:0 frame:0
TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11896 (11.6 KiB) TX bytes:3780 (3.6 KiB)


b) Del lado del equipo cisco , es un poco más sencillo,


GRE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
GRE#int tunnel 100
GRE(config-if)#tunnel source 9.9.9.2
GRE(config-if)#tunnel destination 8.8.8.1
GRE(config-if)#ip address 7.7.7.2 255.255.255.252


Listo!!!

Veamos la configuracion

GRE#sh run in tu100
Building configuration...

Current configuration : 128 bytes
!
interface Tunnel100
ip address 7.7.7.2 255.255.255.252
tunnel source 9.9.9.2
tunnel destination 8.8.8.1
end

GRE#

Y listo Sres, ya tenemos nuestro Tunel levantado

GRE#sh int tunnel 100
Tunnel100 is up, line protocol is up
Hardware is Tunnel
Internet address is 7.7.7.2/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 9.9.9.2, destination 8.8.8.1
Tunnel protocol/transport GRE/IP


Cabe destacar que la interfaz tunnel 100, usa por defecto un tunel modo GRE, asi que no hace falta definirlo.

Revisar:

Para probar conexión, un simple Ping podria darnos lo que buscamos


GRE#ping 7.7.7.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.1, timeout is 2 seconds:
!!!!!


Lab:/home/rollingpaper# tcpdump -i Core2 icmp
tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on Core2, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
11:56:26.704400 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 0, length 80
11:56:26.708400 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 1, length 80
11:56:26.710648 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 2, length 80
11:56:26.712147 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 3, length 80
11:56:26.713897 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 4, length 80



Listo Sres, espero que haya sido de ayuda

Networking Tips

Gracias por entrar en acostanetwork.blogspot.com.
Aquí se publicaran tips semanales en el area de networking