Learn about Privex's network

Learn about Privex's network ============================ # Peering with Privex ### If you'd like to learn about peering with Privex (AS210083), please see our [Peering Page](/peering/) # Basic Information ## IP Allocations ### Our IPv4 and IPv6 allocations from Internet Registries (IRR's) Below are the full IP blocks we've been allocated from internet registries such as RIPE. @@LDSEG ip_allocations_table ### How we allocate this IP space We split this IP space up into smaller blocks, below is a rough guide to how we're using our current allocations: @@LDSEG ip_space_table ## BGP Communities While information about our BGP communities isn't very useful outside of Privex, it can help when trying to sift through our routing table on our route server. For example, you can use `show ip bgp community 0:201` to see all the IPv4 routes we're receiving from [SOL-IX's Route Server](https://www.sol-ix.net/routeserver/). 0:100 - PVX-TRANSIT - All transit BGP routes 0:101 - PVX-TRANSIT-OBE - Transit routes from OBE 0:200 - PVX-PEER - ALL incoming peering prefixes 0:201 - PVX-PEER-SOLIX - SOL-IX peering prefixes only 0:250 - PVX-PEER-DIRECT - Direct BGP peering only 0:300 - PVX-CUST - Our own prefixes # Does Privex use RPKI? **For an in-depth explanation on what RPKI is, how it's set up, and why it's important - please read our article:** <a href="/articles/understanding-rpki/" target="_BLANK">Understanding RPKI (Resource Public Key Infrastructure)</a> On our physical network for AS210083 where we have control over the networking - we both **sign our prefixes** using RPKI ROA's, and **validate/filter incoming prefixes** from our BGP peers.  We sign our prefixes by enabling ROA's on <a href="https://ripe.net" target="_BLANK">RIPE's RPKI Dashboard</a> for all of our IPv4 and IPv6 prefixes, with exact prefix sizes. We validate/filter incoming prefixes from our peers - whether direct BGP peering or from route servers, using the <a href="https://github.com/NLnetLabs/routinator" target="_BLANK">open source (Rust) RPKI validator service Routinator 3000</a>. <img src="https://i.imgur.com/hLuGRb5.png" width="100%" /> The website [Is BGP Safe Yet](https://isbgpsafeyet.com/) ran by Cloudflare - confirms that Privex's RPKI filtering is fully functional, as we're correctly filtering out the (purposely) invalid prefixes which they advertise and fail RPKI validation. ### Our RPKI route maps (route preference based on RPKI status) For reference, here are what the different RPKI states mean: - **Valid** - matches prefixes which have RPKI enabled at their respective RIR (RIPE, ARIN etc.), have the appropriate ASN advertising them, and they are within the prefix size limits specified in the RPKI ROA. - **RPKI not found** - prefixes which do NOT have RPKI enabled - i.e. we cannot find any RPKI ROA's associated with that prefix. - **INVALID** - prefixes which have RPKI enabled at their respective RIR (RIPE, ARIN etc.), BUT, either their **ASN** or the **prefix size** does not match any related RPKI ROA's - meaning these prefixes may be forged by a malicious/misconfigured network. Some networks choose to completely drop any prefixes which are `invalid` - however, some peers may occasionally misconfigure their RPKI, which could cause a lot of problems if we suddenly had to reject a large amount of prefixes from a large network. To be safe, we have a scaling `local preference` based on the RPKI status of each prefix, along with where the prefix came from (SOL-IX route server, STHIX route server, or a direct BGP peer etc.). Prefixes which have `invalid` RPKI are treated equally with the low local preference of `50` - while `valid` and `not-found` have a varying local preference depending on the source of the prefix. <table class="table table-bordered"> <thead> <tr> <th>Peering Profile</th> <th>RPKI Status</th> <th>Local Preference</th> <th>Communities</th> </tr> </thead> <tbody> <tr> <td>SOL-IX Route Server</td><td>Valid</td><td>200</td><td>0:200, 0:201</td></tr> <tr> <td>SOL-IX Route Server</td><td>RPKI not found</td><td>110</td><td>0:200, 0:201</td></tr> <tr> <td>SOL-IX Route Server</td><td>INVALID</td><td>50</td><td>0:200, 0:201</td> </tr> <tr> <td>STHIX Route Server</td><td>Valid</td><td>190</td><td>0:200, 0:202</td> </tr> <tr> <td>STHIX Route Server</td><td>RPKI not found</td><td>105</td><td>0:200, 0:202</td></tr> <tr> <td>STHIX Route Server</td><td>INVALID</td><td>50</td><td>0:200, 0:202</td></tr> <tr> <td>Standard direct BGP peer</td><td>Valid</td><td>210</td><td>0:200, 0:250</td></tr> <tr> <td>Standard direct BGP peer</td><td>RPKI not found</td><td>120</td><td>0:200, 0:250</td></tr> <tr> <td>Standard direct BGP peer</td><td>INVALID</td><td>50</td><td>0:200, 0:250</td></tr> </tbody> </table> # Privex's Looking Glass (Ping/Traceroute from our network + Peer prefix explorer) **Our looking glass is available at the following URL**: <a href="https://lg.privex.io" target="_BLANK">https://lg.privex.io</a> ## Run traceroute's (mtr) from our network <img src="https://i.imgur.com/nezvXMg.png" width="100%" alt="Screenshot of lg.privex.io after running a traceroute to ns2.privex.io" /> When you visit <a href="https://lg.privex.io" target="_BLANK">our Looking Glass</a> website, by default you'll be presented with our traceroute / ping tool. To run a traceroute, simply enter a hostname (e.g. `ns2.privex.io`), a IPv4 address (e.g. `8.8.4.4`), or an IPv6 address (e.g. `2607:5600:c6::333`) and press the **Go!** button. Within 30-60 seconds, the **Results** box at the bottom will update with the traceroute results. The traceroute results contain 11 pieces of data for each "hop" between our looking glass server, and the destination host/IP which you entered: 1. **The first column contains the "hop" number.** 1.1. Hop `1.` is generally Privex's core router 1.2. Hop `2.` is either one of our datacenter's routers/switches (if we need to go via Transit to get to the host), OR the destination network's / destination's transit provider's switch/router (if we're peering with the destination network or their transit provider) 1.3. The hops inbetween hop 2 and the final hop may be within the destination host's network, or they may pass over several different networks 1.4. The final hop, is the destination host which you entered into the host/IP box. 2. **The second column contains the ASN (Autonomous System Number)** of the network which the hop IP address belongs to - if it's known. An ASN is a unique 1-6 digit number that identifies a specific network (ISP), for example AS210083 is Privex Inc. (the company writing this article), AS6939 is Hurricane Electric (one of the largest networks and transit providers in the world), AS15169 is Google, and so on. If you look at the example screenshot above, which shows a traceroute to ns2.privex.io over IPv6, we can see that traffic between our looking glass and ns2.privex.io passes over at least 4 different networks: AS210083 (Privex), AS6939 (Hurricane Electric), AS23404 (Ritter Communications) and finally AS31863 (Centrilogic) Knowing the ASN of each hop is very helpful, since if you can narrow down a fault such as packet loss, to a router hop within a certain ASN, then you'll know to contact the company/individual behind that ASN to rectify the fault. 3. **The third column contains the reverse DNS hostname (if set) and IP address of the hop**. The rDNS hostname of a hop helps to give you some information about a certain router, for example, `core1.se1.privex.cc` indicates that the router is a "core router" operated by Privex, and is located in Sweden (`se1`). Similarly, `100ge8-1.core1.dub1.he.net` tells you the router is operated by Hurricane Electric (`he.net`), is located in Dublin, Ireland (`dub1`), AND that the router likely has a total network throughput capacity of 100gbps (`100ge8-1`). 4. **The fourth column indicates the percentage of ICMP packets which were lost to/from this hop**. Packet loss may indicate that a certain router hop is responsible for network issues - HOWEVER, some routers may simply drop ICMP packets on purpose, usually for performance/security reasons, to prevent pings/traceroutes taking up too many resources on the router. To identify **real packet loss**, the packet loss percentage must be non-zero on the destination: If the routers within a few hops of the destination don't have any packet loss, then the reason for the packet loss is likely the destination server's fault. Where-as if the destination server had a packet loss of 20%, the hop before the server had a 20% packet loss rate, the hop behind that had 15%, but all other hops had 0% (or were clearly purposely dropping ICMP packets) - we could identify the fault most likely lies with the 2nd or 3rd hop before the destination: Hop | Hostname / IP | Packet Loss ----+-----------------------------------------+------------- 1. | core1.se1.privex.cc (185.130.44.1) | 0% 2. | 10.48.28.4 | 80% 3. | ??? | 100% 4. | pl2-15.int.examplecorp.net (10.25.4.15) | 0% 5. | pl2-9.int.examplecorp.net (10.25.4.9) | 0% 6. | de1-8.core.example.com (10.1.0.5) | 15% 7. | de1-2.core.example.com (10.1.0.2) | 20% 8. | some-server.example.org (10.5.8.2) | 20% In the above example trace route, we can see that hop 2 has high packet loss (80%), and hop 3 can't be determined (thus 100% packet loss), but because hop 4 and 5 have no packet loss, we can determine that the packet loss of hop 2 and 3 are irrelevant We can see the destination host (hop 8) has 20% packet loss, and the two core routers behind it have a similiar amount of packet loss (7 has 20%, 6 has 15%), while the packet loss stops at hop 5. This allows us to determine that the cause of the packet loss is most likely a fault with the router in hop 6, or the connection between hop 5 to hop 6. 5. The fifth column contains the number of packets which were sent to that hop. With our looking glass, this will generally always be `10`, as our mtr's are setup to stop after sending 10 packets. 6. The sixth column contains the latest packet's latency (ping) between the server running the test, and the hop 7. The seventh column contains the average latency (ping) between the server running the test, and the hop, based on how many packets were sent, and the latency of each packet test. 8. The eighth column contains the worst (highest) latency (ping) which occurred during the test. 9. The ninth column contains the best (lowest) latency which occurred during the test. 10. The tenth column contains the "Standard Deviation" (stdev), which is a metric for measuring the stability of a host's latency. Lower numbers mean less often/smaller variation in latency, with `<=0.1` being "very good" ping stability, `<=1.0` being "good", `<=8.0` being "okay", # Privex's Public Route Server We operate a public route server using Quagga, which works similarly to [Hurricane Electric's](https://he.net) route server (`route-server.he.net`). You can connect to our route server via either SSH, or Telnet, allowing you to browse our Sweden network routing, including the prefixes we receive from our peers. ### Connecting to the route server <div class="row"> <div class="col-sm-12 col-md-6"> <img src="https://cdn.privex.io/privex.io/img/routeserver-images/rs_ssh.png" width="100%" alt="Route Server via SSH" /><br/> <pre>ssh rs@route-server.privex.io</pre> </div> <div class="col-sm-12 col-md-6"> <img src="https://cdn.privex.io/privex.io/img/routeserver-images/rs_telnet.png" width="100%" alt="Route Server via Telnet" /><br/> <pre>telnet route-server.privex.io</pre> </div> </div> Above are screenshots of the route server after logging in, via both SSH and Telnet. ----------------------- ### Basic route server commands <div class="row"> <div class="col-sm-12 col-md-6"> <img src="https://cdn.privex.io/privex.io/img/routeserver-images/rs_ip_bgp.png" width="100%" alt="View IPv4 prefixes" /> </div> <div class="col-sm-12 col-md-6"> <img src="https://cdn.privex.io/privex.io/img/routeserver-images/rs_ipv6_bgp.png" width="100%" alt="View IPv6 prefixes" /> </div> </div> Using the route server commands `show ip bgp` and `show ipv6 bgp`, you can view **all routing prefixes** that our core router knows. If you type: `?` - you'll see various commands available. You can also type `?` after any command to view the sub-commands / options you can use. For example `show ip ?` or `show ipv6 ?` ### Filtering BGP prefixes using our community groups Our BGP prefixes are organised under the community `0:300` <img src="https://cdn.privex.io/privex.io/img/routeserver-images/rs_bgp_community.png" width="100%" alt="Viewing Privex prefixes via bgp community" /> As shown in the screenshot above, you can view the prefixes we're advertising to our peers, by typing: show ip bgp community 0:300 show ipv6 bgp community 0:300 This will show the IPv4 and the IPv6 prefixes we're advertising, along with their next hop IP address (which IP handles that prefix) See our [BGP Communities](#bgp-communities) section to view the other communities we organise our routes with. ### Filtering BGP prefixes using ASN regex queries Show all IPv4 prefixes we're receiving from AS 6939 (Hurricane Electric), including prefixes they're advertising for third parties (e.g. they're acting as transit for that ASN) show ip bgp regexp ^6939 Show all IPv4 prefixes which are direct to AS6939 (no third-party routes they advertise) show ip bgp regexp ^6939$ Show only internal IPv4 BGP prefixes (empty ASN path), which generally means prefixes that we're advertising ourselves. show ip bgp regexp ^$ Show all IPv6 prefixes that have the ASN 13335 (Cloudflare) **in their path**. This will include routes that we're not receiving from AS13335, instead they're routes which include a hop via Cloudflare AS13335. show ipv6 bgp regexp 13335 Show all IPv6 prefixes we're receiving from AS 13335 (Cloudflare), including routes they're advertising for a third party which they're acting as transit for/ show ipv6 bgp regexp ^13335