bgp

Cambios en anuncio AMPR en BGP

 

26634-bgp-toc2

Dani, nos pasa esta info de cambios en las configuraciones de Hamnet.es:

 

Los bloques 44.133.128.0/17 (Hamnet EA) y 44.158.144.0/22 (Hamnet CT)
están empleando actualmente el gateway AMPR de DB0FHN para conectar con
la 44net internacional que no es accesible por BGP (esto es, el resto
del mundo menos Alemania, Austria y algunos países vecinos). DB0FHN
exporta por BGP las rutas que recibe por AMPR-RIPD. Dichas rutas se
originan todas en el AS64620.

Hasta ahora, el BGP en EA4GPZ estaba propagando las rutas provenientes
de AMPR-RIP, de manera que los paquetes con destino la 44net
internacional eran enrutados hacia DB0FHN.

Los cambios realizados son los siguientes:
* El BGP de EA4GPZ bloquea las rutas que se originan en AS64620.
* El BGP de EA4GPZ anuncia la red 44.0.0.0/8 a todos los BGPs vecinos
excepto DB0GW y F4HOF (es decir, a todos los BGPs vecinos en EA o CT).
* En el router de EA4GPZ hay una ruta estática que manda los paquetes
destino a 44.0.0.0/8 en dirección hacia 44.133.192.2 (DB0GW).

Los efectos de estos cambios:
* Fuera de EA y CT estos cambios no hacen ningún efecto (salvo el caso
de F4HOF, al cual le estábamos enviando las rutas originadas en
AMPR-RIPD aunque no le valían para nada).
* En EA y CT, si la IP de destino es accesible por BGP, al usarse la
subred más específica se emplea la ruta propagada por BGP. De este modo,
se accede a dicho destino por la ruta propagada por BGP. Si la IP de
destino no es accesible por BGP entonces la única ruta que concuerda es
44.0.0.0/8 y los paquetes se encaminan hacia EA4GPZ. Al llegar a EA4GPZ
los paquetes pasan a DB0GW, y ya la Hamnet alemana sabe cómo enrutarlos
hasta DB0FHN.

Las ventajas de este cambio (esencialmente más flexibilidad a la hora de
elegir el gateway AMPR y la posibilidad de usar varios gateway AMPR):
* Ahora es posible que una subred de Hamnet EA o CT use el gateway AMPR
de EA4GPZ en lugar de el de DB0FHN. Para esto, basta que el AMPR-RIP
anuncie dicha subred por el gateway de EA4GPZ (para el tráfico entrante)
y colocar una ruta estática en EA4GPZ que enrute el tráfico que no
concuerda con ninguna red BGP por el gateway de EA4GPZ (para el tráfico
saliente).
* Ahora es posible instalar un nuevo gateway AMPR en cualquier sitio de
Hamnet EA o CT y que un conjunto de ASs vecinos usen dicho gateway. Para
ello, los bloques de esto ASs deben anunciarse en AMPR-RIP por el nuevo
gateway. El nuevo gateway debe propagar la ruta 44.0.0.0/8 igual que
hace EA4GPZ. Los ASs que se encuentren en el borde de este conjunto
deben bloquear la propagación de la ruta 44.0.0.0/8 a través del borde
de este conjunto (en ambas direcciones).

A la hora de la práctica:
* En el futuro probablemente nos convenga utilizar el gateway de EA4GPZ
en lugar del de DB0FHN (u otro gateway más cercano, si alguien se anima
a instalar más gateways). Esto tiene la ventaja de que los paquetes que
van a la 44net internacional salen a internet directamente por EA4GPZ (o
otro gateway más cercano) en lugar de ir primero hasta DB0FHN. El único
problema es que para empezar a hacer esto se necesitan hacer cambios en
el portal de AMPR. Los usuarios del bloque 44.133.128.0/17 necesitaremos
la colaboración de Rafa EB2DJB y/o Brian Kantor y quizás Jann DG8NGN.
Los usuarios del bloque CT creo que solo necesitan la colaboración de
Jann (quizás).
* Podemos ofrecer la posibilidad de hacer de gateway AMPR a otras redes.
Estoy pensando en F4HOF y compañía, que creo que no tienen gateway AMPR
(aunque tampoco parece que les importe mucho) y en la red de Galicia y
el norte de Portugal con la que estamos realizando un enlace (creo que
no se ha hablado de esa red por esta lista, pero pasaré la información
en cuanto que el enlace esté plenamente funcional).

