#30 vamos, que es lo que decía, vamos a tener que cambiar todo el direccionamiento de nuestra red, lo cuál no creo que le haga mucha gracia al coordinador xD
Yo uso http://www.gliffy.com/ para los diagramas xD
El switch que está fuera del área azul no lo gestionamos nosotros, sólo sabemos que existe y ya está
#32 Básicamente cuando el Main Link (router 01R) fallaba hay otro router (02R) que sabe una ruta alternative por OSPF y la advierte en BGP, hasta aquí todo perfecto.
Cuando el Main Link se recupera en 01R, 02R sigue advirtiendo la ruta en BGP por que el weight es más preferido que el que recibe en BGP y por tanto en su tabla de rutas se queda con la entrada de OSPF y nunca hace el failback a la ruta aprendida por BGP.
Todo esto no es un gran problema en sí, el problema más grave es que 02R que no hace el failback es el que advierte la default network por BGP, y cuando el otro router afectado intenta llegar a internet hay un bucle en la red OSPF del cliente por culpa de nuestro router.
La solución es poner un route map en 02R y cambiarle el weight a la LAN de 01R a algo mayor que 32768 , 40000 por ejemplo.
Es un poco lioso explicarlo así sin papel ni nada, si estás más interesado preparo el LAB en GNS este finde y le echas un ojo.
#33 Imagino que algo como que la ruta redistribuida de OSPF tiene mayor peso que la propia ruta eBGP y esa misma ruta luego la advierte como ruta por defecto y genera el problema, no veo como se produce el bucle porque no se el mapa de red pero supongo que por ahi van los tiros.
Si no tambien le puedes poner weight 0 a las rutas redistribuidas de OSPF en BGP.
La redistribucion es jodida de diagnosticar.
#34 Sep, por ahi van los tiros, con un route-map se arregla el asunto. Es un problema del Lead Engineer (broke by design le llamamos aqui 
)
La putada para nosotros es que en el 99% de los casos no tenemos un diagrama de la red del cliente y a base de tocar tienes que hacerte la idea de que topologia tienen y que protocolos usan, y a partir de ahi empezar a hacer el tshoot.
Hoy he tenido algo divertido en el trabajo (oculto las IPs/MACs/Hostnames por temas de privacidad):
HOSTNAME01#sh standby
GigabitEthernet0/0 - Group 11 (version 2)
State is Active
14 state changes, last state change 2d15h
Virtual IP address is XXX.XXX.XXX.XXX
Active virtual MAC address is XXXX.XXXX.XXXX
Local virtual MAC address is XXXX.XXXXX.XXXX (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.544 secs
Preemption enabled, delay min 60 secs
Active router is local
Standby router is unknown
Priority 105 (configured 105)
Track object 99 state Up decrement 10
Group name is "hsrp-Gi0/0-11" (default)
HSRP ICMP redirects disabled
Basicamente HOSTNAME01 y HOSTNAME02 no se ven en la LAN , HOSTNAME02 muestra esto en la tabla ARP:
HOSTNAME02#sh arp | i GigabitEthernet0/0
Internet XXX.XXX.XXX.XXX - XXXX.XXXX.XXXX ARPA GigabitEthernet0/0 = IP PROPIA
Internet XXX.XXX.XXX.XXX - XXXX.XXXX.XXXX ARPA GigabitEthernet0/0 = VIRTUAL IP
HOSTNAME01 muestra toda la LAN en la tabla ARP excepto la ip de HOSTNAME02.
He habilitado CDP y estan en diferente VLAN, esta es la forma ingeniosa que se me ha ocurrido para notificarles que cambien de VLAN :
HOSTNAME01#ssh -l checkyourvlanconfiguration-iswrong-ATTEngineer XXX.XXX.XXX.XXX
Password:
Password:
Password:
[Connection to XXX.XXX.XXX.XXX closed by foreign host]
Estoy seguro que no haran nada hasta que se les caiga el circuito en el primario y vengan quejandose de que tienen un UBU (UselessBackUp).
En nuestro caso es al reves, todas las configuraciones de cliente son nuestras, lo que no llevamos es la parte WAN en los circuitos que son fuera de España.
http://www.renesys.com/2014/04/indonesia-hijacks-world/
En resumen, la cagaron con unas rutas que se propagaron a nivel mundial y 2/3 del tráfico de Internet pasó por sus redes.
Me preguntan en un ejercicio como se podría evitar ese problema, pero la verdad que no tengo ni idea.
That is, the AS paths to 146.23.208.0/21 tend to look like … 2856 7862 7862 7862 7862 7862
No entendí mucho, pero por lo visto el nombre de AS de BGP era parecido a este 2856 7862 7862 7862 7862 7862 tal vez metieron en el nombre de AS alguna cifra de menos o de mas de eso 7862 y la cagaron con el enrutamiento.
#38 Se supone que con aunthentication debería de valer, pero si no entendí mal en internet no hay en auth (cosa que desconozco) a ver si otra persona nos ayuda, que tengo ganas de sacar apuntes de BGP.
Supongo que no será lo único que hay que tocar ya que si tiene auth no evitará que las rutas se propaguen y si tienen menor coste sean las elegidas, quizás faltaría más información para saber como se ha dado el problema exactamente o tal vez entendí mal el asunto.
#38 por lo que veo las rutas de Chevron van penalizadas con el AS path prepend, que basicamente es alterar el atributo AS path de la ruta repitiendolo las veces que sea necesario para que a la hora de elegir una ruta segun su AS path sea enorme y se prefiera otra con menor AS path, que entiendo que las rutas que inyectaron tenian un AS path mas corto.
Pues las recomendaciones -yo no he trabajado con peering o transito de BGP- son controlar muy bien que rutas anuncias y cuales permites, definir una politica de enrutamiento, que camino sigo yo hacia los otros AS (local preference), como vuelve el trafico (metrica) ,como anuncio mis rutas, que rutas permito, que atributos modifico, etc-, supongo que en un primer lugar manejar la local preference para la entrada en los AS y asi no tener que depender del AS path.
En resumen, si tu anuncias una ruta a X sitio pero por alguna razon le empeoras un atributo sobre el que decide BGP, llego yo anuncio la misma ruta con mejor atributo y la gente utilizara mia a menos que ellos decidan cual usar mediante la local preference, esto es lo que entiendo que ha pasado.
