Categories
BGP Networking

Transit, peer, downstream..what do they all mean?

As a service provider you have a mountain of terms to deal with. As you dive into the realm of BGP, you will hear many terms in regards to peers.  Knowing their names AND your definition of them will serve you well.  I emphasized the and in the last sentence because many people have different definitions of what these terms means. This can be due to how long they have been dealing with networks, what they do with them, and other such things.  For example, many content providers use the term transit differently than an ISP.  So, let’s get on to it.

Transit or upstream
This is what you will hear most often.  A transit peer is someone who you go “through” in order to reach the internet.  You transit their network to reach other networks.  Many folks use the term “upstream provider” when talking about someone they buy their internet from.

Downstream
Someone who is “downstream” is someone  you are providing Internet to.  They are “transiting” your network to reach the Internet.  This is typically someone you are selling Internet to.

Peer
This is the term which probably needs the most clarification when communicating with others about how your BGP is setup.  A peer is most often used as a generic term, much like Soda (or pop depending on where you are from). For example someone could say:
“I have a peer setup with my upstream provider who is Cogent.” This is perfectly acceptable when used with the addition of “my upstream provider”.  Peers are often referred to as “neighbors” or “BGP neighbors”.

Local or Private Peer
So what is a local peer? A local peer is a network you are “peering” with and you are only exchanging routes which are their own or their downstream networks.  A local peer usually happens most often at an Internet Exchange (IX) but can happen in common points where networks meet. The most important thing that defines a local peer is you are not using them to reach IP space which is not being advertised form their ASN.   Your peering relationship is just between the two of you. This gets a little muddy when you are peering on an IX, but thats being picky.

I have trained myself to qualify what I mean by a peer when talking about them. I will often say a “transit peer” or a “local peer”. This helps to add a little bit of clarity to what you mean.

Why is this all important? For one, it helps with keeping everyone on the same page when talking about peering.  I had a case a few weeks ago where a Content provider and I wasted configuration time because our definition of transit was different.  Secondly, you want to be able to classify your peers so you can apply different filter rules to them. For example, with a downstream peer you only want to accept the IP space they have shown you which is their own.  That way you are not sending your own transit traffic over their network. This would be bad.  However, if you are accepting full routes from your transit provider, you want your filters to accept much more IP than a downstream provider. So if you have a team being able to be on the same page about peers will help when it comes to writing filters, and how your routers “treat” the peer in terms of access lists, route filters, etc.

Categories
Cambium Networking Wireless WISP

Upgrading ePMP Cambium firmware

Categories
Mikrotik Networking

Basic Mikrotik BGP filter rules

Below are some basic Filter Rules for Mikrotik BGP filtering.  These are not complex and can be very easily implemented on your BGP peers.

Before we get to the code there are a few assumptions
1.Your own IP space in this example is 1.1.1.0/22
2.These filters are not fancy and are geared toward upstream ISPs, not your own internal routers or clients.
3.If you copy and paste the below code make sure there is one command per line.  Some browsers will cut the line off and then it won’t paste right.  If in doubt paste it into notepad, textedit, etc. and clean it up.

/routing filter
add action=discard chain=INET-IN comment="BEGIN INET-IN" prefix=127.0.0.0/8 protocol=bgp
add action=discard chain=INET-IN prefix=10.0.0.0/8 protocol=bgp
add action=discard chain=INET-IN prefix=169.254.0.0/16 protocol=bgp
add action=discard chain=INET-IN prefix=172.16.0.0/12 protocol=bgp
add action=discard chain=INET-IN prefix=192.168.0.0/16 protocol=bgp
add action=discard chain=INET-IN prefix=224.0.0.0/3 protocol=bgp
add action=discard chain=INET-IN prefix=1.1.1.0/22 protocol=bgp
add action=discard chain=INET-IN prefix-length=25-32 protocol=bgp
add action=discard chain=INET-IN protocol=bgp
add action=accept chain=INET-OUT comment="BEGIN INET OUT" prefix=1.1.1.0/22 protocol=bgp
add action=discard chain=INET-OUT protocol=bgp

So what does this do?
-The first 6 lines filter out non routeable IP space.  There should be no reason these are being advertised to you from the public internet.

-Next we are saying if we see our own IP space being advertised to us (in this case 1.1.1.0/22) discard that.  There should be no reason we see our own IP space on a public peer.

-The next line filters out prefixes that are a /25 and smaller.  Just about every provider out there has a minimum size of a /24 they will accept as an advertisement.  If you are getting anything smaller it’s a good practice to drop that.  If there happens to be smaller prefixes they can be sent to a default route to the provider.  This helps trim your routing table, which makes lookups and convergence time quicker.

Under the INET-OUT rules we are advertising our IP space to our upstream.

Pretty simple eh? We could get complicated and add in chains, and more rules. But, this is a start.  We will do some more advanced rules in a later post.

