Hola Ramon,

En primer lloc, un detall: amb el BGP el que fas és comunicar diferents sistemes autònoms, cadascun amb el seu número assignat d'AS, i no àrees OSPF. És un nivell superior, com si diguéssim; OSPF és un IGP, mentre que BGP és un EGP. ({Internal,External} Gateway Protocol)

Dit això, sobre el que comentes: sí, es pot fer perfectament (amb el preu de considerar el que tu anomenes àrea X i àrea Y com a 2 sistemes autònoms diferents i assignar-los un número únic). Els sumaris fets pel BGP i el VLSM (considerar màscares variables, /27, /26, etc.) són precisament el que ens ha permès seguir utilitzant IPv4 a Internet evitant que les taules de rutes creixin massa (com ens interessa aqui).

L'agrupació de xarxes la fa quan pot. Per exemple, caldria posar  10.138.0.0/23 dins la configuració del BGP de l'ASBR (autonomous system border router) de "l'àrea Y", així:

aggregate-address 10.138.0.0/23 summary-only

Crec que és perillós dir-li una aggregate-adress que té alguna subxarxa FORA de l'AS. Com passaria si per exemple poséssim 10.138.0.0/15 a banda i banda, això NO s'hauria de fer. Per tant el preu seria:

a) Buscar un dimoni d'enrutament que sigui capaç d'autosumaritzar

o bé

b) Controlar els sumaris "a mà" (llegint-ho directament de la pàgina "networks" de guifi.net) en aquells casos en que no hi hagi subxarxes d'una zona repartides FORA d'aquesta zona.

Per exemple, si tinguéssiu 10.138.0.0/24 a Gurb i dins l'AS de l'Anoia hi hagués la 10.138.0.0/27, els routers de l'Anoia probablement tindrien un problema, perquè acabarien amb dues entrades a la taula de rutes: la 10.135.0.0/15 (via Osona, redistribuida pel BGP) i la 10.138.0.0/27 via on sigui, redistribuida per l'OSPF.

És important notar que al BGP no li importa que l'IGP (ospf en aquest cas) tingui o no una xarxa que haguem introduït nosaltres a mà dins la config, bgpd.conf, si li hem dit que faci l'agregació o li especifiquem la xarxa via "network", ell l'anuncia igualment als seus veïns.

Sobre el filtratge, s'hauria de poder fer, però encara ho he d'explorar. Ho he provat amb "no network 172.25.0.0/16", de manera que fes el sumari i després no el redistribuís, però no funciona. De moment no veig exactament com manegar-ho, dilluns en parlaré amb el Berenguer, a veure si ho treiem.

Pel tema d'assignació del número d'AS, un comentari (que jo m'he passat per un lloc al fer el túnel xD):

A unique AS number is allocated to each AS for use in BGP routing. The numbers are assigned by the same authorities that allocate IP addresses. AS numbers are currently 16-bit integers. There are public numbers, which may be used on the Internet and range from 1 to 64511, and private numbers from 64512 to 65535, which can be used within an organization.

Thx per la info... estic deduin que el BGP, amb els resums, pot ser la manera efectiva de resoldre el trencament de zones, abans que no pas les arees del OSPF.
Jo crec que el moment d'implementar coses d'aquestes pot ser amb els nous troncals a 5GHz, en principi s'hauria de suportar el BGP... Ja us faré preguntes
En darrer terme, obtenir un llistat agrupat de les subxarxes de cada zona no és problema, l'aplicació ho pot fer.

Una cosa important. No és el cas, perquè l'aplicació ja agrupa com a mínim al /24, després passant a /23 etc... però en l'exemple que poses, 10.138.0./24 en una banda, i 10.138.0.0/27 en l'altre, si el BGP bescanvia bé les rutes, no hi hauria d'haver cap problema. Les taules de rutes ja s'espabilaran. L'unic que no hi pot haver es les ip's "repartides" a cada banda o óbviament, ip's públiques duplicades.

Vull dir que a X pots tenir perfectament
10.138.0.0/24 via X
10.138.0.0/27 via Y
Això ho suporta perfectament qualsevol taula de rutes. De fet la default no deixa de ser una ruta així (0.0.0.0/0). Per entendren's, en el nostre cas com que distinguim internet i els nostres rangs, és com si hem de gestionar diversos tipus de "defaults".

Pensa que abans o després, amb ipv4, els rangs s'et fraccionaran perquè no et serà possible fer prou reserves. A un lloc o altre has de posar el límit a les agrupacions (p.ex. ara parteix de /24 = 8 subxarxes /27 ...) i així anar fent. Com més petits siguin els blocs d'agrupacions de rangs, menys IP's malemeses, però més fraccionament. Però vaja, un cert fraccionament tard o d'hora l'hauràs de tenir, de manera que s'està onligat a prendre un compromís. Voler evitar al 100% el fraccionament amb ipv4 significa directament limitar-te el creixement simplement perquè no tindràs prous adreces.

També és impossible que puguis preveure d'antuvi sempre des d'on es produiràn els enllaços. Sempre hi ha la possibilitat de que allò que hagis previst com a zona, en un futur s'et trenqui entre mig i llavors bé que hauràs d'especificar les /27 que van a parar a cada banda.

Jo ara tinc la impressió que agrupacions /24 o /23 ja son raonables i aprofiten molt bé els rangs. El que dispara molt la taula de rutes son les ip internes d'enllaç (172.25.x.x). Per aixó estaria bé que aquestes només funcionin dins de cada area, en tot cas sempre es podrà fer el salt d'una àrea a l'altra per accedir a aquest tipus d'adreces.

Pensa que abans o després, amb ipv4, els rangs s'et fraccionaran perquè no et serà possible fer prou reserves. A un lloc o altre has de posar el límit a les agrupacions (p.ex. ara parteix de /24 = 8 subxarxes /27 ...) i així anar fent. Com més petits siguin els blocs d'agrupacions de rangs, menys IP's malemeses, però més fraccionament. Però vaja, un cert fraccionament tard o d'hora l'hauràs de tenir, de manera que s'està onligat a prendre un compromís. Voler evitar al 100% el fraccionament amb ipv4 significa directament limitar-te el creixement simplement perquè no tindràs prous adreces.

Totalment d'acord. La gràcia és que si a BGP no li dius res de aggregate-route les rutes es propaguen totes perfectament (sense cap diferència amb tal i com està ara l'ospf), amb el màxim de granularitat. El nivell de, com dius tu, fraccionament de les xarxes es pot controlar a cada peer bgp. Que s'ha de partir el rang per la meitat? Cap problema, es posen sumaris quan es pugui i quan no, no

