Hurricane Electric now requires IRR and filters invalid RPKI

If you are a Hurricane Electric customer you may be receiving e-mails like the following:

Dear ASXXX,

Routing Security Report for ASXXX

Hurricane Electric cares about your routing security.  We filter all BGP sessions using prefix filters based on IRR and RPKI.

This report is being sent to help you identify prefixes which may need either their IRR or RPKI information created or updated 
and to also help you identify possibly hijacked routes you may be accepting and reannouncing.  

Routes with RPKI status INVALID_ASN strongly indicate a serious problem.

IPv4 SUMMARY

Routes accepted: 3
Routes rejected: 3
Routes with RPKI status VALID: 0
Routes with RPKI status INVALID: 0

IPv6 SUMMARY

Routes accepted: 1
Routes rejected: 0
Routes with RPKI status VALID: 0
Routes with RPKI status INVALID: 0

We currently do not have a valid as-set name for your network.  Please add an export line to your aut-num ASXXXX 
that references your as-set name.  For example,

export: to AS-ANY announce your-as-set-name

If you do not currently have an as-set, we recommend you create one named ASXXXX:AS-ALL

Your as-set should contain just your ASN and your customers' ASNs and/or as-sets (not your peers or upstream providers).

What does this mean for you as a service provider? If you use Hurricane Electric as transit or peer with them on an exchange you will need to have ROAs for your blocksand have routing registry objects. I did a tutorial based upon Arin which can be found at: https://blog.j2sw.com/networking/routing-registries-and-you/

In short you need to do the following:

  • Create a mntner object (equivalent of a user account) to give you the ability to create IRR objects in your selected IRR database
  • Create an aut-num to represent your autonomous system and describe its contact information (admin and technical) and your routing policy
  • Create an as-set to describe which autonous system numbers your peers should expect to see from you (namely your own and your transit customers)
  • Create a route/route6 object for every prefix originated from your network
  • Update your peeringdb profile to include your IRR peering policy
  • Generate RPKI https://www.arin.net/resources/manage/rpki/roa_request/#creating-a-roa-in-arin-online

Clarification:
Some folks are confusing having valid ROAs with your router supporting RPKI with route origin validation in real-time. These two are separate things. You create ROA records with your RIR, such as ARIN, which has nothing to do with route validation on your router.

Also, HE is filtering any RPKI INVALID routes. Does this mean they are requiring RPKI? You be the judge.



Bandwidth and the Wireless ISP

This was an older article I had on my blog a few years ago.  Much of this applies still.

Bandwidth is a big hurdle most aspiring WISPs face. The reason is if high-speed alternatives were already in place, the need for a WISP would not be as great.  Sure there are business models in which the WISP can compete with other high-speed solutions. However, the bread and butter of a WISP is going into underserved areas.

You have several options for bringing a connection into your area to re-distribute to your customers. I will outline these and then go into further detail

-Leased Lines (Fractional, T-1, T3, etc.)
-Fiber Optic
-Wireless backhaul
-Cable
-DSL

Leased Lines are the most easily accessible across the United States. However, as more and more providers build fiber it is taking over as the preferred method of connectivity.  Fiber is more “future proof” than a T-Carrier circuit such as a T1 or T3.   Most phone companies can provide t1 service to almost anywhere. This is because T1 service uses the existing copper already at 99% of locations. If you have a phone line you can almost always get t1 service.  Once you go beyond T1 things get a little more complicated.  However, T1 has the ability to do bonding if the carrier and telco support it.  You essentially buy multiple T1s and combine them into a single “pipe”.  This requires the provider to support bonding as well as some special configuration on your routers.

Some questions you should ask your provider/telco.

1.Where is my circuit “homed out of”? This means where does the circuit terminate on the facility end.  You do not want this to be too far. If it is too far your reliability will suffer because you have more distance and equipment to go through.  This raises the likelihood of an equipment failure, backhoe digging something up, & utility poles falling.  The longer the distance also means the “loop charge” will most likely increase.   We will get to that in a moment.

2.There are several types of T1s for our purposes.  Some terms to familiarize oneself with are PRI, channelized, transport, and port fee.

3. Ask your provider to spell out what type of t1 this is.  If you are buying the T1 from a backbone provider such as Qwest, Level3, and others they will typically bundle everything into one package. Ask them to break this down if they don’t.  You want to know what the Local loop charge is, what the port fee is, and what the bandwidth costs.  The local loop is typically what the telephone company charges to deliver the circuit from Point A (their equipment) to Point B (you).  If you are going with a 3rd party, and not the local telephone company, the provider typically becomes the central point of contact for the entire circuit.  This can add a level of complexity when issues arise.

The port fee is a charge normally passed on for connecting to the provider’s equipment.  Say you have a 48 port switch sitting in a CO-Location facility.   For each Ethernet cable you plug in from the telephone company they charge a fee either one-time and/or monthly.  This is just the way it is typically.  One of those “Because they can” charges.  The 3rd charge is the cost of the Internet bandwidth.  A T1 can handle 1.5 Megabits of bandwidth so the cost per Megabit is not as big of an issue because you are not buying in bulk.

4.Ask to see the Service Level Agreement (SLA). If you are unfamiliar with the terms have a consultant look this over.

5.Know where your DMARC location is. This is the spot where the provider’s responsibility ends and yours begins.

6.Ask if the provider can verify with the telco how long the next circuit would take to install. You don’t want to go to order a second circuit and find out the local telephone equipment does not have enough capacity.  This has happened to our clients on many occasions.  This can be a quick process or the telco can take months and months to get around to installing the needed equipment.

