Mostrando entradas con la etiqueta ipv4. Mostrar todas las entradas
Mostrando entradas con la etiqueta ipv4. Mostrar todas las entradas

martes, 11 de agosto de 2015

Como monitorear independientemente contadores IPv4 e IPv6 en Cisco (tráfico)

Introduccion
  Hoy en día es muy común ver redes en la modalidad Dual Stack (IPv4 + IPv6) donde ambos protocolos conviven en misma VLAN y/o Bus de red

  En el presente post voy a mostrar como monitorear independientemente el tráfico IPv4 e IPv6 que atraviesa una interfaz de un equipo Cisco.

Que se necesita
  a) Primero es muy importante el soporte de IP::MIB en el IOS del router, muy probablemente ya lo tengas pero vas a necesitar un IOS relativamente novedoso porque existen OID que no estan en versiones viejas.

  Para la realizacion del siguiente documento utilizamos:  c7200-adventerprisek9_sna-mz.152-4.M8.bin

  b) El cliente debe tener el software con el que vayas a monitorear..., eso es todo :-)  El siguiente post brevemente da ejemplos en MRTG, por ello instalamos:

apt-get install snmp
apt-get install snmp-mibs-downloader
apt-get install mrtg

  c) Para un mejor seguimiento de este documento es mejor tener compilado el MIB: IP-MIB de Cisco, muy seguramente quedó instalado luego de ejecutar apt-get install snmp-mibs-downloader.


Topologia utilizada para este post




Pasos

a)  Primero hay que averiguar el índice de la interfaz. Hay dos maneras:
  1) Desde el CLI del equipo Cisco con el comando:

#show snmp mib ifmib ifindex

Obtendremos algo así:

FastEthernet1/1: Ifindex = 3
Loopback0: Ifindex = 5
Null0: Ifindex = 4
FastEthernet1/0: Ifindex = 2
FastEthernet0/0: Ifindex = 1

 Logicamente trabajaremos con las interfaces que nos interecen, recordemos el número de índice que lo necesitaremos más adelante.


  2) Vía SNMP:
  Sabiendo al menos el IPv4 que queremos monitorear (mas adelante podremos monitorear IPv6 también)

Desde el equipo linux hacemos:
#snmpwalk -mALL -v2c -chola3 host1 .1.3.6.1.2.1.4.20.1.2.+DIRIPv4  
Por ejemplo:
#snmpwalk -mALL -v2c -chola3 host1 .1.3.6.1.2.1.4.20.1.2.192.168.1.1

Lo anterior nos devuele el indice de la interfaz que queremos monitorear. Listo!.

Si queremos estar seguro podemos hacer:

#snmpwalk -mALL -v2c -chola3 host1 1.3.6.1.2.1.2.2.1.2.+IntfIndex  
y nos devuelve la interfaz.

Donde:
host1 = host (podemos colocar un IP)
hola3 = la comunidad SNMP


b)  Crear los OID a monitorear
  i) Para obtener el OID de paquetes "INPUT IPv6" haremos lo siguiente:
- Utilizaremos este OID base y la agregaremos el indice de la interfaz al final:
  1.3.6.1.2.1.4.31.3.1.5.2 (IP-MIB::ipIfStatsInOctets.ipv6) + ifIndex = 1.3.6.1.2.1.4.31.3.1.5.2.1

 ii) Para obtener el OID de paquetes "Output IPv6" haremos lo siguiente:
  1.3.6.1.2.1.4.31.3.1.32.2 (IP-MIB::ipIfStatsOutOctets.ipv6) + ifIndex = 1.3.6.1.2.1.4.31.3.1.32.2.1

En MRTG el mrtg.cfg quedaría algo así:

Target[ipv6_f00]:1.3.6.1.2.1.4.31.3.1.5.2.1&1.3.6.1.2.1.4.31.3.1.32.2.1:readonly@192.168.1.1


Ahora bien, también queremos monitorear el tráfico IPv4:

