Verified Commit 51aecd66 authored by Gio's avatar Gio
Browse files

Fix typo "all routes to all routeRs"

parent 779f87f7
......@@ -530,7 +530,7 @@ But what in detail causes this unwanted behavior? We can find the answer is in +
2001:DB8:9::/64 dev bmxOut_BMX1 proto static metric 1024
---------------------------------------------------------------
We can observe there are two routes towards +2001:DB8:9::/64+ one learned via BGP (the +proto bird+ ones) that have lower metric and one learned by BMX6 (the ones associated to +dev bmx*+) that have higher metric, thus the BIRD routes are always preferred. One could think that the problem could be fixed just by giving to BMX6 more preference but this tentative would just fail because it solves the loop in the BGP->BMX6 direction but it creates the exact opposite loop in BMX6->BGP direction. The classic way to solve this problem on BGP networks usually is to adopt the iBGP setup. In a iBGP setup routers share the same ASN so the exchanges can recognize internal routes when they learn them form other eBGP routers and avoid re-adding them to the kernel routing table. To adopt iBGP solve the problem but with an unbearable cost for an auto-organized mesh network that is that each iBGP router must be configured to establish peering connections to each other router in a setup called _full-mesh_ where every router speaks to all other routers directly <<ref:wkpdbgp>>. At this point, no other solutions then iBGP has been found. I started investigating how iBGP works internally and I discovered that the _full-mesh_ peering is needed because every iBGP router need share the same routing information with all other iBGP routers <<ref:ebgpibgp>>. In our case as BMX6 is a proactive distance-vector routing daemon it already spreads all routes to all routes so I supposed that in our case the iBGP _full-mesh_ setup may be avoided, and empirical tests proved this supposition true. In fact loop is avoided and every host of both BGP and BMX6 networks can successfully reach every host of the whole Guifi.net (both BMX6 and BGP parts).
We can observe there are two routes towards +2001:DB8:9::/64+ one learned via BGP (the +proto bird+ ones) that have lower metric and one learned by BMX6 (the ones associated to +dev bmx*+) that have higher metric, thus the BIRD routes are always preferred. One could think that the problem could be fixed just by giving to BMX6 more preference but this tentative would just fail because it solves the loop in the BGP->BMX6 direction but it creates the exact opposite loop in BMX6->BGP direction. The classic way to solve this problem on BGP networks usually is to adopt the iBGP setup. In a iBGP setup routers share the same ASN so the exchanges can recognize internal routes when they learn them form other eBGP routers and avoid re-adding them to the kernel routing table. To adopt iBGP solve the problem but with an unbearable cost for an auto-organized mesh network that is that each iBGP router must be configured to establish peering connections to each other router in a setup called _full-mesh_ where every router speaks to all other routers directly <<ref:wkpdbgp>>. At this point, no other solutions then iBGP has been found. I started investigating how iBGP works internally and I discovered that the _full-mesh_ peering is needed because every iBGP router need share the same routing information with all other iBGP routers <<ref:ebgpibgp>>. In our case as BMX6 is a proactive distance-vector routing daemon it already spreads all routes to all routers so I supposed that in our case the iBGP _full-mesh_ setup may be avoided, and empirical tests proved this supposition true. In fact loop is avoided and every host of both BGP and BMX6 networks can successfully reach every host of the whole Guifi.net (both BMX6 and BGP parts).
.Relevant snippet of the resulting routing table using the ``smart'' iBGP-like setup.
-------------------------------------------------------------------------------------
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment