BGP, a single /24 and two diverse non-connected exit points

I am starting to see the following scenario more and more as IPv4 space is hard to get, but isn’t.

With ARIN it is still possible to get an IPv4 allotment. Many smaller ISPs qualify for a /24 and can get one if they wait long enough on the ARIN waiting list. a /24 of IPv4 space is the smallest block that 99% of the Internet allows to be advertised on the Capital I Internet. There are filter rules in place that drop smaller prefixes because that is the agreed upon norm.

So what happens if you are an ISP and you have a shiny new /24 but you have two networks which are not connected. Let’s look at our scenario.

The above network have no connectivity between the two of them on the internal side. These could be half way across the world or next door. If they were half way across the world it would make sense to try and get another /24. Maybe they are either side of a big mountain or one is down in a valley and there is no way to get a decent link between the two networks.

So what is a way you can use this /24 and still be able to assign IP addresses to both sides of the network? One way is to use a tunnel between your two edge routers.

Without the tunnel the scenario is traffic could come into network1, but if the IP is assigned on network 2 it will come back as unreachable. BGP is all about networks finding the shortest path to other networks. You don’t have much control over how networks find your public IP space if you have two providers advertising the same information. Some of the Internet will come in Network2 and some will come in Network1.

By running a tunnel between the two you can now subnet out that /24 into two eqal /25s and assign one /25 Network1 and one /25 to Network2 or however you want to. You can make the tunnel a GRE, EOIP, or other tunnel type. If I am using Mikrotik I prefer to use EOIP. If it’s another vendor I tend to use GRE.

Once the tunnel is established you can use static routing, OSPF, or your favorite IGP (interior Gateway Protocol) to “tell” one side about the routes on the other side. Let’s look at a fictional use.

In the above example our fictional ISP has an IPv4 block of 1.2.3.0/24. They have two networks separated by a tall mountain range in the center. It’s too cost prohibitive to run fiber or a wireless backhaul between the two networks so they have two different upstream providers. The ISP is advertising this /24 via BGP to Upstream1 from the Network 1 router. Network 2 router is also advertising the same /24 via BGP to Upstream 2.

We now create a Tunnel between the Mikrotiks. As mentioned before this can be EOIP, GRE, etc. We won’t go into the details of the tunnel but let’s assume the ISP is using Mikrotik. We create an EOIP tunnel (tons of tutorials out there) between Network 1 router and Network 2 router. Once this is established we will use 172.16.200.0/30 as our “Glue” on our tunnel interfaces at each side. Network 1 router gets 172.16.200.1/30. Network 2 router gets 172.16.200.2/30

To keep it simple we have a static route statement on the Network 1 Mikrotik router that looks like this:

/ip route add dst-address=1.2.3.129/25 gateway=172.16.200.2

This statement routes any traffic that comes in for 1.2.3.128/25 via ISP 1 to network1 across the tunnel to the Network 2 router. The Network 2 router then send it to the destination inside that side of the network.

Conversely, we have a similar statement in the Network 2 Mikrotik router

/ip route add dst-address=1.2.3.0/25 gateway=172.16.200.1

This statement routes any traffic that comes in for 1.2.3.0/25 via ISP 2 to network2 across the tunnel to the Network 2 router. The Network 2 router then send it to the destination inside that side of the network.

It’s as simple as that. You can apply this to any other vendor such as Cisco, Juniper, PFSense, etc. You also do not have to split the network into even /25’s like I did. You can choose to have os of the ips available on one side and route a /29 or something to the other side.

The major drawback of this scenario is you will takef a speed hit because if the traffic comes in one side and has to route across the tunnel it will have to go back out to the public internet and over to the other ISP.

#packetsdownrange

Mikrotik Connection tracking and CPU usage

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon
Already a qualifying Patreon member? Refresh to access this content.

FD-IX: Local-pref and default routes

I just finished up an article over on the FD-IX blog about local-prefs, default routes, and Internet exchanges.

https://www.fd-ix.com/uncategorized/local-pref-and-default-routes/

Not everyone on the Internet needs full feeds from their provider. In this case, how does learning routes from an Internet Exchange such as FD-IX benefit you if all you are doing is default routes?

So let’s take a scenario. You are a local hosting company. You don’t provide Internet to customers, you just do hosting of websites and data. You have a couple of providers you are buying Internet from, mainly for redundancy. One of these is primary and the other is a backup. You are doing BGP just because. All you are receiving from these providers is a default route and that is it. Why would you want to receive all these routes from an IX?

What is routing? MANRS

The Internet has over 68,000 publicly visible networks, which means it’s impractical to know about the existence of every other network or how they’re connected. Networks can also appear and disappear, whilst connections are constantly coming and going due to various faults and reconfigurations. This makes it too complex to take manual decisions about how to route packets across the Internet.

Hurricane Electric Route Filtering Algorithm

The following is from http://routing.he.net/algorithm.html . This outlines the criteria HE.NET uses for filtering routes from peers and customers.

This is the route filtering algorithm for customers and peers that have explicit filtering:

1. Attempt to find an as-set to use for this network.
1.1 Inspect the aut-num for this ASN to see if we can extract from their IRR policy for what they would announce to Hurricane by finding export or mp-export to AS6939, ANY, or AS-ANY.
1.2 Also see if they set what looks like a valid IRR as-set name in peeringdb.

2. Collect the received routes for all BGP sessions with this ASN. This details both accepted and filtered routes.