i) Para obtener el OID de paquetes "INPUT IPv4" haremos lo siguiente:
- Utilizaremos este OID base y la agregaremos el indice de la interfaz al final:
  .1.3.6.1.2.1.4.31.3.1.5.1 (IP-MIB::ipIfStatsInOctets.ipv4) + ifIndex (F0/0) = .1.3.6.1.2.1.4.31.3.1.5.1.1

ii) Para obtener el OID de paquetes "Output IPv4" haremos lo siguiente:
  1.3.6.1.2.1.4.31.3.1.32.1 (IP-MIB::ipIfStatsOutOctets.ipv4) + ifIndex (F0/0) = 1.3.6.1.2.1.4.31.3.1.32.1.1


Target[ipv4_f00]:.1.3.6.1.2.1.4.31.3.1.5.1.1&1.3.6.1.2.1.4.31.3.1.32.1.1:readonly@192.168.1.1


  c) Se generó tráfico desde los hosts IPv4 e IPv6 hacia la Loopback del router principal con la aplicación bwping, se cambió el ancho de banda transmitido con el objeto de ver los cambios en la interfaz

    Para generar el tráfico utilicé el siguiente script:

while [ 1] 
do 
  bwping6 -b 256 -s 100 -v 9999 2001:db8:ffff::ffff
done

y

while [ 1] 
do 
  bwping -b 128 -s 100 -v 9999 192.168.255.255
done




Resultados

IPv4:




IPv6:



Total en la interfaz (default en MRTG):






Get Tweaked apps, iOS Emulators and Hack games with iPA Library Browse and download iOS IPA Apps, tweaks and ++ apps for iPhone, iPad and iPod Touch.
Guia do Host: Dicas para Criação e Hospedagem de Sites alphimedia hospedagem de site e revenda de hospdagem mais barata do brasil O Guia do Host é o local ideal para quem quer aprender mais como criar e hospedar um site. Nele você vai encontrar dica melhor hospedagem site brasil No Guia do Host você vai encontrar a melhor hospedagem para seu projeto, acompanhe também nossas promoções e cupons de desconto em parceria com as melhores hospedagens de sites da atualidade.
인스타그램 바로가기
जीबी व्हाट्सएप APK WhatsApp का मॉड वर्जन है जिसमें कई सारे Advance Features मिलते है तो जीबी व्हाट्सएप डाउनलोड करें और पाए Hide Last Seen जैसे बेहतरीन फीचर्स।

lunes, 26 de enero de 2015

Tecno-cuento: La triste historia de un ISP sin IPv6

Erase una vez.....
  Erase una vez, en un tiempo no muy lejano, un ISP muy grande que
dominaba las telecomunicaciones de un país, se sentía poderoso y sin
competencia. Cuando alguien necesitaba conectarse a Internet siempre
recurrian a ellos. Tenían una penetración en el mercado envidiable
para todos.

  Sin embargo, este ISP tan grande no había querido implementar nunca
IPv6, pensaba que tenía suficientes direcciones IP para abastecerse, no
percibían indicador alguno que dijera: tengo que tener el nuevo protocolo.

  Durante esos años, otro pequeño ISP si implementó IPv6,
comenzaron a crecer lentamente, se dieron cuenta que el protocolo si
marcaba una diferencia en sus clientes, ganaban usuarios gracias a tener
soporte de dicho protocolo. Su penetración en el mercado crecía,
ganaban más dinero y más respeto. Siendo más grandes le era más
fácil conseguir mejores precios de equipos, de tráfico, de
interconexión. Todo funcionaba muy bien. El ISP pequeño sencillamente
no lo podía creer, algo tan sencillo de implementar como IPv6 le
rendía frutos inimaginables. Sus clientes le decian que tenian crear
VPNs y conferencias contra otras partes del mundo, que sus subsidiarias, clientes y
aliados de negocio en Europa y Asia si tenían IPv6, por ello IPv4 no les
era importante.

 El ISP grande, a pesar de ser tan poderoso comenzó a tener
