All Entries in the "Routing and Switching" Category
OSPF: Area range vs Summary address
It seems like an easy one! I mean what could be so hard about area range and summary address command? You will be surprised how many people tend to forget this things or to apply them when not necessary or even worst where is their place to be added. It’s basic knowledge, but sometimes exactly this basic knowledge give us headache.
In the following line, I will try to explain briefly the difference between Area range and Summary address command. First let’s have a look at the following topology:
We have mixed network domain with EIGRP and OSPF. From documentation we know that along other routers in OSPF domain we have 2 important routers:
ASBR (Autonomous System Boundary Router) – One device at the edge of OSPF domain, that receive routes from another non-OSPF domain (e.g. RIP, EIGRP…)
ABR (Area Border Router) - One device inside the OSPF domain that assure Inter-area communication (e.g. area 0 and area 1)
You will find situation when only one physical device will be ASBR and ABR router. The functionality and rules remain the same, just that instead of having 2 device you have only one that connect to another non-OSPF domain and in the same time to multiple OSPF areas.
Why we would use this 2 commands? Well one simple explanation is that we want to summarize advertised subnets to reduce the total number of routes present in the routing table. Less routes means less overhead and load for a router.
Let’s have a look to the routers presented in the above topology. The dynamic IP routing protocols (EIGRP and OSPF) are already configured and functional. For the IP network clouds, I have used Loopback interfaces.
R1:
On R1 the 2 IP subnets (192.168.1.0/24 and 192.168.2.0/24) are present in EIGRP routing protocol.
R2:
On R2, there is already a basic redistribution between OSPF and EIGRP. Also notice that the IP subnet which connect R2 and R3 is routed in OSPF area 0 (zero)
R3:
As well on R3, the IP subnet between R2 and R3 is present in OSPF area 0 (zero) and the other 2 subnets (10.10.1.0 /24 and 10.10.2.0 /24) are in OSPF area 1 (one). Now, if you remember from my older post, if you have a Loopback interface with a IP address (doesn’t matter what netmask) this will be always advertised in OSPF as /32. I did a little trick to be sure that they are still advertised in OSPF as presented under Loopack 1 (10.10.1.1 /24) and Loopback 2 (10.10.2.1 /24). You want to know how, check this post.
Until now, we saw how the routers are configured. Let’s have a look how the routing table appear now on this routers.
R1:
Among other routes, please notice that we receive the 2 networks from R3 each of them with a /24 prefix. Keep this in mind as it’s important for later.
R2:
On R2 we have both the EIGRP and OSPF routes, each with a /24 prefix. In some minutes we will change this. Let’s check the last router.
R3:
Here we have the 2 prefixes from EIGRP domain, again with /24.
After reviewing all the necessary information let’s apply the configuration. I will start with Area range command. For example in our case we want to advertise only one subnet from Area 1 to Area 0 in OSPF. We will combine the 2 x /24 subnets in one /22.
Why /22 and not /23? Because we have 10.10.1.0 /24 and 10.10.2.0 /24 and 10.10.1.0/23 will not be a valid prefix. Keep in mind that you have to stick to the subnetting rules. Indeed with this /22 we will “catch” also 10.10.0.0/24 and 10.10.3.0/24 in our range, but being in a test environment this is not a problem for now. In the real world you have to take care about discontinuous networks and to apply summarization only when it’s possible.
On our R3 router we should apply the following configuration:
R3
configure terminal
router ospf 1
area 1 range 10.10.0.0 255.255.252.0
If we check now R2, we should see:
Only one /22 subnet. IP subnet summarization is successfully taking place.
What about Summary address command? Remember that we redistribute from EIGRP into OSPF, so if you have a look about, right now in the OSPF cloud we have 2 /24 subnets imported from EIGRP domain. We want to summarize this 2 addresses in a /22 (the same reason like explained above). For this we will use the Summary address command. In short explanation, this command is only used on ASBR routers, when you want to summarize IP subnets imported from a non-OSPF domain.
On R2, we a apply the following configuration:
configure terminal
router ospf 1
summary-address 192.168.0.0 255.255.252.0
Let’s check what we receive on R1 and R3 after summarization:
We could see clear the advantage. Summary route 192.168.0.0/22 is present on R3 and again 10.10.0.0 /22 is on R1. This is the nice part and we achieved what we wanted.
Very important!
What about the blue line? That a big problem. Maybe your idea was that I did some mistake when using .1. and .2. in the third octet the subnet. It was more easier to use .0. and .1. and then I could summarize easy with /23. But I wanted to show you a hidden danger which lies beyond the summarization. Remember that I said I did just a basic redistribution between EIGRP and OSPF? Forget that! In test environment is OK, but in real ones not. Always try to reduce the amount of redistributed subnets between 2 domains to only the necessary one using route-maps or route tagging. This should be mandatory, when redistributed summarized networks which are discontinuous.
Back to the blue line. We redistribute from EIGRP to OSPF, where we did the summarization. Due to the fact that we used 192.168.1.0/24 and 192.168.2.0/24 we had to summarize to /22, which include also the non-present subnets 192.168.0.0/24 and 192.168.3/24. Then we redistribute from OSPF to EIGRP. See the loop? EIGRP-OSPF-EIGRP. Since EIGRP see there a /22 prefix which include the 2 additional /24 subnets 192.168.0.0 and 192.168.3.0 of which R1 has no clue about, the router install this route in it’s routing table, thinking that R2 is the gateway for the 2 prefixes above. It sound complicated but I tried to simplify the explanation as much as I could. If we were using route-maps or route tagging this situation could be avoided.
Popularity: 11% [?]
Cisco: How to configure HSRP
In this post I proposed to discuss a little bit about Hot Standby Router Protocol and how it can be configured on a Cisco device. For this I have chosen the following topology:
I had in mind this scenario due to the fact that the traffic can take multiple paths in case of link being down and this give us the possibility to have a little bit of conversation on HSRP topic.
HSRP is defined in the document RFC2281 and according to the definition in this document: “The Hot Standby Router Protocol, HSRP, provides a mechanism which is designed to support non-disruptive failover of IP traffic in certain circumstances.” If you want to read more about the details how HSRP is working, please the RFC2281. I think there is not point in reproducing here what is already written there.
Regarding our topology, what you should know is that after configuring HSRP on R1 and R2 we will achieve a failover mechanism for the traffic from the Client (192.168.0.10) to the Server(10.10.10.10). From the beginning we will assume that R1 and R2 have the proper routing already configured to reach this destinations.
In the below presentation, you will see how the failover is achieved and what’s happening when you have a proper HSRP configuration in case that the link SC – R1 is broken:
So, how to achieve this behavior? From the topology you notice that proper configuration of HSRP involves 3 IP addresses from the same subnet (in our case this is 192.168.0.0 /24). One of the IP is configured on R1 the second one on R2 and the third one is HSRP IP address, which will be announced to the Client as gateway.
Configuration is straight forward on R1:
configure terminal
interface fa0/0
ip address 192.168.0.1 255.255.255.0
standby 1 ip 192.168.0.254
standby 1 priority 110
and on R2:
configure terminal
interface fa0/0
ip address 192.168.0.2 255.255.255.0
standby 1 ip 192.168.0.254
First we configure an IP address on the interface. Then we configure HSRP by typing the command “standby” followed by HSRP group (in our case group 1) and then the IP address. HSRP default priority is 100, and the principle is the higher the better. To force the path R1-SC to be the preferred one, we increse the priority to 110, making R1 to be the “Active” one. The other router, in our case R2, will have the HSRP status “Standby“. Maybe you are wondering what happens if you don’t configure the priority and both routers are having the same value 100. In this case HSRP has a mechanism that help it to chose the active router by comparing the IP addresses and chosing the one with the higher value. In our case this would be R2 (192.168.0.2 > 192.168.0.1).
Another useful feature that I recommend to configure for HSRP is “preemption“. The HSRP preemption feature enables the router with highest priority to immediately become the Active router. The configuration is also very simple and inquire only one additional line to the above ones:
standby 1 preempt
Also recommended is to configure “authentication“ between the HSRP participants:
standby 1 authentication somepassword
where “somepassword” can be what ever you want.
Going back to the topology, another scenario can take place. What if the link R1 – SC remains active, and instead the R1 – SS goes down. Since the R1 – SC is UP, the router R1 has no intention to cease the HSRP Active status. If you are having some kind of dynamic routing between R1 and R2, then you are on the safe side as the traffic will flow like in the scenario below (I’m assuming R1 to be the Active one for both R1-SC and R1-SS):
Remember that if do not have some routing between R1 and R2, the packets will be dropped on R1 as they will not have any path to the Server IP address 10.10.10.10.
This situation can be avoid with another HSRP feature, that will force the R1 to change it’s status from Active to Standby by monitoring the interface from R1 to SS. This feature is called “interface tracking“. This HSRP feature you have to configure at least on the router which is usual in Active mode:
standby 1 track FastEthernet1/0 30
In this scenario I assume that interface Fa1/0 is the connection to SS switch. This tracking command is watching for the status on the interface Fa1/0. When it’s status changes to “down” the “priority” value (110 in this example) is decremented with 30 (or whatever you will configure in the command line). After decremental, the “priority”
will have a value of 80 which is lower than the default one (100), forcing R2 to become the Active router and changing the R1 status to Standby.
Checking the status of an HSRP participant is very easy, and you can see this in the output below:
R1#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Fa0/0 1 110 P Active local 192.168.0.2 192.168.0.254R2#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Fa0/0 1 100 P Standby 192.168.0.1 local 192.168.0.254
All the HSRP configuration from this article can be fine tuned or extended according to your needs. I have presented here only the basics about the HSRP configuration. If you want don’t be afraid to explore and to “play” with the commands. Of course I would recommend to do that in test environment first.
Popularity: 10% [?]
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: 29% [?]
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% [?]
