Differences

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

--- fuss:networking [2017/02/22 18:30] – external edit 127.0.0.1
+++ fuss:networking [2020/05/16 22:55] – [Determine ISP Address Blocks] office
@@ Line 266: / Line 266: @@
   * ''-Pn'' tells ''nmap'' not to ping and just to connect
   * ''--reason'' will make ''nmap'' explain why a port was considered closed
+====== Determine ISP Address Blocks ======
+Either starting from a hostname, for instance ''tb1060.lon.100tb.com'' by issuing:
+<code bash>
+nslookup tb1060.lon.100tb.com
+</code>
+to determine the IP address, or from the IP address itself (in this case, ''146.185.28.59''), [[http://www.radb.net|RADb]] can be used to determine an ISP's address block.
+First, lookup the IP itself to determine which ISP it belongs to:
+<code bash>
+whois 146.185.28.59
+</code>
+Then, lookup the Autonomous System (AS) number (an ISP identifier code, if you will) of that ISP:
+<code bash>
+whois -h whois.radb.net 146.185.28.59 | grep ^origin
+</code>
+which should output:
+<code>
+origin:          AS29302
+</code>
+There may be more AS numbers for small internet providers that are, in turn, customers of a larger network.
+To make sure that the IP you are after is part of the AS, lookup the AS itself:
+<code bash>
+whois AS29302
+</code>
+and make sure that the ISP is listed.
+The final step is to get all known routes for the AS:
+<code bash>
+whois -h whois.radb.net -- -i origin -T route AS29302 | grep ^route | awk '{ print $2 }'
+</code>
+which should output all IPv4 address blocks allocated to that ISP line-by-line (easy to automate):
+<code bash>
+.185.16.0/20
+</code>
+IPv6 can also be queried in the same way:
+<code bash>
+whois -h whois.radb.net -- -i origin -T route6 AS29302 | grep ^route | awk '{ print $2 }'
+</code>
+and will yield similar results:
+<code bash>
+a01:5a80::/32
+</code>
+====== Solving Issues with PXE Servers not Working with Network Bridges with Spanning Tree Protocol Enabled ======
+A typical scenario of a non-working PXE server is a PXE server that has been set up on a Linux server running virtual machines that automatically join an STP-enabled network bridge once the virtual machine boots.
+The phenomenon is due to STP itself that runs through various stages (''Blocking'', ''Listening'', ''Learning'') before reaching the ''Forwarding'' state. When the virtual machine adds its interface to the STP-enabled bridge, the bridge switches to the ''Learning'' state, where, by default, the bridge spends at least 10 seconds (on Linux). For 10 seconds, the STP-enabled networking bridge will listen to packets and learn the new topology introduced by the addition of the interface. libvirt virtual machines run SeaBIOS as the default BIOS and, at version ''1.12'', the PXE boot code does not wait sufficiently for the bridge to switch to the ''Forwarding'' state and the network interface will not even be configured.
+Cisco routers have a (nasty) hack named ''portfast'' that can be set on a bridge that, when enabled, will skip over the ''Learning'' stage of the bridge and commute directly into the ''Forwarding'' state. Since the bridge will immediately forward packets, the issues with libvirt virtual machines should be resolved.
+In order to resolve the issue, STP can be turned off for the entire bridge:
+<code bash>
+brctl stp br0 off
+</code>
+but that means losing the extra benefits of having the STP protocol.
+Instead, and even better than Cisco ''portfast'', the forwarding delay can be lowered sufficiently for the SeaBIOS PXE boot code to obtain an IP address via DHCP:
+<code bash>
+brctl setfd br0 2
+</code>
+where:
+  * ''2'' is the number of seconds to spend in the ''Learning'' state (default ''10'' seconds).
+On Debian, in case the bridge is configured via ''/etc/network/interfaces'' the following changes can be made to the bridge in order to make the forwarding delay permanent:
+<code>
+auto br0
+iface br0 inet static
+...
+        # Enable STP
+        bridge_stp on
+        # Fix PXE with STP
+        bridge_fd 2
+...
+</code>