I was just witnessed a very surprising conversation through NANOG. The person was asking if he can redistribute their full BGP table into OSFP. Of course, the rest of a forum was able to assist this poor chap out.
This is a problem on several levels. Frist of which, OSPF is designed as an IGP meant to find the best path to a prefix within a AS, not the entire internet, which BGP is designed for. Therefore, it is not recommended to inject an EGP into an IGP such as OSPF. On the other hand, BGP, or eBGP more specifically, is designed for route control, not best path discovery; or in other words, to provide the AS control of what routes get advertised out of the AS, what routes get advertised into the AS, and what path to take for egress and ingress traffic.
Second, a full internet BGP table is 400,000+ prefixes. I cannot image a router that can calculate that many SPF algorithms, or any other IGP protocol, and make it through convergence, not to mention if there is a one area or several areas within OSPF. I suppose it would depend on the amount of memory, and processing power of the router. Maybe there is a router that can, but could you imagine maintaining a route table with 400,000 prefixes, it would be an administrative nightmare.
Unless you are an ISP, keep the EGP at the edge or within the core for specialty cases. Also, unless you are multi-homed with 2 or more ISPs there is not really a reason to have a full BGP table. I do acknowledge that there are reasons to redistibute individual routes into the IGP for path selection within the AS, but there are other ways of accomplishing this within the IGP. I can imagine also redistributing a default route learned from BGP into the IGP, but OSPF does not support this feature in Cisco IOS, though it is supported in JUNOS.
If you have had experiences redistributing BGP into an IGP I would be very interested in hearing how you have utilized it. I have myself redistributed a default route into EIGRP within a multi-homed environment, and also did some interesting things with MPLS from a practical perspective, and done other things in the lab.
Showing posts with label OSPF. Show all posts
Showing posts with label OSPF. Show all posts
Sunday, May 20, 2012
Saturday, May 19, 2012
Intra-area and External OSPF LSAs Explained (Briefly)
So why segment your OSPF AS into various areas all connected to a backbone area (a.k.a. area 0)? Why not just keep it one simple backbone area? That answer is to contain Type-1 (Router) and 2 (Network) LSA propagation, and summarize at border routers to allow for faster convergence within each area. LSAs help us do that, but we need to know what they are and what they do for us.
First a bit about LSA's and OSPF. Link State Advertisements or LSAs are generated for every router, for every transient network (both broadcast and non-broadcast multiaccess networks...ethernet, frame-relay, etc), for every prefix from another area, and every prefix that redistributed into an OSFP network from an external routing source. These LSAs are flooded within an area, and some into other areas as we will see. All this information is shared between OSPF speaking routers. It is gathered and placed into the OSPF database called the Link State Database or LSDB on each router. Once the routers have all the information about every prefix everywhere within its AS, it then runs the Shortest Path First (SPF) algorithm against the LSDB to calculate the shortest or 'best' path to each network prefix. This path is determined by the lowest cost calculated based on a metric that drived from the bandwidths of the links and the costs advertised by all other routers. Each router calculates the best path to each prefix from its own perspective, essentially building a tree that no brach crosses any other branch, thus creating a loop free topology. The problem is that the larger the database or topology is, the more processing and time it takes to calculate the shortest path, hence slower convergence. Depending on the router's capabilities and the number of SFP calculations to process if the database is too large during convergence, I have seen routers never converge.
This is where OSPF's 2 teir hierarchy, areas and LSAs comes into play. Area Border Routers (ABRs) are routers that connect 2 or more areas. All areas must be connected to the backbone area (with the exception of a sham-link) and is connected via an ABR. The ABRs do not forward type 1 or 2 LSAs into adjacent areas. And this is good. Instead the ABRs take the prefix information learned from the connected areas and flood them as a Type-3 (Net Summary) LSA into each adjacent area. All other routers in the area instead of calculating the SPF to the advertising router within another area, instead use the cost the ABR provides along with the cost to get to the ABR(not always though, see stubby networks below). Now it would not make sense to have every subnet connected to every router in an area advertised as a Type-3 LSA into the adjacent areas. This would do nothing to reduce the number of LSAs, so at the ABRs we should summarize the prefixes contained within that area. This summarization can effectively reduce the Type-3 LSA advertisements into adjacent areas to one Type-3 LSA, if the IP numbering schema is well designed.
The fun begins with two AS's or autonomous systems exchanging OSPF LSAs (via redistribution). For this to occur we need a Autonomous System Boarder Router or ASBR. The ASBRs produce Type-5 (AS-External) LSAs for each external route redistributed into OSPF and and floods them throughout the AS (again, see stubby networks below). The ASBR can advertise the LSA as a Type-1 or Type-2 External metric. Essentially, a Type-1 External metric is calculated based on the advertising ASBRs metric plus the metric to get to the ASBR. In other words, a router will receive an LSA from an ASBR and add the cost to get to the ASBR to the metric received from the ASBR for the Type 1 External prefix. The other is Type-2 External metrics are much easier the metric that ASBR advertises does not change throughout the AS. Type-1s are preferred over Type-2s by the routers. Again like Type-3 LSAs, Type-5 LSAs can be summarized to reduce LSA propagation throughout the AS.
So what happens if the ASBR is in a different area than the Backbone area? The problem is how is another area's router going to calculate how to get to the ASBR of another area if all it receives is a LSA. This is where a Type-4 LSA helps. A ABR (remember it connects 2 or more areas) helps out by letting everyone in the area know the cost of getting to the ASBR from the ABR for each prefix.
There is one other LSA that needs to be touched on, and that is the Type-7 LSA or NSSA External. Some say NSSA is Cisco propriety, but there is OSPF extension that describes it in RFC 1587. An NSSA or Not-So-Stubby-Area, is an area that is confused. But to know why it is confused need to know what a stubby network is. In a stubby network, the ABR advertise no Type-5 LSAs into the area, and will instead advertise a default route as a Type-3 LSA. This again is to reduce the number of LSAs propagated to the stub area. An ABR may send other Type-3 LSAs as well or it may not depending on the configuration. A stubby network which does not receive type-3 LSAs with the exception of the default route is called a totally stubby network. But a NSSA is a stub network (which doesn't get Type-5 LSAs, and may not get Type-3 LSAs) that is connected to another AS, whose prefixes are being redistributed into OSPF within the stub network, hence the could have been stubby network it is not so stubby any more. These prefixes are advertised via a Type-7 LSA. However, when the ABR receives and re-advertises the prefixes received from the Type-7 LSA it advertises them in the backbone area as a Type-5 LSA.
Of couse there are exceptions to some of these rules as we have seen with stubby areas and NSSAs. For example, in an MPLS VRF or Layer 3 VPN that is being redistributed from MP-BGP into OSPF on a Provider Edge router, the PE router does not advertise the prefix via a Type-5 LSA but it in fact advertises it as a Type-3, even though technically BGP and OSPF are differing AS's. But this makes sense, from a customer point of view, the prefixes the customer advertises into the VRF are not from differing AS's but all part of the customers own AS. This way each of the customers site router actually receive Type-3 LSAs, and everything looks to be part of the same large network with no ISP interference.
I hope this provides you with some insight into the various LSA types that are used in multiarea OSPF domains. OSPF is a very complex routing protocol with many 'button and knobs', and as the title suggested I tried to be brief and hit on the highlights of each LSA (the devil is in the details). I know I did not touch on Type-6 Group Membership LSAs but I have never seen them used in production. Small OSPF networks may only have one backbone area and have no convergence problems, larger OSPF network may have many areas and still work to reduce there LSDB. How to control the propagation of LSAs is a key factor to faster OSPF convergence times. In conclusion, OSPF is my favorite IGP, and has great convergence when designed and tuned correctly, and scales very well thanks to the controls that are built into the LSAs. In a later post I describe how to summarize and filter Type-3 and 5 LSAs from being advertised to different areas.
First a bit about LSA's and OSPF. Link State Advertisements or LSAs are generated for every router, for every transient network (both broadcast and non-broadcast multiaccess networks...ethernet, frame-relay, etc), for every prefix from another area, and every prefix that redistributed into an OSFP network from an external routing source. These LSAs are flooded within an area, and some into other areas as we will see. All this information is shared between OSPF speaking routers. It is gathered and placed into the OSPF database called the Link State Database or LSDB on each router. Once the routers have all the information about every prefix everywhere within its AS, it then runs the Shortest Path First (SPF) algorithm against the LSDB to calculate the shortest or 'best' path to each network prefix. This path is determined by the lowest cost calculated based on a metric that drived from the bandwidths of the links and the costs advertised by all other routers. Each router calculates the best path to each prefix from its own perspective, essentially building a tree that no brach crosses any other branch, thus creating a loop free topology. The problem is that the larger the database or topology is, the more processing and time it takes to calculate the shortest path, hence slower convergence. Depending on the router's capabilities and the number of SFP calculations to process if the database is too large during convergence, I have seen routers never converge.
This is where OSPF's 2 teir hierarchy, areas and LSAs comes into play. Area Border Routers (ABRs) are routers that connect 2 or more areas. All areas must be connected to the backbone area (with the exception of a sham-link) and is connected via an ABR. The ABRs do not forward type 1 or 2 LSAs into adjacent areas. And this is good. Instead the ABRs take the prefix information learned from the connected areas and flood them as a Type-3 (Net Summary) LSA into each adjacent area. All other routers in the area instead of calculating the SPF to the advertising router within another area, instead use the cost the ABR provides along with the cost to get to the ABR(not always though, see stubby networks below). Now it would not make sense to have every subnet connected to every router in an area advertised as a Type-3 LSA into the adjacent areas. This would do nothing to reduce the number of LSAs, so at the ABRs we should summarize the prefixes contained within that area. This summarization can effectively reduce the Type-3 LSA advertisements into adjacent areas to one Type-3 LSA, if the IP numbering schema is well designed.
The fun begins with two AS's or autonomous systems exchanging OSPF LSAs (via redistribution). For this to occur we need a Autonomous System Boarder Router or ASBR. The ASBRs produce Type-5 (AS-External) LSAs for each external route redistributed into OSPF and and floods them throughout the AS (again, see stubby networks below). The ASBR can advertise the LSA as a Type-1 or Type-2 External metric. Essentially, a Type-1 External metric is calculated based on the advertising ASBRs metric plus the metric to get to the ASBR. In other words, a router will receive an LSA from an ASBR and add the cost to get to the ASBR to the metric received from the ASBR for the Type 1 External prefix. The other is Type-2 External metrics are much easier the metric that ASBR advertises does not change throughout the AS. Type-1s are preferred over Type-2s by the routers. Again like Type-3 LSAs, Type-5 LSAs can be summarized to reduce LSA propagation throughout the AS.
So what happens if the ASBR is in a different area than the Backbone area? The problem is how is another area's router going to calculate how to get to the ASBR of another area if all it receives is a LSA. This is where a Type-4 LSA helps. A ABR (remember it connects 2 or more areas) helps out by letting everyone in the area know the cost of getting to the ASBR from the ABR for each prefix.
There is one other LSA that needs to be touched on, and that is the Type-7 LSA or NSSA External. Some say NSSA is Cisco propriety, but there is OSPF extension that describes it in RFC 1587. An NSSA or Not-So-Stubby-Area, is an area that is confused. But to know why it is confused need to know what a stubby network is. In a stubby network, the ABR advertise no Type-5 LSAs into the area, and will instead advertise a default route as a Type-3 LSA. This again is to reduce the number of LSAs propagated to the stub area. An ABR may send other Type-3 LSAs as well or it may not depending on the configuration. A stubby network which does not receive type-3 LSAs with the exception of the default route is called a totally stubby network. But a NSSA is a stub network (which doesn't get Type-5 LSAs, and may not get Type-3 LSAs) that is connected to another AS, whose prefixes are being redistributed into OSPF within the stub network, hence the could have been stubby network it is not so stubby any more. These prefixes are advertised via a Type-7 LSA. However, when the ABR receives and re-advertises the prefixes received from the Type-7 LSA it advertises them in the backbone area as a Type-5 LSA.
Of couse there are exceptions to some of these rules as we have seen with stubby areas and NSSAs. For example, in an MPLS VRF or Layer 3 VPN that is being redistributed from MP-BGP into OSPF on a Provider Edge router, the PE router does not advertise the prefix via a Type-5 LSA but it in fact advertises it as a Type-3, even though technically BGP and OSPF are differing AS's. But this makes sense, from a customer point of view, the prefixes the customer advertises into the VRF are not from differing AS's but all part of the customers own AS. This way each of the customers site router actually receive Type-3 LSAs, and everything looks to be part of the same large network with no ISP interference.
I hope this provides you with some insight into the various LSA types that are used in multiarea OSPF domains. OSPF is a very complex routing protocol with many 'button and knobs', and as the title suggested I tried to be brief and hit on the highlights of each LSA (the devil is in the details). I know I did not touch on Type-6 Group Membership LSAs but I have never seen them used in production. Small OSPF networks may only have one backbone area and have no convergence problems, larger OSPF network may have many areas and still work to reduce there LSDB. How to control the propagation of LSAs is a key factor to faster OSPF convergence times. In conclusion, OSPF is my favorite IGP, and has great convergence when designed and tuned correctly, and scales very well thanks to the controls that are built into the LSAs. In a later post I describe how to summarize and filter Type-3 and 5 LSAs from being advertised to different areas.
Wednesday, May 16, 2012
Advantages of Loopback Interfaces on Routers
It is very easy to create and use loopback interfaces on routers and they can provide many advantages to the network engineers who utilize them.
First let me define what a loopback interface is. A loopback is a logical virtual interface created on a router that emulates a real interface. Once assigned an IP address and that IP or Subnet is advertised on the network, one has an always up interface that is reachable as long as the route to that IP is available in the IP routing table.
So here is an example configuration of a loopback interface and address assignment on a Cisco Router running IOS called R1:
R1(config)#interface loopback 0
R1(config-if)#ip address 10.10.10.10 255.255.255.255
R1(config-if)#end
So what advantage does having this loopback address give you?
Routing protocols such as OSPF or BGP can utilize the loopback address as the Router ID or RID. A network engineer can assign RIDs that are easily identifiable. These RIDs are advertised to the routers peers or neighbors establishing adjacency.
(Note: RID do not have to be a loopback, and can be assigned automatically by the protocol via an interface IP address, or you can specify a 32 byte address under the protocol, but there are advantages to making it a loopback address.)
Continuing on from the example above, R1 is connected to R2 on interface FastEthernet0/0 via a /30 subnet. R2 will be configured with a loopback address of 20.20.20.20/32.
Although the OSPF routing protocols will automatically assign a configured loopback address, to follow best practices we will specify the loopback as the RID and advertise it as a reachable network via that router. The following example is for OSPF:
R1(config)#router ospf 1
R1(config-router)#router-id 10.10.10.10
R1(config-router)#network 10.10.10.10 0.0.0.0 area 0
When R1 and R2 establish a neighbor relationship via OSPF the 10.10.10.10/32 network will be reachable as it is now advertised by R1. But lets take a look at the OSPF neighbor relationship on R2:
R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.10.10.10 1 FULL/DR 00:00:37 10.1.1.1 FastEthernet0/0
The RID is the Neighbor ID. This is very advantageous to those who maintain the network because now we can design the loopback addressing schema to allow us to quickly identify what routers are peered. And now from R2 the loopback address of 10.10.10.10 is reachable.
R2#ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/26/40 ms
This is an easy way to test if your router is reachable even if multiple interfaces to it may be down. As long as the router has IP connectivity and able to advertise its routes to the rest of the network it will be reachable via the network via the loopback address. No guessing which interfaces are up and which ones are down.
In the following BGP example, the iBGP neighbor peering can be specified via the neighbors loopback address. (Note: To implement this for eBGP, BGP multi-hop would need to be implemented because eBGP has a TTL of 1, where iBGP has a TTL of 254.) BGP's neighbor table looks like this between iBGP peers.
R2#sh ip bgp summary
BGP router identifier 20.20.20.20, local AS number 65000
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.10 4 65000 4 4 1 0 0 00:00:34 0
Because BGP peerings are established over TCP port 179 these routers could have many router hops in between them and they do not have to be directly connected. By utilizing the 'update source interface' command you can specify that the TCP connection with the peer router be established using the address on the router's local loopback interface thus utilizing the routers IGP to route to the destination router you are trying to peer with.
Loopback addresses have other advantages with their 'always up' nature. They can be used for DNS entries by associating the loopback IP address to an assigned hostname, thereby making the router always reachable via its DNS name as long as the router has IP connectivity. TACACS+ or RADIUS can use the loopback address as a source for AAA functions and thereby reducing the administration overhead of having to add every IP address of the router to the AAA server to ensure functionality should an interface fail . NMS products can easily add routers via the loopback addresses and it eliminates the guess work as to what IP address the router should be added with. Point to point serial interfaces can utilize the 'ip unnumbered interface' command to assign the IP of the loopback to multiple serial interfaces.
Loopback addressing becomes even more important in large fully meshed or route-reflector BGP environments where many routers will have multiple peering with many other BGP speaking routers, and many IGPs can be running in the background. Adding and troubleshooting other services like LDP for MPLS, or building MPLS L2 Pseudo-wire crossconnects, all running over MP-BGP, loopback addressing becomes extremely important to easily identify the peer routers to deliver the services in large ISP environments.
I hope this gives you some ideas about the advantages of loopback interfaces and ways to implement them in your environment. I am sure there are many other useful ways to utilize loopback interfaces. Please feel free to provide any additional benefits that you have found in your networks.
Subscribe to:
Posts (Atom)