References:

http://en.wikipedia.org/wiki/Demarcation_point

http://en.wikipedia.org/wiki/T-carrier

Indianapolis Data Center landscape

We like to refer to Indianapolis, Indiana as an “NFL  City” when explaining the connectivity and peering landscape.  It is not a large network presence like Chicago or Ashburn but has enough networks to make it a place for great interconnects.

At the heart of Indianapolis is the Indy Telcom complex.  www.indytelcom.com (currently down as of this writing).  This is also referred to as the “Henry Street” complex because West Henry Street runs past several of the buildings.   This is a large complex with many buildings on it.

One of the things many of our clients ask about is getting connectivity from building to building on the Indy Telcom campus. Lifeline Data Centers ( www.lifelinedatacenters.com ) operates a carrier hotel at 733 Henry. With at least 30 on-net carriers and access to many more 733 is the place to go for cross-connect connectivity in Indianapolis.   We have been told by Indy Telcom the conduits between the buildings on the campus are 100% full. This makes connectivity challenging at best when going between buildings. The campus has lots of space, but the buildings are on islands if you wish to establish dark fiber cross-connects between buildings. Many carriers have lit services, but due to the ways many carriers provision things getting a strand, or even a wave is not possible.  We do have some options from companies like Zayo or Lightedge for getting connectivity between buildings, but it is not like Chicago or other big Date centers.  However, there is a solution for those looking for to establish interconnections.   Lifeline also operates a facility at 401 North Shadeland, which is referred to as the EastGate facility. This facility is built on 41 acres, is FEDRAMP certified, and has a bunch of features.  There is a dark fiber ring going between 733 and 401.  This is ideal for folks looking for both co-location and connectivity.  Servers and other infrastructure can be housed at Eastgate and connectivity can be pulled from 733.  This solves the 100% full conduit issue with Indy Telcom. MidWest Internet Exchange ( www.midwest-ix.com ) is also on-net at both 401 and 733.

Another location where MidWest-IX is at is  365 Data Centers (http://www.365datacenters.com ) at 701 West Henry.  365 has a national footprint and thus draws some different clients than some of the other facilities.  365 operates Data centers in Tennessee, Michigan, New York, and others. MidWest has dark fiber over to 365 in order to bring them on their Indy fabric.

Another large presence at Henry Street is Lightbound ( www.lightbound.com ).  They have a couple of large facilities. According to PeeringDB, only three carriers are in their 731 facility.   However, their web-site lists 18+ carriers in their facilities. The web-site does not list these carriers.

I am a big fan of peeringdb for knowing who is at what facilities, where peering points are, and other geeky information.  Many of the facilities in Indianapolis are not listed on peering DB.  Some other Data Centers which we know about:

Zayo (www.zayo.com)
LightTower ( www.lightower.com )
Indiana Fiber Network (IFN) (https://ifncom.co/)
Online Tech ( www.onlinetech.com )

On the north side of Indianapolis, you have Expedient ( www.expedient.com ) in Carmel. Expedient says they have “dozens of on net carriers among all markets”.  There are some other data centers in the Indianapolis Metro area. Data Cave in Columbus is within decent driving distance.

EVPNs: The answer to your MPLS issues

I had a good discussion with my Buddy JJ tonight on kind of the next step of network evolution for provider networks.  Many providers have evolved to MPLS networks with VPLS.  There are some inherent issues with this when it comes to things like bonding, MLAG, among other issues. Nothing is perfect, right?

So as we dive into What is EVPN I want you to know I am approaching this from a service provider standpoint. I also am no EVPN expert, but I am seeing it more and more as a solution to solve specific issues.  As a result, EVPN is sliding into a natural progression of the service provider network.

So what is EVPN?
There are folks much more versed on EVPN than I am. As a result, I will lean on some already written articles.
https://blog.ipspace.net/2018/05/what-is-evpn.html

https://www.cisco.com/c/en/us/products/ios-nx-os-software/ethernet-vpn.html#~stickynav=1

Components of EVPN
Now that you have a high-level overview of EVPN, what are some of the major components and features you should know? Let’s dive into that

Unified control plane.  EVPN can be used throughout your network.  You don’t have to use one stack for data center, one for metro to the data center, and yet another for connectivity between data centers. You can bring it all under one control roof so to speak.

EVPN, through BGP, marries the Layer 2 and Layer 3 layers together.  With MPLS everything is controlled at the layer3 level.  Now with EVPN Mac addresses become much more important. For example, Each EVPN MAC route announces the customer MAC address and the Ethernet segment associated with the port where the MAC was learned from and is associated MPLS label. This EVPN MPLS label is used later by remote PEs when sending traffic destined to the advertised MAC address. Pretty cool huh?

Image result for evpn service provider

As networks grow network engineers learn about things such as north-south traffic and east-west traffic.  Microsoft has a great article which explains this concept. https://blogs.technet.microsoft.com/tip_of_the_day/2016/06/29/tip-of-the-day-demystifying-software-defined-networking-terms-the-cloud-compass-sdn-data-flows/

East-West – East-West refers to traffic flows that occur between devices within a datacenter. During convergence for example, routers exchange table information to ensure they have the same information about the internetwork in which they operate. Another example are switches, which can exchange spanning-tree information to prevent network loops.

North | South – North- South refers to traffic flows into and out of the datacenter. Traffic entering the datacenter through perimeter network devices is said to be southbound. Traffic exiting via the perimeter network devices is said to be northbound.

So, if you are a growing Service provider look at EVPN.  In some upcoming articles, I will talk more about various components of EVPN and such.