Per aquest motiu em vaig matar a fer aquell applet java xungo, per poder veure exactament quan realment es podia agrupar un AS en una superxarxa. Però si l'aplicació ja ho controla, collonut!

Pel tema de filtratge... Només caldria anar amb compte que tota l'info viatgi des d'adreces comunes 10.1xx..., és a dir, bàsicament que no es facin NATs agafant les adreces del backbone, cosa que en teoria no ha de passar.
Al Carles em sembla recordar que això de tenir dos rangs distints a tot arreu tampoc li agradava massa, així es podrien reaprofitar un munt d'adreces

Efectivament mai es fa NAT i n'hauriem de defigir. Només cap a les xarxes privades, i òbviament inet. Només el proxy arp en comptats cassos (sino els enllaços AP/Client no funcionarien amb vàries macs), però sense NAT.
Efectivament reutilitzar les 172 estaria molt bé.
No crec que hagis perdut el temps amb el tema de sumarizacions. El moment de fer-ho servir es va acostant, ho haurie4s de considerar com a una aproximació

Ja sé que no estaré en sintonia amb en Ramon, però crec que cada zona a de mirar de no trametre problemes a altres zones.

Així si a dins una zona hi ha una ruta d'un rang d'una altra zona segurament ells no tindran problemes per accedir-hi, però no poden esperar que les altres zones tinguin aquesta ruta perduda i possiblement repetida dins dels seus routers.

La sumarització automàtica no existeix. És impossible de calcular, doncs la sumarització mai pot saber on aturar-se i arribar a sumaritzar fins a la 10.0.0.0/8. Així tots aquests protocols, el que fan és assignar rangs pertanyents a zones (podeu veure-ho en aquesta configuració Oest.Anoia_VilaCami_Nord ) i el protocol d'enrutament si troba alguna xarxa que pertanyi dins d'aquesta la substitueix per aquesta, que és la sumarització.

És perillós posar una xarxa fora de l'AS, realment és una incongruència.

No es un tema de sintonia... no estic segur de que hagis entès la qüestió: No hi ha xarxes perdudes, ni problemes per accedir a altres zones. ni cap inconsistència, ni dins d'una zona s'agafen rutes de rangs d'altres zones.

El funcionament ara és així:

• Hi han rangs generals a les zones "pares" (p.ex. 10.138.0.0/15).
• Quan una zona necessita un subrang perquè té algun trasto que li cal assignació, demana a la pare un rang, el primer que obtindrà és un /24, si ja en tenia i n'estava extenent, obtindrà una /23. Les adreces dins de la zona les assignara dins d'aquest rang fins que s'acabin. Cap altre zona agafa adreces d'aquesta Zona, només n'assigna dins del rang que li pertoca (per això l'exemple que posava en lasker sobre una 10.138.0.0/27 en una zona i una 10.138.0.0/24, en una altra NO es produeix.

El que si que cal preveure és:

