All Entries in the "Cisco-EGP" Category
Cisco: 2-Bytes / 4-Bytes ASN BGP scenarios
In my last post I wrote some basics about the new 4-bytes AS number which is supported on new Cisco IOS images. Now I would like to give you a brief overview about different BGP peering scenarios that you can meet in the real world. Even if the configuration examples in this article are on a Cisco hardware with the latest IOS, the BGP scenarios can be applied to any other platform.
OK, let take the following topology (the high quality PDF file can be downloaded here):
You can see that I think of 3 main scenarios when it comes to have in the same topology 2-Bytes only and 4-Bytes ASN BGP routers:
- 2-Bytes support ASN peering with a 4-Bytes ASN, which has a number greater that 65535 (if you remember from the previous article, this can be wrote as ASPLAIN or ASDOT)
- 4-Bytes ASN peering with a router that support 4-Bytes ASN, but in fact has a number smaller than 65535 (e.g old telecom provider which has has the ASN already asigned as 3456)
- 2-Bytes ASN peering with the same 4-Bytes supported ASN, but with a number smaller than 65535, as in the above scenario
I chose this particular scenarios because it will be interesting to see how we configure a 2-Bytes ASN BGP router which has a 4-Bytes ASN peer or how the same 2-Bytes ASN BGP router will have the AS-Path containing the 4-Bytes ASN router.
For the R1 and R3 routers I will use a C3640 with an IOS image that support only 2-Bytes ASN, and for R2 and R3 a C7200 with the newest IOS image that can support 4-Bytes ASN. All routers have a Loopback interface that will be the BGP router-id an also announced into BGP (e.g. R2 will have interface Loopback100 with IP address 2.2.2.2/32). The AS number that I will use (ignore the fact that I use public ones, it’s just to be more easy to follow):
R1 – ASN 1111
R2 – ASN 2.2 (ASPLAIN 131074)
R3 – ASN 3333
R4 – ASN 4444
I will skip all the boring point-2-point configuration and present only the BGP config.
#### R1-C3600 ####
router bgp 1111
bgp router-id 1.1.1.1
neighbor 10.10.12.2 remote-as 23456
network 1.1.1.1 mask 255.255.255.255
As you can see in BGP peering between R1 and R2 we have to use the remote-as number 23456, due to the fact that R1 is not supporting 4-Bytes ASN. If you read my previous post, or from other sources, you know that any BGP router that does not support 4-Bytes ASN, will use a transitory number for peering with 4-Bytes ASN BGP routers and this number is 23456.
#### R2-C7200 ####
First let’s be sure that the IOS is supporting 4-Bytes ASN. Simplest way:
router bgp ?
<1-65535> Autonomous system number
<1.0-XX.YY> 4 Octets Autonomous system number
I think it’s obvious that it supports. A small note. On all Cisco platforms (usually C3600, C7200) with IOS that I tried testing 4-Bytes ASN BGP, I saw that only ASDOT format is supported. I don’t know about other software platforms (like NX-OS) or something high-end hardware if they support ASPLAIN. Now for the configuration, R2 is peering with R1 and R3:
router bgp 2.2
bgp router-id 2.2.2.2
neighbor 10.10.12.1 remote-as 1111
neighbor 10.10.23.3 remote-as 3333
network 2.2.2.2 mask 255.255.255.255
#### R3-C7200 ####
R3 supports 4-Bytes ASN, but due to the fact that it’s and “old telecom provider” it had been assigned a 2-Bytes ASN, so I will preserve this form:
router bgp 3333
bgp router-id 3.3.3.3
neighbor 10.10.23.2 remote-as 2.2
neighbor 10.10.34.4 remote-as 4444
network 3.3.3.3 mask 255.255.255.255
The difference between R3 and R1 is that R3 support for “remote-as” a 4-bytes ASN number (again only ASDOT representation). So, in it’s peering with R2, the remote ASN is 2.2
#### R4-C3600 ####
R4 only support 2-Bytes ASN, but the difference from R1 is that it has to peer with a 4-Bytes supported ASN router that in fact has a 2-Bytes AS number.
router bgp 4444
bgp router-id 4.4.4.4
neighbor 10.10.34.3 remote-as 3333
network 4.4.4.4 mask 255.255.255.255
This is the basic configuration in this topology. Let’s take now the IP address 1.1.1.1 which is advertised into BGP from R1. If you will check the AS-Path on R4 and R3, you will see a big difference. Have a look into the screen capture below to see the real environment for the above topology:
Popularity: 23% [?]
4-bytes Autonomous System Number
Last week I received a form from APNIC with a new AS numbers. When I had a look through papers I saw there something strange: AS 123456 (I replaced the original with this number). 6 digits. First I thought that there is a mistake or something, then I recall the new 4-bytes ASN. If for IPv6 the things seems to be moving slower, than for the new format of AS numbers, it seems that the things are going faster. So faster that by January 1, 2010 all BGP speaker must support this feature, according to Cisco. I didn’t understood if they refer in the document for their products or it is something that is mandatory globally. No matter how, the things are moving quite fast in this direction.
Since I have to implement a BGP configuration with this 4-Bytes ASN, I started to search with Google friend about the standards and I was surprised that there is not to much to search after. Of course there is the official RFC, some other documentation, but not real examples how to configure, troubleshoot and so on. That’s why I said it’s nice to put something together for a general understanding of what is and how does it work this 4-Bytes ASN. I assume here that reader has a basic understanding of what ASN and BGP is.
RFC 4893 is the reference for “BGP Support for Four-octet AS Number Space”. Currently the Autonomous System number is encoded as a two-octet (2-bytes) entity in BGP, meaning 16bits and this was defined in RFC 4271. The new system is using a four-octet (4-bytes) , meaning 32bits. Currently the ASN 2-bytes include a range from 1 – 65535, used in decimal plain text when configuring the BGP. The expansion from 2-bytes to 4-bytes give us 4,294,967,295 AS number which can be written in ASPLAIN or ASDOT format.
Why two formats? Mainly due to different opinions about how the 4-bytes number should be represented:
ASPLAIN representation
The RIPE NCC assigns and registers 4-byte AS Numbers in ASPLAIN format.
ASPLAIN defines the 4-byte AS Number as a basic 32-bit integer.
“2-byte only AS Numbers” refers to AS Numbers in the range 0 – 65535
“4-byte only AS Numbers” refers to AS Numbers in the range 65536 – 4294967295”
“4-byte AS Numbers” refers to AS Numbers in the range 0 – 4294967295
Advantages:
- IETF preferred notation
- continuation on how a 2-Byte AS number has been represented historically
- does not break AS-PATH REGEX
- APNIC reached consensus to adopt ASPLAIN for assignment and representation of 4-byte AS Numbers
- routers vendors appear to be supporting ASPLAIN, which will require no conversion from allocation to configuration
Disadvantages:
- long number to remember
- All existing 4-byte only assignments have been made in ASDOT
ASDOT representation
The full binary 4-byte AS number is split two words of 16 bits each. It is proposed to identify 4-byte AS Numbers using a syntax of <high
order 16 bit value in decimal>.<low order 16 bit value in decimal>:
“2-byte only AS Numbers” refers to AS Numbers in the range 0 – 65535
”4-byte only AS Numbers” refers to AS Numbers in the range 1.0 – 65535.65535
“4-byte AS Numbers” refers to AS Numbers in the range 0.0 – 65535.65535
Advantages:
- easy to read and remember
Disadvantages
-require conversion from ASPLAIN to ASDOT
-hard for regular expressions
What’s happening if in a BGP peering one router supports the new format and the other one only the old one. The new reserved ASN 23456 is used for backward compatibility between 4-bytes and 2-bytes BGP speakers. So, if your router advertise BGP with a 4-bytes as number (doesn’t matter in which representation ASDOT or ASPLAN), the peer which does not support the new format, will translate the 4-bytes ASN into 2-bytes ASN 23456. A graphical representation of the AS path from 4-bytes to 2-bytes in BGP would be:
OK, I hope you understand the basics of 4-bytes ASN. For me, some challenge was to understand to transform the 4-bytes ASN from ASPLAIN to ASDOT. In every document that I saw on the Internet there was the same example: AS 65546 in ASPLAIN is 1.10 in ASDOT, but without no explanation. See below how I understood that the conversion takes place. If I understood it wrong, please let me know, to correct it here. After all I’m not an 4-byte ASN expert, I just try to help as much as I can.
So let’s take the number 65546.
1. 65546 / 65535 = 1 (integer) which will be the parte in front of the . (dot) in ASDOT representation.
2. 65546 – ( 65535 * 1) = 11 (see how much rest remains after 65353 going once in 65546)
3. 11 – 1 = 10 which will be the part after . (dot)
4. You obtain 1.10
As a general rule, you have an ASPLAIN number. You take 65535 and see how many times it goes, with integer in the ASPLAIN number (1 time, 2 times, 3 times…depending). This will be your decimal number before dot in ASDOT format . Then you multiple the 65535 with the integer obtained in the first step and you deduct from the ASPLAIN number. From the rest after the second operation, you deduct the the decimal you have in front of the dot. The rest in decimal that comes after the dot .
What confused me is that the number in the example was so close to the last 2-bytes ASN which is 65535.
Now for the last example, let me take a random higher number 194534 (the example from the first line) and to obtain the ASDOT format.
1. 194534 / 65535 = 2 (integer)
2 194534 – ( 65535 * 2) = 194534 – 131070 = 63464
3 63464 – 2 = 63462
4 ASDOT = 2.63462
An online converter from ASPLAIN do ASDOT you can find here: http://as4.nullroute.se/index.php
For some more detailed explanation I would like to ask you to download the Cisco and Juniper documents regarding 4-bytes ASN implementation in BGP.
If you have any useful information about this topic or if something is wrong in my post, please comment and share your knowledge.
Popularity: 7% [?]
Cisco: 6 best practice security tips for BGP
As we all know, in today’s digital communication world, there is a very big possibility that your network is or was target for a malicious activity. BGP is one of the most targeted routing protocols when we are talking about network attacks.Why? This is quite simple. BGP is your connection to the exterior world (peer networks, Internet and everything which is outside your LAN/MAN), so it is somehow normal to be the main target of the conducted attacks. If in case of the WWW, DNS, E-mail services we can say that maybe an attack was not intentionally made (e.g. a user got infected with some trojan/malware/botnet tool that is attacking random destinations), in the case of BGP, you can be 90% sure that this is an intentionally conducted attack. The main scope of a BGP attack is to flood the network with false information (e.g. false network prefixes) in this way trying to direct interesting traffic to special destinations where this can be sniffed and decoded.
I will present here 6 tips that I’m using the most to protect BGP against malicious information. This is really easy to implement, if you have any basic idea about how to configure BGP protocol, but it can save you from hours of troubleshooting and investigation.
1. Limit the maximum number of prefixes that you learn from BGP peer, to avoid overload of your machine.
2. Deny updates that include a private AS number in the AS Path (64512 – 65535).
3. Use ACLs on your external interface to permit input/output BGP packets only from your defined source and destination
4. Limit TTL in BGP packets to limit the communication only with next-hop peers.
5. Use a password to authenticate peer neighbors.
6. Limit the maximum length of the AS path
Also here I would like to mention, not necessary as a security tip, but more like a best practice, enable when it is possible logging. This can help you to observe some strange behavior that occur on your machines where you are not arround them.
There is no topology present for this tutorial, but we will assume that we have a point-to-point serial connection between 2 routers, R2 (10.0.23.2) and R3 (10.0.23.3). Please click the image below to view the tutorial:
If for some reasons the tutorial above is not available for you, please check this text file which present in text mode everything needed to implement BGP security tips presented above.
Popularity: 3% [?]
Cisco: BGP path selection for inbound traffic
In some previous post we saw how we can manipulate BGP paths using attributes for outgoing traffic. Today we will see how to use another BGP attribute, but this time for manipulating inbound traffic. First I would like to ask you to have a look into the topology file and also to check the config files (if you have a basic idea about how BGP is configured that you don’t need the config files).
From the table above:
we see that the attributes needed for inbound traffic manipulation are AS-Path and MED. Today we will use AS-Path for traffic manipulation (MED sometime in closer future).
Beside using BGP attributes, there are other ways to manipulate traffic and paths in a BGP environment, but usually this need that the provider will support your actions. As an example to understand, you can do route tagging in your network (for example in MPLS on your CE) and your ISP will apply rules based on different tags (on PE side), but this is out of the scope of this tutorial and will be discussed maybe in another tutorial.
For our test environment, that you see in the topology, we advertise everything into BGP domain, exactly as draw, so there will be no problems of reachability.
Please see the tutorial and explanations below:
Popularity: 4% [?]
