apadrinaments
network figures & facts
| Nodes | 69.138 |
|---|---|
| Working | 37.562 |
| Planned | 22.165 |
| Inactive | 7.674 |
| Testing | 696 |
| Building | 499 |
| Reserved | 458 |
| Dropped | 84 |
| Enllaços Sensefils | # | kms. |
|---|---|---|
| ap/client | 35.722 | 58.195 |
| Enllaç P2P | 3.120 | 14.884 |
| desconegut | 2 | 70 |
| Total | 38.844 | 73.148 |
Qui està connectat
Plantejament d'utilització d'elements ubiquiti a supernodes
Bones,
Ja hi ha qui fa servir productes Ubiquiti com a sustitut de les radios convencionals aprofitant els nous trastos Ubiquiti.
El problema d'una implementació manual i totalment personal es que tothom fa el que lo sembla.
Un exemple mencionat es el de possar la ubiquiti en mode bridge, possant-li una ip 172.xx amb una mascara /29 (la /29 compren rb1-ub1-ub2-rb2); però aixó te uns problemes.
1) Les 172.xx no s'estenen (es filtrada pel BGP) així que ja ens podem oblidar de graficar el ubiquiti o de poder accedir al mateix sense fer un nat al rb.
2) L'aplicació dona un /30 al enllaç, per tant o tens que tocar-lo a posteriori o estas ocupant un espai diferent que pot afectar a altres coses.
La proposta que faig la he fet servir per fer un Hotspot, fent servir Ubiquiti com a radio i la rb fa tot lo demés (dhcp, routing, nat, hotspot); el mateix es pot fer amb un enllaç, on l'ubiquiti solament te una IP de gestió publica i un bridge que conecta directament la interface wi-fi amb la rb.
script rc.poststart a la ubiquiti posada en mode router:
#!/bin/sh
VLAN_ID=3
vconfig add eth0 $VLAN_ID
brctl addbr br_vlan$VLAN_ID
ifconfig ath0 0.0.0.0 up
ifconfig eth0.$VLAN_ID 0.0.0.0 up
brctl addif br_vlan$VLAN_ID eth0.$VLAN_ID
brctl addif br_vlan$VLAN_ID ath0
ifconfig br_vlan$VLAN_ID 0.0.0.0 up
Pros i contres:
Pro:
1) La ubiquiti no intervé en el routing, solament fa l'enllaç sense fils, tot ho segueix fent els routers.
2) La ubiquiti es accesible des de guifi.net per tant apart d'administrar-la la podem graficar.
3) Podem fer servi les ubiquitis amb el seu firm original i segurament donar-li soport al aplicatiu.
Contra:
1) Necesites possar l'script a la Ubiquiti
2) Fas servir un mateix cable fisic per tenir 2 xarxes logiques.
- El blog de SGaleano
- 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
knoppix ja veig que quant els
knoppix ja veig que quant els comentaris no t'agraden els esborres amb les seves respostes...
si el cometari es meu per tan el puc borrar no?i tambe
le borrat per que ja o tinc clar,de totes maneres el teu sisitema tambe fa servir dos ip's a la mateixa xarxa,per tan tambe es barrejan ip's crec que el millor es el firm d'en miquel que fa enrutament...
a part de com que contestes amb to despactiu molts cops ....be ja et coneixem...
knoppix dexa-ho ja estas
knoppix dexa-ho ja estas barrejant peres i pomes, no son unides les dos subnets, estan en vlans separades: es.wikipedia.org/wiki/VLAN
Virtual node amb l'OLSR
Recuperant l'esperit constructiu... i tot i que potser no hi té massa a veure
Al battlemesh el desenvolupador de l'OLSR va parlar (molt per sobre) d'una implentació futura per a aquest protocol d'enrutament que anomenava Virtual Node i consistia en, no sé com, aconseguir que totes les màquines d'una mateixa ubicació funcionessin amb la mateixa ip. Per a l'OLSR, i la xarxa del Pla de Bages :), això seria una gran millora ja que els enllaços entre trastos dins del supernode no comptarien alhora de fer el càlcul de rutes i faria més fàcil que es tries la ruta "correcte"
No crec que serveixi de res aquest comentari però aquesta configuració que proposes m'hi ha fet pensar...
Els que enteneu mes
Els que enteneu mes ¿podrien explicarnos millor com fer-ho per no cagarla?
MEA CULPA ja que jo soc el que fa fotre el merder amb les ips duplicades i per aixo demano disculpes a tot aquell afectat per el meu desconeixemen.
Crec que es mes constructiu apendre dels errors i demanar ajuda a els que saben el que tocan, el problema hi es cuan el que sap mes en lloc de buscar solucions ajudan al que no sap explicanli que i com fer-ho es renta les mans (teniu de tenir en conte que tots no sabem tant).
Es tindria de procurar de adaptar la forma de treballar actualment dins de guifinet amb les mikrotiks interconectades amb qualsevol aparell d'ubiquiti, ja que no sempre es te posibilitats de ampliar una mikrotik sigui per el que sigui.
Salutacions
Abans de posar cap element en
Abans de posar cap element en producció, i més si no es domina del tema, s'hauria de provar en un indret més petit, per evitar problemes com els que es van tenir. I ho dic amb ànims de millorar, no de destruir ;).
Penseu que d'aquesta xarxa hi tira molta gent, gent que ho fa servir perquè s'en refia i no es poden permetre errors d'aquest tipus, perquè aleshores tot va malament.
S'han intentat fer tallers per tal d'explicar tot això i més, a les llistes hi ha gent que s'està trencant les banyes en les seves estones lliures i que com a hobby, desenvolupen la web, etc etc etc. S'ha proposat de fer un taller perquè tot aquell que tingui un interés en poder donar suport a la web a nous elements com el que demanes, ho pugui fer ell mateix sense haver d'esperar a que ningú altre ho faci per ell. Recordeu que si ens anem passant el mort, al final no es fa res.
És molt fàcil demanar i passapalabra, i a l'hora de que es vulgui implementar qualsevol cosa, tothom ho pot fer. No hi ha res tancat, ni el que hi ha ara és el millor, sinó el més pràctic i el més testejat. Es veritat que s'hauria de fer aquesta adaptació a la web, però per a això primer s'ha d'ensenyar a gent que vulgui fer aquest desenvolupament, a saber fer-ho sense xafar res, que sinó ens pot passar com fins ara.
La forma que planteja el Sebastiàn està bé, però a mi no m'agrada perquè ens pulim adreces públiques 10.x.x.x quan en podriem fer servir del tipus 172.x.x.x com fins ara, l'únic que canviant la màscara de xarxa per una un índex més elevat. Es veritat que segons a on no es podran llistar, però si hi ha un servidor de gràfiques acada zona OSPF, bé te accessivle aquestes adreces 172..x.x.x i per tant, es poden graficar.
Si es fa amb vlan, s'ha de tenir ben clar el que s'està fent, perquè costa una mica d'imaginar, realitzar esquemes i posar-ho en marxa.
Per lo demés, aviam si algun dia en comptes de veure els típics missatges de "s'hauria de fer això....", "algu sap que passa en aquest node", "no tenim senyal", etc etc etc, es canvien per "s'ha afegit aquest nou aparell a la web amb suport..", "s'ha solucionat aquest incident..", "no teniem conexió però ens hem mogut i ho hem solucionat", etc etc etc. Ser una mcia més autònoms entre tots erò alhora col·Laborant entre tots, per així poder seguir creixent.
Salut!
Joan Gaudes
Amb sembla molt be!
el fet de col.laborar i ser positiu, no fer comentaris despactius que l'unic que fan es que la gent es cremi i pasi de col.laborar.
be en quan el tema de fer desenvolupament de la web per la meva part i crec que per la part de molts de les terres gironines estem
disposat a aprendre,l'únic problema que i veig es la distancio per tant podriem fer cursos a distancia,via xat,web o com voleu ...
crec que serviria també per mol-te gent que també esta a distancia.
es podria quedar a unes hores per exemple el vespre i tindre un canal xat expres per tocar aquest tema ...
be es una idea ...
SAX!!
Sobre les 10.xx: son per
Sobre les 10.xx: son per obtenir access a tots els aparells de la xarxa que tinguin IP, sempre dependents d'un node amb l'enrrutament dinamic.
Sobre les 172.xx son les utilitzaces per fer els enllaços p2p, en aquest cas la el enllaç es fa entre una rb i la seguent independentment del hardware que hi ha en mig.
Fer servir zones OSPF solament comença a tenir sentit en zones que no conecten ni podrán conectar mai amb altres zones, tots els demes casos (la majoria) obliguen a no trencar l'as-path fent servir BGP.
Fer servir les 172 per tenir administració a un trasto perd el sentit i mes si no quant la majoria d'elements de la xarxa si tenen routing estatic solament tenen una ruta a la 10.0.0.0/8; a mes no es el seu objectiu, l'objectiu es tenir un adressament independent del node (neutral i no extendre'l).
Com sempre es IMHO, pero es tindrá que fer d'una sola forma, pq si cadascú ho fa a la seva ja sabem com acaba una xarxa comú.
L'idea no es que les persones entenguin que fa una vlan, si no que els trastos s'entenguin, pq si aquest fos el cas parlariem de paraules no de rutes :)
Serviria per connectar una RB+ubiquity com a AP?
Hola Sebastian,
Volem ampliar una RB532 amb una nanobridge.
De moment hem de fer un enllaç punt a punt and dos nanobridge 5, una d'elles conectada a la RB pel port ethernet.
RB+Nanobridge ---->nanobridge (darrera la segona nanobridge no hi ha cap RB) suposo que es semblant a la teva ideia de crear un hotspot.
No em queda clar com posar la configuració a la web de les nanobridges, ni com afegir a la web el enllaç RB+nanobridge
Fernando
KISS (*)
No hi estic d'acord. Crec que és molt més fàcil d'aplicar i entendre si es fa servir 172.x.x.x/29, i fer un NAT d'una 10.x.x.x per cada Ubiquity:
Pros:
1) Igual que com tu dius, la ubiquity no intervé en el Routing
2) Igual que com tu dius, la ubiquity és accessible directament i es pot graficar.
3) Igual que com tu dius, es fa servir el firm original.
4) Al contrari del teu, no cal posar script.
5) Al contrari del teu, no es fa servir el mateix cable per 2 xarxes.
6) Al contrari del teu, més fàcil d'entendre/inplementar per part d'usuaris amb menys coneixements que els teus. Ja es prou complicat d'entendre per un noob com funciona guifi, que a sobre ho tinguem que complicar gratuitament amb VLANs i scripts.
Cons:
1) Algun hi haurà ... però comparat amb el que proposes, no en se veure cap.
(*) KISS --> http://en.wikipedia.org/wiki/KISS_principle
quin problema hi ha
si es fa guifi.net/node/30502 amb 10..*.*.* ok fa servir dos rangs el que no acabo dentendra amb 172.*.*.*/29 es.wikipedia.org/wiki/M%C3%A1scara_de_red
son 8 ip's no com les posaries?
172.0.0.1 rb
172.0.0.2 trasto n
172.0.0.3 trasto n
172..0.0.4 rb
men sobren quatre?
Gracies Crack
Te'n sobren 2, perquè et
Te'n sobren 2, perquè et falta la IP de xarxa i la de broadcast ;)
ok i quines serian
la IP de xarxa i la de broadcast
mmm, m'agrada, potser per
mmm, m'agrada, potser per enllaços a partir de la ether2 está be.
Com ho faries per fer-lo si la ubiquiti esta conectada al ether1, que es a la vegada membre del bridge wLan/lan i on tb sota la ether1 hi ha clients amb 10.
Ho comento pq amb el sistema WDS actual no es barrejen els dos dominis de broadcast, si es fa un bridge si que es mesclaran, per tant si fas un enllaç de dos nodes amb la ether1, tindrás com a resultat que els dhcp es mesclen. Es el que faig amb las vlan, fer independent el canal logic sobre el fisic, per exemple ens permitiria mes de 2 enllaços amb ubiquitis amb una rb532/rb600/rb433 que crec que aixó conforma una considerable part del parc de mikrotiks que hi ha a guifi.net
Joan com pots fer 8 enllaços amb ubiquitis amb una rb600 existent?
Com ho faries per fer-lo si
Miraria de connectar-lo a la ether2, si no es pot, ho faig a la ether1 i asigno la 172.x.x.x a la ether1.
Tens raó, i no hi havia caigut. Per tant, s'ha d'evitar connectar dues ether1 a les ubiquity en 2 routers on que enllacin amb PtP i que al mateix temps tinguin el DHCPserver activat a la wLan/Lan i que hi tinguin APs a la wlan1. Una alternativa: parar el DHCPserver si no cal, o potser desfer el wLan/Lan si no hi ha cap trasto (server) penjat de la ether1. I una altra: amb firewall (ebtables) bloquejar el DHCP als ether1 (no he comprovat si el RoS te/aplica ebtables).
Si vols fer això, com a mínim necesitaras un switch, perquè no poses una RB750 o qualsevol altre trasto d'aquests que estan sobre els 50€? Tampoc pots plantejar posar 4 Ubiquitis en un sol ethernet d'una RB532. Conta que les Ubiquitis et tiren 60Mbps facilment, multiplica-ho per 3 i posa-ho a un sol ethernet, ni el ethernet dona prou ni la RB532 pot moure tans Mbps.
En un supernode, si es fan millores/canvis i es posen 3/4 Ubiquities, el pressupost dona per alguna RB que tingui un bon grapat d'ethernets. Quin sentit te fer enllaços amb més ample de banda si el router que els gestiona no te capacitat per moure tants Mbps? Sobretot tenint RB que valen 4 duros i poden fer la feina.
Compraria 2x RB750G o 2x RB450 i les conectaria a un ethernet de la RB600. 8 enllaços amb ubiquity et costaran (nomes contant una banda, i enllaços curts) un minim de 550-600€. Les RB que necessites costa sobre els 100€. Però el millor és que ho tens escalat, tens mes Mhz (CPU) per Mbps que pot moure el supernode.
Un exemple real (RB600 + RB750 + 3x NanoBridge): http://guifi.net/node/26312
Cadascú que ho fagi com vulgui mentre es respecti el routing, l'adreçament, etc.
Mikrotik SXT 5HnD
Seria todo igual para las nuevas Mikrotiks SXT? O estas ya no requieren que se meta una RB 750 entre medio?
Saludos