Anuncios

Integración DMR y Hamnet

dmr-logo

En hamnet tuvimos un hilo en la lista de correo  que creo que puede ser interesante poner aquí para abrir debate con los miembros de este foro.

La idea es que el direccionamiento BGP que se usa en hamnet de 16 bits, se vio que quedaba pequeño y en otros países se están pasando al direccionamiento de 32 bits que permite más direccionamiento. Estudiando el tema para hacerlo aquí en EA, se planteó la cuestión de integrarlo teniendo en cuenta la red DMR para que hubiera integración entre ambos sistemas.

Corte y pego los correos más interesantes:

 

parte de la discusión
se llevó en las listas de correo alemanas. Creo que la propuesta más
popular (aunque no sé si fue aceptada por todos) fue la siguiente:

“Usar el esquema

42<mcc>xxxxx

donde <mcc> son los tres dígitos de código MCC del país
(http://www.mcc-mnc.com/) y xxxxx son 5 dígitos para administrar por
cada país según se considere oportuno. Observar que algunos países
tienen varios códigos MCC según su tamaño.

En España el MCC es 214 y en Portugal 268.”

Sobre cómo asignar los 5 dígitos en España, tengo la siguiente
propuesta: Usar el código postal
https://es.wikipedia.org/wiki/C%C3%B3digo_postal_espa%C3%B1ol

Los primeros dos dígitos del código postal indican la provincia.
Ejemplo: Madrid es el 28. Además, el código 28000 (o xx000) no se usa,
por lo que si se quiere emplear un único AS para toda una provincia, se
puede usar este código postal.

Si se quiere asignar un AS distinto a cada sitio Hamnet (es lo que
estamos haciendo ahora utilizando confederaciones), se puede emplear el
código postal del municipio. Por ejemplo, mi estación está en Tres
Cantos, código postal 28760.

Dentro de cada provincia, los códigos xx070, xx071 y xx080 están
reservados por correos para usos especiales, por lo que también se les
puede dar algún uso especial en Hamnet de ser necesario.

Finalmente, los dos primeros dígitos del código van de 01 a 52. De esta
manera, quedan los dígitos 00 y 53-99 para emplear otro esquema de
asignación distinto.

¿Qué os parece esta propuesta? ¿Propuestas alternativas?

Estaría interesante llegar a un esquema de asignación en España y
empezar a usarlo.

73,

Dani.

 

me parece un sistema genial.

Los dígitos 00 y 53-99 podrían ser para lo que ahora estamos usando los 655xx

 

Luis

Entiendo que están asignando prefijos al estilo de los DMRID, MCC – zona – usuario

 

Luis

Luis, ¿puedes contarnos cómo se usan estos códigos? Oigo que en DMR y
demás se están usando asignaciones similares, pero no sé los detalles
por no estar activo en estos modos.

Estaría bien ver si se pueden compatibilizar de algún modo estas
asignaciones con las asignaciones Hamnet (quizá como propones tú).

Dani

La verdad es que sería lo suyo. Unificar la identificación de los hams con un modelo único.

En su momento ya planteé unifirmar la VoIP interna a MCCYXXX en vez de como se hace ahora.

 

Así tendríamos una id única para identificarnos en los nuevos sistemas

Además el actual sistema de VoIP a mi entender no es muy escalable.

 

Alex

en DMR se usar MCC – número de región – id

siendo id un número secuencial que te dan cuando te registras, yo fuí el número 14 en registrarme por EA5

así yo soy EA5IDN -> EA = 214, 5, 014 -> 2145014

 

Este número se usa en las redes DMR-MARC, DMR+ y BrandMeister

 

Luis

En mi opinión bastaría con tener un AS por distrito y de ahí un “edge router” que intercambiase rutas BGP con el resto de AS de la red.

Internamente en un distrito bastaría con tener OSPF y no sería necesario utilizar BGP.

 

Este “edge router” podría sumarizar las rutas de ese distrito y así ahorrar espacio en las tablas ARP

Es una propuesta que, como digo la llevo escrita desde hace tiempo

 

Alex

tres opiniones/reflexiones:

– Yo dejaría lo que está tal y como está, ya que ambas numeraciones coexisten perfectamente

– Vamos a ver cómo lo están haciendo los que ya han migrado antes de inventarnos nada

– Molaría tener un último dígito propio para poder inventarnos 9 ASs y poder jugar sin necesidad de complicar mucho las cosas (como funcionan los APRS SSID)

 

Luis

Pues la verdad que si se pudiera hacer compatible como indica Luis y además con el sistema de los modos DMR y demás, seria la bomba.

 

Pero no se si tanta integración será posible.

 

Miguel

Unificar las identidades sería algo genial.

¿posible? Si se logra coordinacion entiendo que si. Pero como vengo diciendo desde hace mucho tiempo. La radioafición ha cambiado y ahora ya no vale con “improvisar” crear aquí ,deshacer allí. Hay que tratar estas cosas de forma más seria.

 

En mi presentación del año pasado de Iberradio ya lo comentaba (ver www.slideshare.net/ssppcc) hay que planificar, diseñar y escrbir antes de pasar a la acción.

 

He visto otros proyectos en los que los “amos” (aka sysadmins) hacen y deshacen a su antojo sin:

 

– Comunicar nada a los usuarios

– Sin documentar la infraestructura

– Sin dejar opinar a los usuarios

 

Consecuencias:

 

– El usuario está perdido

– El usuario un día le funciona una cosa y al día siguiente no

– Malestar, disputas, etc…

 

No hay que llegar al extremo de tratar esto como si de un proyecto empresarial se tratase pero, lo que estamos montando requiere de mayor planificación que antaño, y requiere de tareas de las que el “radioaficionado de a pie” no está acostumbrado

 

Ya no vale improvisar, ahora hay que planificar y documentar.

 

 

Perdón por el “toston”.

 

Alex

Esta propuesta tiene sentido si cada distrito implementa esta
arquitectura de red. Tiene sus ventajas e inconvenientes. El primer
inconveniente que veo es que el distrito depende de que su edge router
no se caiga.

También, y lo que creo que es más importante, creo que hay que dejar
abierta la posibilidad de que el que lo decida pueda experimentar con
cualquier tipo de protocolos y sistemas de routing. Con esta propuesta,
fuerzas a todo el distrito a estar en una misma red OSPF.

De todas formas, tu propuesta es válida y compatible con todo lo demás.
En Austria usan algo parecido (creo, mi Alemán no da para tanto). Si un
distrito quiere establecer una red OSPF para todo el distrito, se puede
usar 00×000, con x el número del distrito. Por supuesto, esto no obliga
a que todos los sitios del distrito participen en esta red, pudiendo
usar otros protocolos de enrutamiento. También se puede hacer una red
OSPF para una provincia, usando el código xx000, donde xx es el código
de la provincia.

 

Dani

 

El 18/05/16 a las 11:15, n0p [Luis Bernal] escribió:
> tres opiniones/reflexiones:
> – Yo dejaría lo que está tal y como está, ya que ambas numeraciones
> coexisten perfectamente
> – Vamos a ver cómo lo están haciendo los que ya han migrado antes de
> inventarnos nada

Completamente de acuerdo. Esto de los AS de 32 bits salió hace meses y
yo decidí dejarlo como está porque es menos trabajo y de momento no nos
hacen falta en EA. Además, el soporte en HamnetDB no era bueno (ahora
parece que no hay problemas).

Parece que los que más se están moviendo a 32 bits, que son los
Holandeses, lo hacen por razones “políticas” (las relaciones entre
Holanda y Alemania a veces no son demasiado buenas en estos temas de 44net).

Discutir esto ahora es porque ha salido el tema y para tener algunas
ideas creadas de cara al futuro.

Dani