1. Que dins dels rangs de les pares (10.138.0.0/15 o les que sigui) hi han fraccionaments i jerarquies. Es a dir, les subxarxes /24 d'una zona no tenen perquè venir totes seguides. Per això és interessant que s'agrupin quan això sigui possible (aquesta era part de la pregunta, si ho sabia agrupar, per ex, quan hi ha la 10.138.0.0/24 i la 10.138.1.0/24 (...) convertir-ho a la /23 i estalviar entrades a les taules de rutes).
2. El Router que dugui el BGP l'hem de poder posar en qualsevol lloc dins de la zona, és impossible preveuree d'antivi on estaràn, i pot ser que dins de la zona hagi de repartir unes subxarxes cap a una banda, i les altres, cap a l'altra.

Pel demés, ficar entrades de l'estil 10.0.0.0/8, 10.138.0.0/15, o les que faci falta a la taula de rutes no deixa de ser, en el nostre cas, el que equivaldria a una "default" (cap a la jerarquia superior) en internet. L'unic que no podem fer servir la 0.0.0.0 simplement perquè es confondrien les defaults de veritat, i les d'internet.

Tenir posada una "default" 10.138.0.0/15" cap a un lloc NO impedeix que dins d'aquest rang, hi hagi altres entrades a la taula de rutes que envien en altres direccions... No sé si m'explico

El que no sé és si el BGP pot fer aquestes agregacions que dèiem per simplificar el nombre d'entrades o no. Si ho fa, això que ens estalviem, si no, ho haurem de posar a través de la aplicació. A la taula networks ara hi tenim la informació de les subxarxes que s'han reservat a cada zona que tingui ràdios.

Manualment seria un cristo. El nombre de subxarxes a gestionar és massa gran.

No podem deixar el BGP sense sumaritzar les xarxes.

O al menys això entenc que és l'objectiu.
Què vols dir? que el BGP no ho fa?

Si no ho fiques NO

... El que volia saber era si per "sumaritzar" s'entenia que era capaç d'agregar les xarxes contigües, solet... Al menys això era el que volia preguntar en el comentari inicial.
Si no ho fa, llavors s'haurà de prevere agregar des de l'aplicació.

Ara m'he perdut... perquè es parla de que "sumaritza" el BGP si igualment se li ha de dir?

Tu vols que et sumaritzi la 10.138.0.0/16, llavors li dius i el sistema BGP ó OSPF quan troba una xarxa dins d'aquest rang la omet i només envia la sumaritzada.

Si hi ha xarxes que no estan dins els rangs de les sumaritzades (que no ho has indicat) s'enviaran igualment. La idea és sumaritzar-les sempre que sigui possible per reduir-ne la quantitat.

De totes maneres, el sistema pot obviar la sumarització i enviar una ruta estàtica, però això limita a re-configurar els routers si s'afegeix un nou rang.

Llavors si volem fer qualsevol agregació de subxarxes, l'haurem d'indicar.
Ummmmm, llavors el que pot ser més efectiu per reduir la complexitat llavors pot ser fer servir una mena de "defaults" a la zona, que en lloc de ser la 0.0.0.0, sigui la 10.x.x.x de les pares...

Deixeu-m'hi posar cullerada.

Ja t'ho he comentat Ramon, i ho fico aquí per a l'Aleix, que m'ha demanat l'opinió, no trobo correcte no redistribuir les 172.x.x.x

Avui per avui, les configuracions impedeixen fer-ho. O més ben dit, molts clients podrien perdre la connexió, ja que estan connectats via nat amb routers connectats a adreces troncals. Jo ho trobaria correcte, sempre que se sàpiga el problema que hi pot haver. I mirar d'evitar connexions de clients finals a adreces troncals.

L'altre problema és poder executar programes de xarxa des dels routers, perquè la IP d'origen de les peticions sempre són les del primer enllaç d'on surt. Així els routers que tenen samba no el podrien utilitzar i així altres programes que podem necessitar. Per exemple obtenir la configuració mitjançant una connexió ftp o qualsevol altra cosa que trobem interessant d'implementar.

No m'havia adonat d'aquest post..., m'havia quedar darrera un altre!
No partim de premises falses o coses que no son!

1.-No es fa servir MAI nat a partir d'una 172.x.x..x. Els unics que fan NAT's son els clients, ho fan respecta a la xarxa privada que pugui tenir un usuari interna a casa seva, i ho fan amb IP pública 10.x.x.x. No hi ha cap servei que es pugui posar a una ràdio que no sigui visible (p.e. un samba, etc).
2.-Les "172.x.x" son adreces adreces que només es fan servir per a subxarxes internes, i no ocupar ip's públiques 10.x.x.x.
3.-No veig cap motiu per fer que les adreces 172.x.x.x trespassin les zones, directament multiplicaria inútilment les subxarxes a trespassar. Si en des d'algun aparell en concret li fes falta , sempre se li pot assignar una ip pública o se li pot fer una ruta adhoc per a aquella ràdio abans que no pas fer la pilota més gran.

Si realment hi haguéssin prous motius perquè les 172.x.x.x trespassin les zones, seria més simple no fer-les servir i absorbir-les dins dels mateixos rangs. Però no és el cas.