apadrinaments
network figures & facts
| Nodes | 69.133 |
|---|---|
| Working | 37.563 |
| Planned | 22.163 |
| Inactive | 7.669 |
| Testing | 695 |
| Building | 501 |
| Reserved | 458 |
| Dropped | 84 |
| Enllaços Sensefils | # | kms. |
|---|---|---|
| ap/client | 35.727 | 58.201 |
| Enllaç P2P | 3.120 | 14.886 |
| desconegut | 2 | 70 |
| Total | 38.849 | 73.156 |
Qui està connectat
Usuaris connectats
- titaranya
- sestaferia.net
Proves de BGP en el túnel Bandoler/Espelt
Bé, finalment l'Anoia i Osona ja formen part de dos sistemes autònoms diferents enllaçats per BGP, i que es passen les rutes sumaritzades :-)
En teoria el BGP *hauria* de ser capaç de fer sumaris **automàticament** a partir de la informació de l'IGP que tingui darrera, en aquest cas OSPF. Això seria l'idoni de cara a reduïr taules de rutes... però no he trobat la manera de fer-ho amb el quagga/zebra (els routers de Cisco ho poden fer). Crec que està per implementar. Una cosa així seria el camí per on anar de cara a reduir finalment la taula de rutes amb el mínim esforç humà.
Per descomptat les rutes estàtiques que hi havia abans en les ràdios penjades a banda i banda del túnel (10.145.2.1 i 10.138.25.65) ja estan eliminades, de manera que tot va dinàmic. Espero que això serveixi de precedent per si algú altre vol començar a fer expedicions mineres i expandir la xarxa via Internet ;-)
De moment hi ha els sumaris entrats a mà a banda i banda. De forma esquemàtica, les comandes claus són:
(Bandoler) bgpd.conf
aggregate-address 10.138.0.0/15 summary-only
aggregate-address 172.25.0.0/16 summary-only
redistribute ospf
(+ info del numero d'AS, neighbour BGP -> Espelt, etc)
(Bandoler) ospfd.conf
redistribute bgp
I a l'espelt, una cosa així:
(Espelt) bgpd.conf
aggregate-address 10.145.0.0/16 summary-only
aggregate-address 172.25.0.0/16 summary-only
redistribute ospf
(+ info del numero d'AS, neighbour BGP -> Bandoler, etc)
(Espelt) ospfd.conf
redistribute bgp
Algunes cosetes amb les que m'he anat trobant:
- Amb les configuracions que fins ara hem anat posant, les xarxes dels routers apareixen com a ASBRs, dins la taula de "AS External Link States". En teoria només haurien de sortir les xarxes obtingudes pel BGP d'altres ASs.
- Els linksysos tenen una ruta 127.0.0.1/8 que no està a les màquines (bandoler/espelt), i la redistribueix... s'ha de filtrar, en teoria a nivell d'IGP (a l'OSPF, vaja).
- Hi pot haver alguna dificultat amb la distribució de l'enllaç punt a punt entre màquines amb BGP cap a dins de l'IGP. Com que les màquines tenen també adreces dins de l'IGP (estil 10.145.x.x, 10.138.x.x) no és problemàtic. La solució passa per afegir l'enllaç del túnel també a l'OSPF (nova network a ospfd.conf de banda i banda), però això ja va a gust del consumidor, a mi se me'n fum que no es pugui accedir a aquestes adreces en concret.
Bé, almenys d'aquesta manera finalment tenim la idea que fa temps que anem mastegant ja en funcionament.
Adjunto configs exactes que hi ha ara rutllant ;-)
TODO, es podria migrar el túnel a gre, per tenir menys overhead, tot i que ara amb l'actualització de la màquina no és tant crític. El que si que acceleraria és el procés d'automatització de tot això.
- El blog de aleix.sole
- Inicieu sessió o registreu-vos per enviar comentaris
Blog de Fundació guifi.net
- Coneixes l’Intelligent Wi-Fi del mòbil?
- 29ª Nit de les Telecomunicacions i la Informàtica: L’esdeveniment clau del sector TIC
- Importància de la sobirania tecnològica per garantir l’accés a Internet en el marc del 75è aniversari de la Declaració dels Drets Humans
- Transformant la Internet amb xarxes lliures, obertes i neutres (FONN)
- La Governança de les Xarxes Comunitàries d’Internet
Comentaris
preguntes! (per veure si ho entenc...)
Ui ui... que interessant ;) a veure si ho he entès bé i li sé treure el suc (de cara a trencar arees dins d'Osona).
Posem que fem BGP entre arees dins d'osona, on:
Les preguntes són:
(En resum, sumaritzant les que hi ha a cada banda...)
Re: preguntes
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 i correccions
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.
Re: thx
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 :P
no es fa pas mai nat...
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ó ;)
Jo ho faria manualment
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.
manualment el que?
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í:
El que si que cal preveure és:
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.
Manualment, les xarxes sumaritzades.
No podem deixar el BGP sense sumaritzar les xarxes.
Si es clar, el BGP ha de sumaritzar
O al menys això entenc que és l'objectiu.
Què vols dir? que el BGP no ho fa?
Si no ho fiques NO
Si no ho fiques NO
:(... uix, aquesta era la 1a pregunta!
... 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?
La sumarització li has d'indicar
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.
ok. entès.
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...
Eliminar les 172.x.x.x
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.
ui... aquest m'havia passat per alt!! (sobre les 172.x.x.x...)
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.
Algunes primeres consideracions
El fet que tots els router siguin ASBR és pel fet que retransmeten la ruta per defecte. Si es treu les ordre redistribute, deixaria de ser un router ASBR. en els drivers del GiX això ja no passa, doncs els routers únicament envien les ips públiques i impedeix trametre la default. ( Per qui tingui permisos ... ) Est.Serra_Marsal. Pots veure en la configuració de l'OSPF que han desaparegut els redistributes. Al treure'ls també desapareix la 127.0.0.1
En el cas d'un router ABR, el driver genera una configuració semblant a aquesta. En el cas d'un router BGP, la forma de treballar hauria de ser el mateix. Ja miraré de fer un driver per configurar els BGP de forma automàtica. Oest.Anoia_VilaCami_Nord