problemas internos, no eran problemas de facturación o dinero. Eran
quejas del personal de ventas que no podían cerrar las mismas porque
los clientes empezaron a pedir IPv6 y ellos siendo tan grandes e
importantes sencillamente no tenían!!. Clientes corporativos pedían
IPv6, usuarios residenciales solicitaban lo mismo, incluso grandes
licitaciones del estado. Cuando eso empezó a ocurrir el Gerente de
Ventas tuvo quejas hacia los departamentos de Producto, Ingeniería y
Operaciones. Estos últimos se quedaron sin palabras y algunos empleados
fueron removidos por los dueños de las empresas. Al final, a Ventas no
les importaba donde estaba la culpa, sencillamente no podían obtener
nuevos clientes.

 Posteriormente algunos vendedores al percatarse que estaban
perdiendo clientes fueron contratados por el ISP pequeño que estaba
buscando personal, total ahora sí podían pagar a importantes vendedores
porque en realidad ya no eran tan chicos. Lo mismo ocurrió con el jefe
de redes del ISP grande que sabía mucho de IPv6 pero la burocracia no
le había permitido llevar a producción el novedoso protocolo. Luego el
jefe de redes lógicamente trajo a su administrador de servidores de
confianza y su persona de seguridad. El ISP grande no podía creer lo
que estaba pasando.

 Los vendedores contratados por el ISP chico (provenientes del ISP
grande) venían con su enorme cartera de clientes, todos potenciales para
ser instalados. Se avecinaba una estampida de clientes del ISP grande.
Pasaban los meses y el ISP chico ya no solo ofrecía Internet, su Data
Center era mucho más grande, importantes empresas trajeron servidores
nuevos, de cache y mucho más. Ahora ofrecían co-location, hosting,
virtual hosting, voz, video y más.

 Cuando el proveedor grande quiso implementar IPv6, tuvo que hacer las
cosas muy rápidas, les salian mal, varios errores, además
consultores y empresas se aprovecharon de sus problemas y cobraban mucho
más para hacer las tareas con la premura que solicitaban. Aumentó el
downtime de red, las llamadas al call center y la prestigiosa reputación se venía
abajo.

 Como es de esperar, al final de la historia todos en el cuento:
clientes y proveedores terminaron implementando IPv6, unos más felices que otros
pero todos con IPv6 en sus redes

  Espero lo hayan disfrutado, y Colorín Colorado este cuento se ha acabado

Abrazos a todos,

Alejandro,


Get ready for Black Friday deals in South Africa with bidorbuy. We at bidorbuy are as excited as you are! We are hard at work to find the best deals at the best price to bring you a whole week of awesome Black Friday deals!

lunes, 10 de febrero de 2014

Configurando Quagga para manipular prefijos (Local Preference) utilizando RPKI

Objetivo:
   En el siguiente mini laboratorio configuraremos Quagga para manipular prefijos BGP y asignar Local Preference segun el estado RPKI (valid, invalid, Not Found).
 
Escenario:
- R1 publica un prefijo con un AS que no le corresponde (segun ROA)
- R2 publica el mismo prefijo que R1 pero desde un AS que si es valido
- R2 publica un prefijo sin ROA.
- En este escenario el validador y el router Quagga estan en el mismo equipo

Diagrama del laboratorio:




Requisitos:
- Quagga con soporte para RPKI
- RPKI Validator de RIPE NCC
- Un prefijo que sepamos que se tiene ROA valido. En nuestro caso utilizamos el prefijo 200.85.64.0 que sabiamos que tiene un ROA que indica que debe ser publicado por el AS 7908
- Ejecutar el validador de RIPE NCC antes de ejecutar Quagga


Configuraciones de todos los equipos

Conf-Quagga-RPKI-Mini-LAB.txt

