Welcome to the Bristol Hackspace Wiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
internet [2016/04/26 12:46]
iwilcox [Plans] Stats on DNS replies/failures/drops is done
internet [2016/04/26 13:12] (current)
iwilcox
Line 21: Line 21:
  
 Gleaned from [[network_outage_logbook|outages]],​ router logs and anecdotes; in roughly worst-first order: Gleaned from [[network_outage_logbook|outages]],​ router logs and anecdotes; in roughly worst-first order:
-  * We have recently seen a period during which we [[network_outage_logbook#​section20160419 |got no DHCP lease for tens of hours]]. +  * We have recently seen a period during which we [[network_outage_logbook#​section20160419 |got no DHCP lease for tens of hours]]. ​ DHCP/DNS on our OpenMesh unit certainly ​seems to [[network_outage_logbook#​section20160422 |cope badly]] with upstream changes in routing. ​ This may be a problem just on this one unit, since there were anecdotal reports that service was still available at least some of the time via ''​BVStudio''​ access points ​during both outages
-  DHCP/DNS on our OpenMesh unit seems to [[network_outage_logbook#​section20160422 |cope badly]] with upstream changes in routing. ​ This may be a problem just on this one unit, since there were anecdotal reports that service was still available at least some of the time via ''​BVStudio''​ access points. +  * BW's service is not hospitable to long-lived connections without extra measures:
-  * BW's service is not hospitable to long-lived ​outbound ​connections without extra measures:+
     * BW appears to dynamically choose its own upstream PoP, and every time that changes it'll break all existing sessions. ​ (There are workarounds like ''​keepalived''​ for this sort of problem, but BW doesn'​t appear to use them.)     * BW appears to dynamically choose its own upstream PoP, and every time that changes it'll break all existing sessions. ​ (There are workarounds like ''​keepalived''​ for this sort of problem, but BW doesn'​t appear to use them.)
-    * It appears there are several layers of NAT between us and BW, and we share with probably several hundred other clients, meaning ​we're very prone to NAT table capacity ​exhaustion and stale entries:+    * It appears there are several layers of NAT between us and BW, and we share with probably several hundred other clients, meaning ​connections may need frequent keepalives ​to maintain their slots in upstream'​s fixed-capacity, most-recently-used NAT tables:
       * To exercise an acceptable level of centralised control over our internal network we have to use our own range behind the single IP we get from BW, so we must to do NAT ourselves.       * To exercise an acceptable level of centralised control over our internal network we have to use our own range behind the single IP we get from BW, so we must to do NAT ourselves.
       * BW itself is obviously NATing us (10.x.x.x is not a routable range).       * BW itself is obviously NATing us (10.x.x.x is not a routable range).
       * Even when we have a long period under the same PoP, there are often several hops through other private IP ranges before our packets reach the Internet.       * Even when we have a long period under the same PoP, there are often several hops through other private IP ranges before our packets reach the Internet.
     * For connections passing through our router, these problems could be worked around by running our own VPN between the router and some other point (our Mythic Beasts VPS, or a commercial VPN provider, and/or an IPv6 tunnel broker supporting AYIYA or similar).     * For connections passing through our router, these problems could be worked around by running our own VPN between the router and some other point (our Mythic Beasts VPS, or a commercial VPN provider, and/or an IPv6 tunnel broker supporting AYIYA or similar).
-  * BW's service is not hospitable to inbound connections (including UPnP often used by peer-to-peer and video calling) without extra measures:+  * BW's service is not hospitable to inbound connections (including ​those negotiated using UPnPoften used by peer-to-peer and video calling) without extra measures:
     * every unit in our route that performs source NAT (see above) would need an exception, which BW may or may not support     * every unit in our route that performs source NAT (see above) would need an exception, which BW may or may not support
     * our PoP is not stable (see above)     * our PoP is not stable (see above)
Line 50: Line 49:
     * Can't really say a VPN improved things unless we have some stats on TCP connection reliability before and after. ​ To do this properly (accounting for NAT drops) we should probably hold connections to the VPS open at a range of keepalive intervals, and log stats on their uptimes.     * Can't really say a VPN improved things unless we have some stats on TCP connection reliability before and after. ​ To do this properly (accounting for NAT drops) we should probably hold connections to the VPS open at a range of keepalive intervals, and log stats on their uptimes.
   * **Verify and establish a fallback uplink**: Give the existing router the means to route via wireless. ​ Lets us verify that ''​BVStudio''​ remains connected when our G11 mesh unit is denying us DHCP, and if so lets us bypass our mesh unit should it misbehave again.   * **Verify and establish a fallback uplink**: Give the existing router the means to route via wireless. ​ Lets us verify that ''​BVStudio''​ remains connected when our G11 mesh unit is denying us DHCP, and if so lets us bypass our mesh unit should it misbehave again.
-    * Grabbed a spare unit from the networking box, installed OpenWrt on it, and will install it (2016-04-28) as client of some selected ''​BVStudio''​ access point besides ours.+    * Grabbed a spare unit from the networking box, installed OpenWrt on it, and will install it (2016-04-28) as client of some selected ''​BVStudio''​ access point besides ours.  ​(Could probably also have used the existing router'​s 802.11bgn radio in [[https://​wiki.openwrt.org/​doc/​recipes/​ap_sta |AP+STA mode]], but don't really want to introduce that complexity unless it's confirmed to be worth it.)
     * Some criteria and a mechanism for switching routes will be needed after that, so it relies on "​monitor more things"​ above.     * Some criteria and a mechanism for switching routes will be needed after that, so it relies on "​monitor more things"​ above.
   * **Establish an experimental VPN and get some volunteers to try it**: permits inbound connections,​ and lets us confirm whether we can maintain stable/​reliable connections despite our dynamic PoP.   * **Establish an experimental VPN and get some volunteers to try it**: permits inbound connections,​ and lets us confirm whether we can maintain stable/​reliable connections despite our dynamic PoP.
Print/export
QR Code
QR Code Hardware (generated for current page)