Category: Networking

Categories
BGP Networking

How does BGP select which route?

BGP can be a complex and almost mystical protocol. For those of you who are trying to determine how BGP selects which route here is your guide. Before we get into it a couple of things to keep in mind. First, BGP is not a multipath routing protocol. This is different than what you may be used to with OSPF. BGP goes to great lengths to encure only one route is used. Secondly, there are some vendor specific rules which are applied. I will try to point those out as we go along.

1.The first test is if the next hop router is accessible.

2.If Synchronization is enabled, the router will ignore any iBGP routes which are not synced.

3.The third is Cisco specific. Cisco uses a weight attribute. The largest weight wins. Default weight is zero. Maximum weight is 65,535.

4.If the weights are the same, the highest local preference is chosen from LOCAL_PREF. It’s important to note that routers only receive this from iBGP.

5.Net up, the router checks to see if any of the possible routes were originated locally. The two main checks are either the network or aggregate commands. The network command wins if it is originated locally.

6.If two or more routes are still equal the router looks as AS_PATH. The router will prefer any iBGP routes. Outside of the AS BGP will prefer the shortest path.

7.BGP then moves on to the ORIGIN attribute. If the path lengths are the same, BGP selects IGP over EGP and EGP over INCOMPLETE routes.

8.BGP now looks at MED values. The lowest value is selected. Note, MED is only used if both routes are received from the same AS, or if always-compare-med has been enabled. Be careful with always-compare-meds as this can cause routing loops.

9.BGP will then prefer eBGP to iBGP routes. This is not the same as #5 above. Only external routes are looked at here.

10.Next IBGP costs are compared to the next hop routers. The closest one is selected.

11.Ages of routes are finally connected. This is kind of like choosing teams for dodgeball. The oldest route wins. The reason being is oldest routes are thought to be more stable.

12.And finally, if all else fails the router with the lowest router ID wins.

This is a quick low-down on how BGP “thinks” in order to determine routes. If anyone has some Cisco, Mikrotik, quagga, or other specific attributes please comment. I have reached out to Mikrotik and Ubiquiti specifically to see if this is in-line with their implementation of BGP.

Categories
Networking

Simple BGP by Qrator

so the folks over at Qrator have proposed some additions to BGP. At the heart of this is the addition of roles in a BGP session. You would have four possible roles: customer, provider,peer, and internal.

You can learn some more about this at https://radar.qrator.net/tools/simple-bgp

Categories
Data Center Fiber Networking Tower xISP

Broadband Applications & Construction Manual

If you are like me and enjoy technical manuals here is a good one from Commscope for you installers out there. It is a good overall manual, with some Commscope specific products thrown in.

From the manual
The Drop Cable Applications and Construction Guide is written for the cable installation professional who, due to the diverse services offered by CATV and telecommunication service providers, needs a quick and handy reference to practical installation information, especially in the case of retrofitting.
We’ve tried to simplify the decision-making process as to which cables to choose for what installation, taking into account factors such as performance over distance, preventing RF interference and fire/safety codes.

Drop_Const_Manual_CO-107145

Categories
Networking

Quanta LB4M insides

Just some geek Pr0n for you on a Friday afternoon. The insides of a Quanta LB4M switch. This is a great switch if you are needing a couple of 10 gig ports.

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
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