hostname RPKI-RTR
password test
!
router bgp 65000
 bgp router-id 10.0.0.10
 bgp bestpath prefix-validate allow-invalid
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 route-map rpki in
 neighbor 10.0.0.2 remote-as 7908
 neighbor 10.0.0.2 route-map rpki in
 neighbor 10.0.0.3 remote-as 65003
 neighbor 10.0.0.3 route-map rpki in
!
route-map rpki permit 10
 match rpki invalid
 set local-preference 10
!
route-map rpki permit 20
 match rpki valid
 set local-preference 30
!
route-map rpki permit 30
 match rpki notfound
 set local-preference 20
!        
line vty
!
enable-rpki
  rpki polling_period 1000
  rpki timeout -1216757171
!
  rpki group 1
    rpki cache 127.0.0.1 8282
! 

R1.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable password test
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.1 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 password test
 login
!
end

R2.cfg

!
!
!
!
hostname R2
!
no ip domain lookup
no ip icmp rate-limit unreachable
ip tcp synwait 5
!
!
interface Ethernet0
 ip address 10.0.0.2 255.255.255.0
 half-duplex
!
!
router bgp 7908
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

R3.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.3 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 192.168.0.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
end



Salida final en Quagga:
(Notese los flags N, I, V) (Notese los local preference)

RPKI-RTR# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
N*> 192.168.0.0      10.0.0.3                 0     20      0 65003 i
I*  200.85.64.0      10.0.0.1                 0     10      0 65001 i
V*>                  10.0.0.2                 0     30      0 7908 i

Total number of prefixes 2




sábado, 28 de diciembre de 2013

IPv6, no te vistas que no vas. Ahora IPv4S

Netland, Diciembre 2013
  Luego de una reunion casi secreta de una semana en Suiza, los principales fabricantes de hardware y software a nivel mundial tomaron la drástica decisión de no continuar con el desarrollo e implementación de IPv6. Como alternativa decidieron de manera únanime utilizar el mismo protocolo IPv4 y crear un nuevo concepto de sub-IP (IPv4S).
  Los detalles técnicos se describieron así: "Vamos a utilizar un bit que se encuentra reservado en la cabecera IPv4 desde su origen (RFC 791), dicho bit al estar encendido los hosts leeran los campos de datos indicando más direcciones IPv4, es decir, es un subgrupo de IPv4". Según el PhD Tniv Frec: "Esto es algo que debió hacerse hace mucho".
  A la reunión asistieron en gran cantidad los mejores programadores del mundo los cuales se mostraban muy contentos con esta nueva idea. Ms Avaj, una reconocida en programadora orientada a objetos indicó "Al fin", esto es lo que todos necesitamos, ahora el desarrollo de software será tres veces más rápido.
  Con la nueva metodología los fabricantes de hardware y software pueden realizar los ajustes pertinentes de manera más sencilla, rápida y funcional. Para los ISPs y programadores este cambio será transparente debido que ahora cuentan con "SP&P" (Super Plug & Play) donde servidores Web y Mail se autoconfigurarán de manera mágica; Ms Cin indicó que incluso los registros DNS serán realizados sin intervención humana gracias el nuevo registro SeIP (sub enhance IP) donde todos los host hablan con todos los DNSs (full mesh).
  Otro participante lllamado Pir, indica que si esto hubiese existido hace 5 años el Internet actual fuera 400 veces más grande y según Mr. Lrep unas 8 veces rápido.
  Desde el aspecto social, Ms. Locotorp, menciona que esta nueva versión servirá para disminuir el hambre en el mundo gracias a que es un protocolo pensado en el consumo eléctrico, indica que es 34% más eficiente gracias a su inteligencia incorporada, todo gracias al nuevo bit que nadie había querido usar. Al final de la entrevista dió a atender que es una verguenza que ingenieros de todo el mundo no hubiesen hecho esto años atrás.
  Un entrevistado de apellidos Tan Tap que no quiso salir a la luz pública lamenta que IPv6 no hubiese crecido más, indicó que el mal uso del NAT y la gran cantidad de mecanismos de transición le quitaron el impulso a la implementación de IPv6, nuestro reportero indica que Mr Tan Tap siempre tuvo una sonrisa fingida y se rió de todos los que habían implementado IPv6.
  Referente a las redes internas, en base a la información de este grandioso bit, dependiendo de si esta completamente encendido o solo un poco se auto-determina si la dirección IP es interna o externa, a su vez reconoce si el host está en una MZ o DMZ, y simultaneamente aplica las políticas de seguridad pertinentes, los administradores de red no tienen necesidad de modificar ninguna política.
  Mr. Lufetats indica que apoyándose en IPv4S los firewall serán muy sencillos de implementar, unicamente es necesario colocarlo y voila!.., BCP 38, servicios y otras politicas se autoconfiguran.
  Finalmente, dieron a conocer que los conceptos de EGPs e IGPs desaparecerán en unos años. La nueva versión puede hablar inter-AS e  intra-AS gracias a sus mecanismos de reconocimiento de rutas, se adapta de Distance Vector a Link State automaticamente según convenga, reconoce saturación de los enlaces, delay, pérdida de paquetes y comprime los datos cuando es necesario. Incluso percibe cuando el CPU del enrutador está sobre cargado y toma acciones correctivas.
  Estiman que en solo un año todos los hosts de internet contaran con IPv4S, luego, las capas 4 y 7 del modelo OSI desapareceran porque IPv4S puede a su vez llevar directamente los protocolos de aplicación, con ello se espera que la enseñanza de redes sea trivial.