3. For each route, perform the following rejection tests:
3.1 Reject default routes 0.0.0.0/0 and ::/0.
3.2 Reject paths using BGP AS_SET notation (i.e. {1} or {1 2}, etc). See draft-ietf-idr-deprecate-as-set-confed-set.
3.3 Reject prefix lengths less than minimum and greater than maximum. For IPv4 this is 8 and 24. For IPv6 this is 16 and 48.
3.4 Reject bogons (RFC1918, documentation prefix, etc).
3.5 Reject exchange prefixes for all exchanges Hurricane Electric is connected to.
3.6 Reject routes that have RPKI status INVALID_ASN or INVALID_LENGTH based on the origin AS and prefix.

4. For each route, perform the following acceptance tests:
4.1 If the origin is the neighbor AS, accept routes that have RPKI status VALID based on the origin AS and prefix.
4.2 If the prefix is an announced downstream route that is a subnet of an accepted originated prefix that was accepted due to either RPKI or an RIR handle match, accept the prefix.
4.3 If RIR handles match for the prefix and the peer AS, accept the prefix.
4.4 If this prefix exactly matches a prefix allowed by the IRR policy of this peer, accept the prefix.
4.5 If the first AS in the path matches the peer and path is two hops long and the origin AS is in the expanded as-set for the peer AS and either the RPKI status is VALID or there is an RIR handle match for the origin AS and the prefix, accept the prefix.

5. Reject all prefixes not explicitly accepted

Don’t try this at home kids. Automated BGP Optimization

https://radar.qrator.net/blog/as10990-routing-optimization-tale
Conclusion? Do not try to optimize the routes with automated software – BGP is a distance-vector routing protocol that has proved, throughout the years, its ability to handle the traffic. Software, wanting to “optimize” the system involving thousands of members would never be smart enough to compute all the possible outcomes of such manipulation.

Medium WISP Core Network Design

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon
Already a qualifying Patreon member? Refresh to access this content.

Network troubleshooting tools

Recently, there was a thread on the NANOG list asking what were somne favorite network troubleshooting tools. I have taken many of these tools and created the following list.

http://ping.pe/
Simple pingport and dig commands

https://mtr.sh/
BGP Looking glass

https://perfops.net/mtr-from-world
Traceroute from various hosts on the net

http://www.traceroute6.net/
IPV6 tools (ping,traceroute,etc)

https://dnsviz.net/
Carious DNS tools

http://irrexplorer.nlnog.net/
Routing Registry object explorer

https://mxtoolbox.com/
DNS and Mail tools

Internet Routing Registry Resources by j2sw

What is a routing registry?
From Wikipedia https://en.wikipedia.org/wiki/Internet_Routing_Registry
The Internet routing registry works by providing an interlinked hierarchy of objects designed to facilitate the organization of IP routing between organizations, and also to provide data in an appropriate format for automatic programming of routers. Network engineers from participating organizations are authorized to modify the Routing Policy Specification Language (RPSL) objects, in the registry, for their own networks. Then, any network engineer, or member of the public, is able to query the route registry for particular information of interest.

RFC2622 Routing Policy Specification Language (RPSL)

RFC2650 Using RPSL in Practice

RFC7682 Considerations for Internet Routing Registries (IRRs) and routing Policy Configuration

General IRR Information

http://www.irr.net/
Includes links to various registries, FAQs, and other info

https://www.gin.ntt.net/support-center/policies-procedures/routing-registry/ntt-route-registry-frequently-asked-questions/
NTT route registry FAQ

https://www.seattleix.net/irr-tutorial
Seattle Internet Exchange IRR Tutorial

https://archive.nanog.org/meetings/nanog51/presentations/Sunday/NANOG51.Talk34.NANOG51%20IRR%20Tutorial.pdf
NANOG Routing registry tutorial

General How-Tos

https://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html
A Quickstart Guide to Documenting Your Prefixes with IRR. This mainly uses the older ARIN e-mail templates.


Arin Specific

https://www.arin.net/resources/manage/irr/userguide/
Arin’s userguide for working with their IRR

https://www.arin.net/resources/manage/irr/irr-online-implementation
Notes on working with ARINs web-based


Other Regional Registries

African Network Coordination Centre (AFRNIC)
https://afrinic.net/internet-routing-registry

Asian-Pacific Network Coordination Centre (APNIC)
https://www.apnic.net/manage-ip/apnic-services/routing-registry/

American Registry for Internet Numbers (ARIN)
https://www.apnic.net/manage-ip/apnic-services/routing-registry/

Latin American and Caribbean Internet Addresses Registry (LACNIC)
https://www.lacnic.net/innovaportal/file/3512/1/internet-routing-registries.pdf

Reseaux IP Eauropeens Network Coordination Centre (RIPE NCC)
https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-in-the-irr

Tools

https://github.com/6connect/irrpt
A collection of tools which allow ISPs to easily track, manage, and utilize IPv4 and IPv6 BGP routing information stored in Internet Routing Registry (IRR) databases. Some of these tools include automated IRR data retrieval, update tracking via CVS, e-mail notifications, e-mail based notification for ISPs who still do human processing of routing information, and hooks for automatically deploying prefix-lists on routers.

https://www.radb.net/query
The RADB whois server provides information collected from all the registries that form part of the Internet Routing Registry. 

https://github.com/irrdnet/irrd
Internet Routing Registry daemon version 4 is an IRR database server, processing IRR objects in the RPSL format.