Bgp » Historial » Revisió 2
Revisió 1 (Agustí Moll Garcia, 16-04-2011 09:10) → Revisió 2/3 (Agustí Moll Garcia, 16-04-2011 09:35)
h1. Apunts Bgp #Apunts sobre BGP h2. Escenari ##Escenari Disposo del següent escenari: * - Node MANET amb GSF (routerstation2): 10.229.193.6 * - Node MANET amb GSF (routerstation1): 10.228.193.4 / 10.0.1.4 * - Virtual amb openWRT (prova1): 10.0.1.2 / 10.0.0.2 * - Virtual amb openWRT (prova2): 10.0.0.3 La conexió física és la següent: RS2 ----- RS1 ----- prova1 ----- prova2 Tant prova1 com prova2, representen supernodes de guifi en infraestrucutra. RS1 representa un node MANET frontera entre el núbol i guifi. **L'objectiu és que prova2 vegi RS2 mitjançant una instància BGP publicada per RS1 a través de prova1** RS2 i RS1 ja és veuen mitjançant BMX h2. Configuració ##Configuració BGP 1. Primer instal·lem quagga en RS1 + prova1 + prova2 @opkg {{{ opkg install quagga quagga-bgpd quagga-vtysh@ quagga-vtysh }}} 2. Configurem /etc/quagga/zebra.conf <pre><code class=`schema`> {{{ interface eth0 ! access-list vty permit 127.0.0.0/8 ! access-list vty deny any ! ip forwarding ! line vty ! access-class vty </code></pre> ! }}} Afegim totes les interfaces de cada màquina.... h2. 3. Configurem /etc/quagga/bgpd.conf 3.1 RS1 <pre><code class=`schema`> {{{hostname rs1 hostname rs1 router bgp 400 bgp router-id 10.0.1.4 network 10.228.193.6/32 neighbor 10.0.1.2 remote-as 200 </code></pre> }}} 3.2 prova2 <pre><code class=`schema`> hostname {{{hostname prova2 router bgp 300 bgp router-id 10.0.0.3 neighbor 10.0.0.2 remote-as 200 </code></pre> }}} 3.3 prova1 <pre><code class=`schema`> hostname {{{hostname prova1 router bgp 200 bgp router-id 10.0.0.2 network 10.0.0.0/24 network 10.0.1.0/24 neighbor 10.0.0.3 remote-as 300 neighbor 10.0.1.4 remote-as 400 </code></pre> }}} * - `router bgp` -> El nom del AS * - `network` -> La xarxa a publicar * - `neighbor` -> Els veins amb qui ens comuniquem <pre><code class=`schema`> /etc/init.d/quagga start </code></pre> {{{/etc/init.d/quagga start}}} ##Proves h2. Proves Des de prova2: <pre><code class=`schema`> ip {{{ip route show 10.228.193.6 via 10.0.0.2 dev eth1 proto zebra 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.3 10.0.1.0/24 via 10.0.0.2 dev eth1 proto zebra 192.168.10.0/24 dev br-lan proto kernel scope link src 192.168.10.3 10.3.3.0/24 dev eth1 proto kernel scope link src 10.3.3.1 172.20.0.0/14 via 10.0.0.2 dev eth1 proto zebra 1.0.0.0/8 dev eth0 proto kernel scope link src 1.1.1.1 default via 192.168.10.1 dev br-lan </code></pre> }}} Com es pot veure, des de prova dos veiem 10.228.193.6, que és la IP de RS2, per tant el recorregut dels paquets seria: @prova2 {{{prova2 ---bgp---> prova1 ---bgp---> RS1 ---bmx---> RS2 @ }}} h2. Implamtació ##Implamtació a GSF Bé,ja Bé, ja hem conseguit que el node MANET frontera sigui capaç de publicar una IP del seu núvol. Però ens queda resoldre la pregunta: Cóm fem això dinàmic? Amb l'aplicació vtysh podem fer el següent per afegir dinàmicament una nova ruta (10.228.193.7/32), i eliminar l'anterior (10.228.193.6/32) <pre><code class=`schema`> vtysh {{{vtysh configure terminal router bgp 400 network 10.228.193.7/32 no network 10.228.193.6/32 end write memory exit </code></pre> }}} Seria el mateix que executar aquesta comanda bash: <pre><code class=`python`> printf {{{printf `configure terminal\nrouter bgp 400\nnetwork 10.228.193.7/32\nno network 10.228.193.6/32\nend\nwrite memory\nexit\n` memory\ne xit\n` | vtysh </code></pre> }}} Mola bastant eh!! Per tant és podria fer un script executat cada X temps (diguem 10 minuts?). Que recullís les IPs vistes mitjançant BMX, i ho publiques al BGP, d'aquesta manera des de GUIFI ens podran veure i enrutar directament cap a nosaltres. I el més important, podrem disposar de varis nodes frontera :-D h2. Referències ##Referències - http://www.quagga.net/docs/quagga.html - http://martybugs.net/wireless/openwrt/quagga.cgi - http://www.mcmcse.com/cisco/guides/bgp_neighbor_process.shtml