Saludos,

Att.
Rebif Citpo VI

viernes, 22 de febrero de 2013

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!

domingo, 17 de febrero de 2013

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!


viernes, 7 de diciembre de 2012

Solucion: Apache solo escucha sobre IPv6

Situación:
  Apache solo funciona sobre IPv6

Troubleshoooting:
a)  Para que escuche en IPv4:
  - Editar el archivo  /etc/apache2/ports.conf
  - En la directiva Listen colocar por ejemplo:
     Listen 192.168.1.10:80  

  Se pueden colocar varias directivas Listen. Tales como:
     Listen 192.168.1.10:80  
     Listen 127.0.0.1:80 

  Para escuchar en todo IPv4 (cualquier IPv4 configurado en el server):
     Listen 0.0.0.0:80 
 
b) Para escuchar en IPv6:
  - Editar el archivo  /etc/apache2/ports.conf
  - En la directiva Listen colocar <[direccionIPv6]:puerto>. Por ejemplo:

Listen [2001:db8::4]:80

  Reiniciar apache..., por ejemplo: /etc/init.d/apache2 restart

Diagnóstico:
  Para saber que servicios, a que direcciones IP escucha y que proceso esta asociado recomiendo utilizar el comando: netstat -pan

#netstat -pan | more
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      965/mysqld     
tcp        0      0 127.0.0.1:587           0.0.0.0:*               LISTEN      1020/sendmail: MTA:
tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN      1162/perl      
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      8478/vsftpd    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      816/sshd       
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1020/sendmail: MTA:
tcp        0      0 192.168.1.10:22          192.168.1.2:57997       ESTABLISHED 19601/sshd: aacosta
tcp6       0      0 ::1:587                 :::*                    LISTEN      1020/sendmail: MTA:
tcp6       0      0 :::80                   :::*                    LISTEN      1134/apache2   
tcp6       0      0 :::22                   :::*                    LISTEN      816/sshd      
 

  En el extracto anterior la ultima linea indica que se está escuchando en todas las direcciones IPv6 (se puede comprender gracias a la culumna de la izquiera que indica tcp6 y luego en la cuarta columa indica ::22). El puerto está en estado listen por el proceso sshd y el pid 816
  Para el primera linea se entiende que mysqld está escuchando en la dirección IPv4 127.0.0.1 en el puerto 3306 bajo el pid (process id) 965. Es decir, mysql no esta habilitado para escuchar conexiones de red (solo escucha localhost)