Categories
Uncategorized

Online OSHA Certifications

http://www.compliancetrainingonline.com/osha_certification_training.cfm

Great for Tower climbers and working at facilities which require OSHA certifications.

Categories
Data Center

What is a DCI?

As you get more and more into Cisco Data Center terminology you come across the term DCI.  DCI is a Data Center Interconnect. DCI’s typically come in 3 categories.

Dark Fiber (CWDM/DWDM)
MPLS Layer 2 VPN (VPWS/VPLS)
MPLS Layer 3 VPN

A DCI is basically a LAN extension over one of the above methods.

Categories
Tower Wireless WISP

Conduit hangers for railings

Several clients have asked how to mount 1/2-1″ pipe to handrails or other such surfaces.  Below are some beam clamps and conduit hangers.  Our tip is to “pin” them by drilling some self-tapping screws to hold the pipe from spinning.

IMG_0644 (1) IMG_0646 IMG_0644 IMG_2587

Categories
News WISP

Tale from the Data Center

So, I have an very heartwarming story today related to the WISP industry.

So this started back in March.  A client was having issues with a circuit.  The transport provider had so many fails in troubleshooting the issue from the start. First, the tech from the transport company did not have the tools he needed (we found this out 12 hours later) and could not troubleshoot the problem properly.   Secondly, the Transport company (okay let’s just call them Zayo from now on) had little to no documentation on this issue.

So after 12 hours of back and forth troubleshooting the transport provider finally sends a tech out.  The tech gets on site, and is told he should be in another location because they finally found a problem on the switch port. If the tech would have had the proper tools this process wouldn’t have taken 12 hours.   But that’s another story

So, and here is part one of the heartwarming part, the problem is determined to be a cross connect at the data center.  I call Eric Rogers​ at 3AM and he is at the data center at 4am tracking down the problem with the backbone provider.  The problem ends up being a loose jumper inside the Backbone providers  cabinet.  It seems about the time the circuit started having issues someone from Zayo was inside the patch panel doing work.  The knocked the jumper loose and when it was opened back up it just kinda fell out. A simple plug in and it was fixed.  It shouldn’t have taken 12 hours to fix, but thats not the end of the story.

Fast forward to a few weeks ago.  Keep in mind the above happened in March.  It’s now September.  Zayo sends the client a substantial bill for their techs time that night saying it was a cross connect issue and not a Zayo issue. There are threats to turn off the services if this outrageous bill, which was their fault to begin with, is not paid.  So, here is where heartwarming part #2 come in.  Eric Rogers takes time out of his very busy day to write a letter detailing what he saw that night, and what the problems were.  After submitting the letter to Zayo the client has received word from Zayo they have credited the account.   In the provider world this is as close to a win as you get.

So, it’s thanks to guys like Rick Harnish​ who have fostered the willingness to work together which has made situations like this possible.  Not only did Eric get up at 3AM to help another WISP out, but he took the time to put words to paper to help correct a resulting bad call. We could go over all the fails in this issue, but the wins are what makes it great!

Categories
Networking

IPv6 Security tidbits

/127’s for point to point links (RFC 6164) instead of /64’s

New security problems with IPV6
-Extension header chains
-Packet/Header fragmentation
-Predictable fragment headers
-Atomic Fragments (RFC 6946)

Most of these type of attacks are very complicated.

Avoid EUI-64

Categories
Networking

ARIN + NANOG – IPv6 Talk

image1

Categories
Networking

Change to H.ROOT-SERVERS.NET

Posted to NANOG
This is advance notice that there is a scheduled change to the IP addresses
for one of the authorities listed for the DNS root zone and the .ARPA TLD.
The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army
Research Laboratory.

The new IPv4 address for this authority is 198.97.190.53.

The new IPv6 address for the authority is 2001:500:1::53.

This change is anticipated to be implemented in the root zone on 1 December
2015, however the new addresses are operational now. They will replace the
previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also
previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL).

We encourage operators of DNS infrastructure to update any references to the
old IP addresses and replace them with the new addresses. In particular,
many DNS resolvers have a DNS root “hints” file. This should be updated with
the new IP addresses.

New hints files will be available at the following URLs once the change has
been formally executed on December 1:

http://www.internic.net/domain/named.root
http://www.internic.net/domain/named.cache

The old IPv4 address will continue to work for six months after the
transition (until 1 June 2016), at which point it will be retired from
service. The address will remain under the control of the Army Research
Laboratory, never to be used again for DNS service. The old IPv6 address
will continue to work indefinitely, but may ultimately be retired from
service.

Simultaneous to the retirement of the old address on June 1, 2016, the
ASN for H-root will change from 13 to 1508.

You can monitor the transition of queries to the new addresses at the
following URL:

http://h.root-servers.org/old_vs_new.html