Mas información:
- http://serverfault.com/questions/332409/how-to-set-apache-virtualhost-to-work-with-ipv6- http://www.linuxweblog.com/blogs/sandip/20081027/forcing-apache-listen-ipv4
- http://www.linuxask.com/questions/limit-apache-only-listen-to-ipv4-address

lunes, 13 de agosto de 2012

Entrevista en la radio sobre IPv6



http://tecnologiahechapalabra.com/archivo/media.asp?i=858

Gustavo Terrero, Presidente de CAVEDATOS; Ricardo Holmquist, Presidente de ISOC Venezuela; y Alejandro Acosta, director del Foro Latinoamericano de IPv6; conversan con Peter Cernik en la oportunidad de explicar la necesidad de migrar toda la estructura de direcciones de internet al Protocolo de Internet version 6, que debe sustituir al IPv4, ya que este último ha agotado su capacidad de manejar identificaciones únicas para cada dispositivo conectado y por conectarse en la red de redes.

Click Aqui

- - - 

Duración = 00:24:38. 


Tomado de/Información original en:
http://tecnologiahechapalabra.com/archivo/media.asp?i=858

viernes, 1 de octubre de 2010

Sendmail e IPv6. Hacer que sendmail escuche en IPv6

Problema:
Tengo un servidor de correo en Linux Debian con Sendmail, en IPv4 todo funciona bien pero no escucha conexiones en IPv6

Escenario:
Servidor Debian con Sendmail 8.14.3 e IPv6 configurado

Procedimiento:
Primero verificar que efectivamente Sendmail no escucha en IPv6. Por ejemplo:

#netstat -pan | grep sendmail

tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2596/sendmail: MTA:
unix 2 [ ACC ] STREAM LISTENING 4198 1025/mysqld / var/run/mysqld/mysqld.sock
unix 2 [ ACC ] STREAM LISTENING 13539 2596/sendmail: MTA: / var/run/sendmail/mta/smcontrol
unix 2 [ ] DGRAM 13535 2596/sendmail: MTA:

En la salida anterior notamos que sendmail se encuentra escuchando solo sobre la red IPv4.

Solucion:
La solucion es indicarle al Sendmail que también levante sobre la familia Inet6. Para ello es necesario modificar el sendmail.mc para reconstruir el sendmail.cf y luego reiniciar el sendmail. Los pasos son los siguientes:

1) Editar el sendmail.mc y agregar las siguientes lineas:
DAEMON_OPTIONS(`Family=inet6, Name=MTA-v6, Port=smtp, Addr=DIRIPV6')dnl
DAEMON_OPTIONS(`Family=inet6, Name=MSP-v6, Port=submission, M=Ea, Addr=::1')dnl

OJO: Sustituir DIRIPV6 por tu dirección IPv6


2) Ejecutar sendmailconfig (para procedar el sendmail.mc con m4 y generar el .cf)

3) Luego de ejecutar el comando anterior lo siguiente es siempre indicarle que Y en las siguientes preguntas:

Configure sendmail with the existing /etc/mail/sendmail.conf? [Y] y
Configure sendmail with the existing /etc/mail/sendmail.mc? [Y] y
Reload the running sendmail now with the new configuration? [Y] y

Verificar:
Para verificar ejecuta el comando:
#netstat -pan | grep sendmail

Realiza un telnet de la siguiente manera:

#telnet ::1 25

debes recibir respuesta similar a:

Trying ::1...
Connected to ::1.
Escape character is '^]'.
220 ipv6.para.com ESMTP Sendmail 8.14.3/8.14.3/Debian-9.1ubuntu1; Fri, 1 Oct 20 10 11:52:48 -0430; (No UCE/UBE) logging access from: localhost(OK)-localhost [IPv6:::1]

Suerte, espero haya sido util.

miércoles, 1 de abril de 2009

Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64

Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64