Classful and Classless

Classful and Classless Classful Routing Protocols Classful routing protocols do not send subnet mask information in routing updates. The first routing protocols such as RIP, were classful. This was at a time when network addresses were allocated based on classes, class A, B, or C. A routing protocol did not need to include the subnet mask in the routing update because the network mask could be determined based on the first octet of the network address. Classful routing protocols can still be used in some of today's networks, but because they do not include the subnet mask they cannot be used in all situations. Classful routing protocols cannot be used when a network is subnetted using more than one subnet mask, in other words classful routing protocols do not support variable length subnet masks (VLSM). There are other limitations to classful routing protocols including their inability to support discontiguous networks. Classful routing protocols, discontiguous networks and VLSM will all be discussed in later chapters. Classful routing protocols include RIPv1 and IGRP. Classless Routing Protocols Classless routing protocols include the subnet mask with the network address in routing updates. Today's networks are no longer allocated based on classes and the subnet mask cannot be determined by the value of the first octet. Classless routing protocols are required in most networks today because of their support for VLSM, discontiguous networks and other features which will be discussed in later chapters. In the figure, notice that the classless version of the network is using both /30 and /27 subnet masks in the same topology. Also notice that this topology is using a discontiguous design.. Classless routing protocols are RIPv2, EIGRP, OSPF, IS-IS, BGP.

Fault Tolerant Network Architecture, Posted in Tutorials , 0 Comments

The Internet, in its early inception, was the result of research funded by the United States Department of Defense (DoD). Its primary goal was to have a communications medium that could withstand the destruction of numerous sites and transmission facilities without disruption of service. It only follows that fault tolerance was the focus of the effort of the initial internetwork design work. Early network researchers looked at the existing communication networks, which were primarily for the transmission of voice traffic, to determine what could be done to improve the fault tolerance level.

Circuit Switched Connection-oriented Networks To understand the challenge that the DoD researchers were faced with, it is necessary to look at how early telephone systems work. When a person makes a call using a traditional telephone set, the call first goes through a setup process, where all of the telephone switching locations between the person and the phone set that they are calling are identified. A temporary path, or circuit, is created through the various switching locations to use for the duration of the telephone call. If any link or device participating in the circuit fails, the call is dropped. To reconnect, a new call must be made, and a new circuit created between the source telephone set and the destination. This type of connection-oriented network is called a circuit-switched network. Early circuit switched networks did not dynamically recreate dropped circuits. In order to recover from failure, new calls had to be initiated and new circuits built end-to-end. Many circuit switched networks give priority to maintaining existing circuit connections, at the expense of new circuit requests. In this type of connection-oriented network, once a circuit is established, even if no communication is occurring between the persons on either end of the call, the circuit remains connected and resources reserved until one of the parties disconnects the call. Since there is a finite capacity to create new circuits, it is possible to occasionally get a message that all circuits are busy and a call cannot be placed. The cost to create many alternate paths with enough capacity to support a large number of simultaneous circuits, and the technologies necessary to dynamically recreate dropped circuits in the event of a failure, led the DoD to consider other types of networks. Packet Switched Connectionless Networks In the search for a network that could withstand the loss of a significant amount of its transmission and switching facilities, the early Internet designers reevaluated early research regarding packet switched networks. The premise for this type of networks is that a single message can be broken into multiple message blocks. Individual blocks containing addressing information indicates both their origination point and their final destination. Using this embedded information, these message blocks, called packets, can be sent through the network along various paths, and can be reassembled into the original message upon reaching their destination. Utilizing Packets The devices within the network itself are unaware of the content of the individual packets, only visible is the address of the final destination and the next device in the path to that destination. No reserved circuit is built between sender and receiver. Each packet is sent independently from one switching location to another. At each location, a routing decision is made as to which path to use to forward the packet towards its final destination. If a previously used path is no longer available, the routing function can dynamically choose the next best available path. Because the messages are sent in pieces, rather than as a single complete message, the few packets that may be lost in the advent of a failure can be retransmitted to the destination along a different path. In many cases, the destination device is unaware that any failure or rerouting has occurred. Packet-switched Connectionless Networks The DoD researchers realized that a packet switched connectionless network had the features necessary to support a resilient, fault tolerant network architecture. The need for a single, reserved circuit from end-to-end does not exist in a packet switched network. Any piece of a message can be sent through the network using any available path. Packets containing pieces of messages from different sources can travel the network at the same

time. The problem of underutilized or idle circuits is eliminated -- all available resources can be used at any time to deliver packets to their final destination. By providing a method to dynamically use redundant paths, without intervention by the user, the Internet has become a fault tolerant, scalable method of communications. Connection-oriented Networks Although packet-switched connectionless networks met the needs of the DoD, and continue to be the primary infrastructure for today's Internet, there are some benefits to a connection-oriented system like the circuitswitched telephone system. Because resources at the various switching locations are dedicated to providing a finite number of circuits, the quality and consistency of messages transmitted across a connection-oriented network can be guaranteed. Another benefit is that the provider of the service can charge the users of the network for the period of time that the connection is active. The ability to charge users for active connections through the network is a fundamental premise of the telecommunication service industry.

====================================================================================

Cisco OSPF and JunOS Basic OSPF connectivity, Posted in CiscoIOS vs Juniper , Tutorials , 0 Comments

Lets set up a basic OSPF adjacency between JunOS and IOS. Ive got the following simple topology:

The good thing here is that the configs shown will show the difference between JunOS and IOS as theactualconfigurationgoalisthe same for both. The Cisco config is as follows:

Router>conf t

#int fa0 #ip address 192.168.1.2 255.255.255.0 #int lo100 #ip address 172.16.10.1 255.255.255.0

#router ospf 1 #network 192.168.1.0 0.0.0.255 area 0 #network 172.16.10.0 0.0.0.255 area 0 #exit

Now

onto

JunOS:

root@Olive>configure # set interfaces em1 unit 0 family inet address 192.168.1.2/24 # set interfaces lo0 unit 100 family inet address 172.16.20.1/24

# edit protocols ospf area 0 # set interface 192.168.1.1 # set interface 172.16.20.1

Lets

see

what

we

see

on

the

Cisco:

Router#sh ip ospf neighbor

Neighbor ID Interface 172.16.20.1 FastEthernet0

Pri

State

Dead

Time

Address

128

FULL/BDR

00:00:34

192.168.1.1

Router#sh ip route

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks O O C C 172.16.20.0/24 [110/1] via 192.168.1.1, 00:00:25, FastEthernet0 172.16.20.1/32 [110/1] via 192.168.1.1, 00:00:25, FastEthernet0 172.16.10.0/24 is directly connected, Loopback100 192.168.1.0/24 is directly connected, FastEthernet0

What

about

the

Olive?

root@Olive> show ospf neighbor Address Dead 192.168.1.2 Interface State ID Pri

em1.0

FULL

172.16.10.1

1

36

root@Olive>show route

172.16.10.1/32

*[OSPF/10]

00:09:05, metric 2

> to 192.168.1.2 via em1.0

And yes, both routers can ping both loopbacks :)

Quick DHCP server Setup on IOS and JUNIPER OS JUNOS, Posted in CiscoIOS vs Juniper , Tutorials , 0 Comments

Lets say we need to setup a quick DHCP server on IOS and JunOS. Weve been tasked with configuring DHCP to give out addresses in the 192.168.1.0/24 subnet, but only from 192.168.1.2 to 192.168.1.100. Weve also been asked to not give out 192.168.1.50 as this has been hardcoded in the local fileserver. The lease time should only be 1 hour, and the default gateway should be 192.168.1.1

This

is

how

we

do

it

on

the

IOS

we

know

and

love:

>conf t #ip dhcp pool 192.168.1.0/24 #network 192.168.1.0 255.255.255.0 #default-router 192.168.1.1

#lease 0 1 #exit #ip dhcp excluded-address 192.168.1.101 192.168.1.255 #ip dhcp excluded-address 192.168.1.1 #ip dhcp excluded-address 192.168.1.50

Now

on

JunOS:

> configure # edit system service dhcp # set default-lease-time 3600 # set router 192.168.1.1 # set pool 192.168.1.0/24 address-range low 192.168.1.2 high 192.168.1.100 # set pool 192.168.1.0/24 exclude-address 192.168.1.50

There are extra things you can add to both, like domain name and so on, but I wanted a quick and dirty comparison between the 2. Remember that you will need an interface in the scope on either router in order for DHCP to actually work. Lets now say that we do have a DHCP server. This server is on another subnet, and so DHCP requests wont get through (as they are broadcasted). Consider the following topology:

Both IOS and JunOS allows you to configure the router as a DHCP relay agent. This is how its done. On IOS its extremely simple. All you need to do is put the following command on the interface receiving the broadcast. In this topology itll be the interface connected to the switch and workstation the user is on

>conf t # int fa0 # ip helper-address 10.1.1.1On JunOS its just as simple. The configuration is not put on a particular interface, rather you specify which interface will be receiving the broadcast.

> configure # set forwarding-options helpers bootp interface em1

# set forwarding-options helpers bootp server 10.1.1.1

OSPF, Posted in OSPF , 0 Comments

OSPF (Open Shortest Path First) is a classless, link-state routing protocol. The current version of OSPF for IPv4 is OSPFv2 introduced in RFC 1247 and updated in RFC 2328 by John Moy. In 1999, OSPFv3 for IPv6 was published in RFC 2740. OSPF has a default administrative distance of 110, and is denoted in the routing table with a route source code of O. OSPF is enabled with the router ospf process-id global configuration command. The process-id is locally significant, which means that it does not have to match other OSPF routers in order to establish adjacencies with those neighbors. The network command used with OSPF has the same function as when used with other IGP routing protocols, but with slightly different syntax. Router(config-router)#network network-address wildcard-mask area area-id The wildcard-mask is the inverse of the subnet mask, and the area-id should be set to 0. OSPF does not use a transport layer protocol, as OSPF packets are sent directly over IP. The OSPF Hello packet is used by OSPF to establish neighbor adjacencies. By default, OSPF Hello packets are sent every 10 seconds on multiaccess and point-to-point segments and every 30 seconds on non-broadcast multiaccess (NBMA) segments (Frame Relay, X.25, ATM). The Dead interval is the period of time an OSPF router will wait before terminating adjacency with a neighbor. The Dead interval is four times the Hello interval, by default. For multiaccess and point-to-point segments, this period is 40 seconds. For NBMA networks, the Dead interval is 120 seconds. For routers to become adjacent, their Hello interval, Dead interval, network types and subnet masks must match. The show ip ospf neighbors command can be used to verify OSPF adjacencies. The OSPF router ID is used to uniquely identify each router in the OSPF routing domain. Cisco routers derive the router ID based on three criteria and with the following precedence:

1. Use the IP address configured with the OSPF router-id command. 2. If the router-id is not configured, the router chooses highest IP address of any of its loopback interfaces. 3. If no loopback interfaces are configured, the router chooses highest active IP address of any of its physical interfaces. RFC 2328 does not specify which values should be used to determine the cost. Cisco IOS uses the cumulative bandwidths of the outgoing interfaces from the router to the destination network as the cost value. Multiaccess networks can create two challenges for OSPF regarding the flooding of LSAs, including the creation of multiple adjacencies - one adjacency for every pair of routers, and extensive flooding of LSAs (Link-State Advertisements). OSPF elects a DR (Designated Router) to act as collection and distribution point for LSAs sent and received in the multiaccess network. A BDR (Backup Designated Router) is elected to take over the role of the DR should the DR fail. All other routers are known as DROthers. All routers send their LSAs to the DR, which then floods the LSA to all other routers in the multiaccess network. The router with the highest router ID is the DR, and the router with the second highest router ID is the BDR. This can be superseded by the ip ospf priority command on that interface. By default, the ip ospf priority is "1" on all multiaccess interfaces. If a router is configured with a new priority value, the router with the highest priority value is the DR, and next-highest the BDR. A priority value of "0" means the router is ineligible to become the DR or BDR. A default route is propagated in OSPF similar to that of RIP. The OSPF router mode command,defaultinformation originate is used to propagate a static default route. The show ip protocols command is used to verify important OSPF configuration information, including the OSPF process ID, the router ID and the networks the router is advertising.

Tuning OSPF Performance, Posted in OSPF , Tutorials , 0 Comments

In this blog post we are going to discuss some OSPF features related to convergence and scalability. Specifically, we are going to discuss Incremental SPF (iSPF), LSA group pacing, and LSA generation/SPF throttling. Before we begin, lets define convergence as the process of restoring the stable view of network after a change, and scalability as the property of the routing protocol to remain stable and well-behaving as the network grows. In general, these two properties are reciprocal, i.e. faster convergence generally means less stable and scalable network and vice versa. The reason for that is that faster convergence means that the routing protocol is more sensitive to oscillating or noisy processes, which in turn makes it less stable.

Incremental SPFThe classic Dijkstra SPF algorithm complexity (or roughly saying, the process run-time) depends on the particular network topology, but it is said to be proportional to N*log(N) in a non-densely connected topology, where N is the number of nodes in the area, see [RFC1245]. The computation complexity used to be a limiting factor for old, slow routers of the 90s, where a single SPF run could hog the CPU dramatically. Modern routers take an order of tens, max hundreds of milliseconds for single full SPF runs even for the largest topologies. The runtime could be further reduced using the SPF algorithm optimization know as incremental SPF, which has been developed quite some time ago see [ARPOPT] (notice the year 1980 on the paper and the name of the main author its no other than Eric Rosen!). The implementation might look a bit sophisticated, but the main idea of iSPF is keeping the SPT structure after the first SPF calculation and using it for further computation optimizations. As you remember, the goal of SPF is building an SPT (shortest-path tree) on the network topology graph, rooted at the node that runs the computations. Look at the sample topology (taken from [JDOYLE]) and the SPT for router R1 below:

If R1 would retain the SPT after SPF calculations (at the expense of extra memory) the following three properties could be used for SPF calculation optimization: Property 1 If a node added or removed to or from the topology appears to be a leaf node to the saved SPT, there needs to be a very simple computation performed to add new routes. Essentially, the existing tree is

simply extended by one node and distance-vector like computations can be performed:

The same optimization property might be utilized when a stub link is added or removed to or from any node in the network. Property 2 There is a link failure, and the link is NOT part of the saved SPT. For example, consider the link between R4 and R5 fails. This link is not part of the saved SPT, and therefore, there is no need to perform any SPF calculation at all!

Even though there is great benefit in not making any SPF calculations, its hard to predict how many link failures would cause such effect. Besides, different routers would have different SPTs and a link failure that does not affect one SPT, might affect the others. Notice that in the case of transit link addition or link cost change, i.e. in the case when graph connectivity increases, this property would not work and the new tree should be built. Property 3: The last property is more generic. Assume there is a transit link failure in the topology and it affects a part of the saved SPT, which means properties (1) and (2) do not apply. For example, imagine there is a link fault between R2 and R4. Still, we only need to re-calculate the paths for the nodes downstream of the failure, based on our existing SPT. So the router would initiate SPT calculations from R1 to R4 only, not ever bothering with other nodes. However, if there is a link failure between R1 and R5, then the router would have to recalculate the paths to R5, R6 and R7 the nodes on the downstream tree under the failed link.

One effect is that the father away from the root node the failure is, the less computations potentially have to be done. Even though remote link failures take more time to propagate to the local node via LSA flooding, they result in shorter iSPF run-time, as the amount of downstream affected nodes is smaller. Once again, since different routers have different SPTs for the topology, the same failure may have different effects on iSPF efficiency for different routers. Another important fact is that this feature performs better in sparsely connected networks. In the asymptotic case of a fully-meshed topology, a single transit-link failure would cause re-running the SPF for all nodes, resulting in the same performance as classic SPF.

iSPF and PRCAmong all the iSPF properties, property (1) is probably the most important and effective in practice. This property puts OSPF on par with the Partial Route Computation (PRC) feature found in IS-IS. The PRC feature made ISIS very effective in situations when new stub links were added, as ISIS propagates network reachability information separately from topological information, thanks to LSPs TLV-based structure. Different TLVs are used for IS-node reachability information and network prefixes associated with the node. When an ISIS router receives an LSP that only lists network prefix change, it performs partial SPF recalculation, based on distance-vector logic, by adding the new prefix in the routing table with the cost of reaching the originating router, similar to property (1). Only a change in the transit link status would trigger

full SPF computation in ISIS. In the past, the PRC feature made ISIS more scalable for a single area design when compared to OSPF. The problem with OSPF was that topological information and network reachability information for router links were conveyed in a single type-1 LSA. Whether there was a transit link failure or simply a stub link going up or down, OSPFv2 had to perform complete SPF calculation as this was reflected using the same event that would report a network prefix or metric. Only type-3 and type-5 LSAs would have triggered PRC in OSPFv2. There was a trick to make better use of PRC with OSPFv2 advertise all connected interfaces via redistribution, which resulted in type-5 LSAs being flooded. However, the tradeoff was that type-5 LSAs flooding scope was the whole routing domain, plus type-5 LSAs have the largest size among other LSA types, not to mention slightly added configuration complexity. The introduction of iSPF made OSPF as effective as ISIS as far as SPF computation goes. To be fair though, we should mention that iSPF was also added to ISIS, so now both protocols are equally effective for SPF computations. By default, iSPF is disabled and could be enabled using the command ispf under the routing process configuration mode. By enabling iSPF you will make OSPF use slightly more memory than by default, propotional to the 2*N where N is the number of nodes in the area. This due to the fact that a spanning tree for N nodes has exactly N-1 edges.

LSA Group PacingAs you remember, OSPF LSAs have two important attributes age and checksum. The age field is needed to guarantee wiping of the outdated information and the checksum is needed to maintain the information integrity. By default, the maximum LSA age is one hour, and the originating router is supposed to re-flood the LSAs every 30 minutes. In addition to that, the router needs to run periodic check-summing on all LSAs. The way Cisco routers originally did that was by running a refresh procedure every 30 minutes and refreshing every self-originated LSA in the database, no matter how old it was. This would result in sudden CPU spikes every 30 minutes in case of large databases in addition to bursty LSA flooding. Every router in the routing domain in turn would have to receive and process a large amount of LSA information. This is a good example of a synchronization problem. In addition to this refreshing, every 10 minutes a router would run periodic check-summing and an aging procedure, and flush any aged non-self-originated or corrupted LSAs. In order to alleviate the 30-minute refreshing problem, Cisco IOS implemented an independent aging procedure for every LSA in the LSDB. A short period scheduler would scan the database and decrement every LSAs age individually. Only LSAs that were close to their half-life of 30 minutes would be re-flooded. This is the opposite of doing a complete refresh every 30 minutes. However, this process would result in many quick floods during the 30-minutes interval, as a result of independent aging. This might be viewed as a fragmentation problem. The balanced solution is known as group pacing. Instead of refreshing an LSA instantly as soon as it reaches its half-life age, the router would wait a pacing interval amount of time to group various LSAs with similar age. The pacing interval is normally shorter than the 30 minute grand interval and defaults to 240 seconds. Thus, a router would attempt to group LSAs with similar lifetime and refresh them simultaneously.

Look at the diagram above for the illustration of the concept. Original refreshing procedure would produce large bursts of LSA flooding every 30 minutes. The individual aging would result in fragmentary re-flooding. The group pacing feature would introduce controlled bursting the shorter the interval, the smaller are the bursts. The same pacing concept could be applied to check-summing and aging. Specifically, if we run individual timers for ever LSA, and aim at check-summing and aging every 10 minutes, we would get the same fragmentary CPU-spiking patterns. Instead of running the process individually for every LSA, grouping based on the same group pacing interval could be used for the purpose of check-summing and aging, so a small batch of LSAs that are close to being aged out or check-summed are processed together. The IOS commands to control the various group pacing intervals are:

timers pacing ?

flood lsa-group retransmission

OSPF flood pacing timer OSPF LSA group pacing timer OSPF retransmission pacing timer

The LSA group interval is used for the refreshing/aging/checksumming grouping discussion above. The retransmission keyword is a bit more interesting. Every time the router needs to retransmit an unacknowledged LSA over an adjacency, it might wait some time to group it with other un-acknowledged LSAs. This is the same grouping principle, which allows for better packing of LSA information in IP packets. Of course, the retransmission grouping interval is much shorten than LSA grouping and measured in milliseconds. The flood keyword serves a similar purpose, but controls the interface LSA flood list. For every interface the OSPF process keeps the flood list, which contains the LSAs that have been generated or received and are destined to be flooded out of this interface. Instead of flooding every LSA as soon as it hits the list, the OSPF process would wait the pacing interval for more potential LSAs and pack them in a single update packet. This process optimizes bandwidth and CPU usage on both sides of the adjacency. Of course, the resolution for this timer is set in milliseconds, due to the real-time nature of the process. So what are the optimal group pacing timer values? Probably the defaults, which could be found as follows: Rack1R5#show ip ospf | inc transmission|pacing LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs For very large LSDBs, you generally want to set the LSA group pacing timer to be inversely proportional to the size of database. This ensures less surges when flooding large LSA batches. Keep in mind that tuning LSA group pacing improves OSPF performance and thus protocol scalability, but does not affect convergence speed.

SPF and LSA Generation ThrottlingThrottling is the general process of slowing down responses to the frequently oscillating events such as link flaps. The general idea is to reduce resource wastage in unstable situations and wait till the situations calm down. If you have a link that flaps up and down frequently, you may want to suppress the links state information flooding until it becomes stable (either stable down or up). Throttling is critical for ensuring network stability and thus protocol scalability. This procedure is also very similar to event dampening, though they differ a little bit dampening would suppress events while throttling simply increases the response times, hoping that oscillations would stop or at least the responses do not follow the same oscillating pattern but filter the high-frequency noisy events. The general idea is as follows. When an event occurs, e.g. a link goes down or new LSA arrives, do not respond to it immediately, e.g. by generating an LSA or running SPF, but wait some time, hoping to accumulate more similar events, e.g. waiting for the link to go back up, or more LSAs arriving. This could potentially save a lot of resources, by reducing the number of SPF runs or amount of LSAs flooded. The

question is how long should we hold or throttle the responses? Ideally, it would be nice to adapt this interval according to the network conditions i.e. make it longer when the network is unstable and shorter under stable conditions. Cisco implements an exponential back-off timer to implement this idea. Here is how it works. The exponential back-off is defined using three parameters start interval, increment, andmax_wait time specified using the command timers throttle spf start increment max_wait.Suppose the network was stable for a relatively long time, and then an event such as LSA arrival has occurred. The router delays SPF computations for the start amount if milliseconds and sets the next hold-time to increment milliseconds. Next, if an event occursafter the start wait window expired, the event would be held for processing until the incrementmilliseconds window expire, but the next hold-time would be doubled, i.e. set to 2*increment. Effectly, every time an event occurs during the current hold-time window, the processing is delayed until the current hold-time expires and the next hold-time interval is doubled. The hold-time grows exponentially until it reaches the max_wait value. After this, every event received during current hold-time window would result in the next interval being equal to the constantmax_wait. This ensures that exponential growth is limited by a ceiling value. If there are no events for the duration of 2*max_wait milliseconds, the hold-time window is reset back to thestart value, assuming the network returned to stable condition. Look at the figure below.

The first event schedules SPF run in start milliseconds. At the same time, the next interval is set to increment milliseconds. Since there is an event during the second hold interval, the third hold interval is set to 2xincrement. There is another event during the third window, and this sets the forth window to 4xincrement. However, in our case this exceeds the max_wait value, and thus the forth hold-time interval equals max_wait milliseconds. There are more events during the forth interval, but since the maximum holdtime value has been reached, the fifth interval is set tomax_wait milliseconds. Since there are no events during the firth and sixth intervals, the hold-time is reset to start milliseconds again. Although SPF response to LSA arrivals has been used in the above examples, the same idea applies to new LSA generation as response to local link events. This could be controlled using the LSA generation throttling command timers throttle lsa start increment max_wait. Both SPF and LSA generation throttling are on by default and you may probably want to reduce their values only if you really need to speed up your network convergence. However, keep in mind that improving response time automatically results in less stable routing protocol behavior.

Summary and Further ReadingWe briefly discussed three extensions to OSPFv2 protocol: iSPF, LSA group pacing and event throttling. The first two features improve OSPF performance, while the last one allows for better scalability and dynamic adaptation to unstable network topologies. Even though these and other OSPFv2 enhancements significantly increase its scalability, the more general design features such as area partitioning, network summarization and event dampening should not be neglected. Lastly, if you havent done so yet, I would strongly suggest you to read the following publications: [RFC1245] OSPF Protocol Analysis, J. Moy [JDOYLE] OSPF and IS-IS: Choosing an IGP for Large-Scale Networks, J. Doyle [LSAP] OSPF LSA Group Pacing [THROT] OSPF Shortest Path First Throttling [ARPOPT] ARPANET Routing Algorithm Improvements E. Rose et al

OSPF Prefix Filtering using Forwarding Address, Posted in OSPF , Tutorials , 0 Comments

This post is dedicated to one esoteric OSPF external route filtering method based on hiding OSPF Forwarding Address. Recall the meaning of OSPF FA. This is a special field used on OSPF type 5 and 7 LSAs to convey the information of the external route source. The purpose of FA is to optimize forwarding in situations where the external route source is connected to a shared segment. Here is an example:

In this scenario, R2 is the ASBR redistributing RIP into OSPF. At the same time, R1 does not perform redistribution. Per normal OSPF rules, the external prefixes appear attached to R2 and thus both R1 and R4 should route across R2 to get to the networks behind R3. In order to avoid this suboptimal routing, OSPF may insert a non-zero FA field into type-5 LSAs, containing the IP address of R3: 155.1.123.3. This will instruct R1 and R4 to route to R3 directly, instead of going across R2. Now an important thing here the FA address must be accessible via the normal routing tables of R1 and R4. This requires the external link to be advertised into OSPF by some means, e.g. by enabling OSPF on the external link between R1, R2 and R3. Redistribution cannot be used for this purpose, as there are some restrictions. Here is a complete list of the requirements for enabling the OSPF FA in type 5 LSAs:

OSPF is enabled on the ASBRs next hop interface AND ASBRs next hop interface is non-passive under OSPF AND ASBRs next hop interface is not point-to-point AND ASBRs next hop interface is not point-to-multipoint AND ASBRs next hop interface address falls under the network range specified in the router ospf command. (You may find more information by reading the article on Ciscos website named Common Routing Problems with OSPF Forwarding Address. Notice the requirement for having the network type of broadcast or non-broadcast this makes sense if you think that in real life you need to have a shared link with multiple exit points. However, you may forcefully configure a physically point-to-point link for the mentioned OSPF network types to enforce the effect of FA assignment.

Application to FilteringBased on the requirement that FA needs to be reachable for the respective external routes to be considered, we may devise a filtering scheme for external routing information. More specifically, if there is a way to filter out the prefix corresponding to the FA, this will stop all routers that lost this information from using the external prefixes. There are two cases here.

1. The FA prefix is filtered at the ASBR. Since OSPF must be enabled on the external link, the only option left is configuring a different area on the external link and using the inter-area route filter (area x filter-list) to block the prefix from propagating further. 2. The FA prefix is filtered at the ABR(s) of the area containing the ASBR. You may use any of the methods described in the post OSPF Route Filtering Demystified to prevent type-3 LSA generation, e.g. use the inter-area route filtering. Lets see how this could be done in a practical scenario. Below is a diagram of a single-area OSPF implementation. R1 redistributes RIP routes into OSPF.

We enable OSPF area 0 on R1s Frame-Relay interface (which uses the default non-broadcast OSPF network type) and apply inter-area route filtering: R1: router ospf 1 area 168 filter-list prefix TO_AREA168 in redistribute rip subnets network 148.1.0.1 0.0.0.0 area 0 network 148.1.18.1 0.0.0.0 area 168 ! ip prefix-list TO_AREA168 seq 5 deny 148.1.0.0/24 ip prefix-list TO_AREA168 seq 10 permit 0.0.0.0/0 le 32 Now look at the OSPF database in SW2: Rack1SW2#sh ip ospf database external OSPF Router with ID (150.1.8.8) (Process ID 1) Type-5 AS External Link States LS age: 505 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 148.1.1.0 (External Network Number ) Advertising Router: 150.1.1.1 LS Seq Number: 8000005B

Checksum: 0xC8B4 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 148.1.0.3 External Route Tag: 0 Now check if this route is present in the routing table. Also make sure the FA address is not in the routing table too: Rack1SW2#sh ip route 148.1.1.0 % Subnet not in table Rack1SW2#sh ip route 148.1.0.3 % Subnet not in table Rack1SW2#show ip ospf database summary 148.1.0.0 OSPF Router with ID (150.1.8.8) (Process ID 1) Now, remove the inter-are route filter in R1 and check SW2s routing table once again. Rack1R1(config-router)#no area 168 filter-list prefix TO_AREA168 in Rack1SW2#sh ip route 148.1.0.3 Routing entry for 148.1.0.0/24 Known via "ospf 1", distance 110, metric 65, type inter area Last update from 148.1.18.1 on Vlan18, 00:00:16 ago Routing Descriptor Blocks: * 148.1.18.1, from 150.1.1.1, 00:00:16 ago, via Vlan18 Route metric is 65, traffic share count is 1 Rack1SW2#sh ip route 148.1.1.0 Routing entry for 148.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 65 Last update from 148.1.18.1 on Vlan18, 00:00:16 ago Routing Descriptor Blocks: * 148.1.18.1, from 150.1.1.1, 00:00:16 ago, via Vlan18 Route metric is 20, traffic share count is 1 Finally, a few words on type-7 LSAs. Per the NSSA area RFC, the use of FA is mandatory with these LSAs. The reason is that there is only one 7-to-5 translating ABR and this might result in suboptimal routing without the use of FA. This makes the use of the special conditions mentioned previously unnecessary. You may always use FA-based prefix filtering with the external information conveyed in type-5 LSAs translated from type-7 LSAs.

SummaryOSPF is a complicated protocol, which combines many features of distance-vector protocols with link-state behavior. Brought together, some of the features allow for sophisticated filtering techniques, not possible normally with pure link-state behavior. Using FA filtering is a good example of this phenomenon.

Understanding OSPF Transit Capability, Posted in OSPF , Tutorials , 0 Comments

The feature we are going to talk about today may look a bit convoluted, but it demonstrates core OSPF behavior: combining link-state and distance-vector behaviors. The command capability transit was introduced in IOS 12.3T and is on by default. However, the description is rather confusing and does not explain the underlying mechanics. We are going to give an in-depth look at this feature now.

What is Transit Capability?In short, this is a special property of a non-backbone area that allows this area to transport traffic for other areas (either zero or non-zero). Per the OSPF definition, a transit area is the area that has a virtual-link connecting two or more ABRs attached to this area. Thus, having a virtual-link provisioned across the area is the necessary thing to make the area transit. In fact, its just an alternate definition of a transit area. So the first thing we want to find out is what kind of mechanism is a virtual-link?

What are Virtual-links?The idea of a virtual link is to extend area 0 across non-backbone areas. There are two main situations when you may want to do this: 1) Due to design considerations, where you have an area not directly connected to the backbone area. This could be a result of two networks merging together. An example is when you have to connect two previously disconnected backbone areas. The purpose, of course, is allowing two OSPF topologies to exchange routing information dynamically. 2) Using a non-backbone area to reach destinations in other areas. The main idea of OSPF inter-area routing is that all areas should be communicating across the backbone, area 0. The backbone area is used to exchange the routing information in a distance-vector manner, requiring the star-topology to avoid routing loops. Per the RFC, the router is only considered an ABR if it has an interface in Area 0 and ignores summary LSAs delivered across the non-backbone areas. This ensures the simple loop free star topology. Look at the diagram below. Here the paths between R4 and R5, and R2 and R5, are slow and OSPF metrics reflect this. The fastest way for R4 to reach the subnet 163.X.12.0/24 is to go over the FR cloud to R3 and then to R1.

However, in reality, in order for R4 to reach the subnet 163.X.12.0/24, it needs to traverse across the slow Serial link to R5 as this is where Area 0 is located. Even though Area 1 provides a shorter path, R3 will never advertise it as it does not have an interface in area zero, and R5s summary sent into area 1 will be ignored in favor of the summary received via area 0! The way to avoid this is by providing a virtual link between R4 and R5, or R4 and R3, or both of these links. Lets see how this allows for lifting the restriction of ignoring the inter-area routes received via non-backbone area.

How Virtual-links WorkVirtual links are seen as point-to-point links in the topology graph, belonging to area 0. When you configure the virtual link you specify the transit area and the endpoint router-ids. Based on the router-ids and the intraarea shortest-path tree, the path for the virtual link is calculated and the hello packets (unicast!) are exchanged. After this, OSPF follows the regular adjacency establishment process. This adjacency is treated at P2P like we mentioned above and used to exchange OSPF LSAs. However, virtual-links are only used to flood specific LSAs: the router, network, and summary LSAs found in area 0. Type 5 LSAs are not flooded across the virtual links. Here is the reason why. As you know, Type 1,2,3, and 4 LSAs have the flooding scope of a single area. Thus, if you have a virtual link connecting two ABRs,

you cannot flood LSAs across the transit area, since this area is different from Area 0. However, external LSAs have the flooding scope of OSPF autonomous system, and thus they are flooded across the area anyways (unless its stub), so there is no need to duplicate information across the virtual link. Obviously, a stub area cannot be transit due to this reason. After LSAs have been loaded across the virtual link, they could be used to run SPF and populate the routing table. Initially, all prefixes learned across a virtual link are assigned the next hop value of virtual-link. This value should be resolved to something physical. Here is where it becomes a little trickier. As the LSAs have been received over a P2P link connecting two ABRs, it makes sense to avoid SPF calculations and simply put the prefixes in the routing table using the metric X+Y, where X is the cost of reaching the other ABR, across the virtual link and Y is the cost the other ABR advertises for this prefix. This is precisely what OSPFv1 did and what Cisco IOS was doing prior to supporting transit capability documented in OSPFv2 standard. Therefore, in the case of OSPFv1 (or OSPFv2 + no capability transit) deployed in the topology documented on the diagram above, if you provision a virtual-link between R4 and R5, R4 will be able to reach the prefixes across Area 1 following the same path that the virtual link takes. What if we want to use the PVC R4-R3 that has more bandwidth compared to the PVC used to reach R5? You will have to provision a virtual-link R4 to R3 then. Could you use a daisy-chained virtual-link as follows: R4-R5-R3? You could, but then R4 will choose to reach the 163.X.12.0/24 subnet across R5, as it has to follow the virtual-link path! Even though R3 will inject a summary LSA for 163.X.12.0/24 into Area 1 as an ABR, R4 will learn this prefix via the virtuallink to R5 and use the path via this ABR. Here is an example: R3, R4, and R5 are configured for OSPFv2 but all have capability transit disabled. There is a daisy chain of virtual links R4->R5->R3 configured on these routers. R4 will prefer the path across R5, even though the shortest path would be across R3, and R3 advertises the corresponding summary into Area 1! Virtual links are provisioned between R3-R5 and R4-R5: R5#show ip ospf virtual-links Virtual Link OSPF_VL1 to router 150.1.3.3 is up Run as demand circuit DoNotAge LSA allowed. Transit area 1, via interface Serial0/0/0, Cost of using 64 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:01 Adjacency State FULL (Hello suppressed) Index 3/6, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec Virtual Link OSPF_VL0 to router 150.1.4.4 is up Run as demand circuit DoNotAge LSA allowed. Transit area 1, via interface Serial0/0/0, Cost of using 64 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:06 Adjacency State FULL (Hello suppressed) Index 2/5, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec

The preferred path is across R5: R4#show ip route ... 163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks C 163.1.45.0/24 is directly connected, Serial0/1/0 O 163.1.0.3/32 [110/64] via 163.1.0.3, 05:27:57, Serial0/0/0 C 163.1.0.0/24 is directly connected, Serial0/0/0 O 163.1.0.5/32 [110/64] via 163.1.0.5, 05:27:57, Serial0/0/0 O IA 163.1.12.0/24 [110/193] via 163.1.0.5, 00:00:46, Serial0/0/0 ... In the above output, 163.X.12.0/24 is seen as an inter-area route via R5. However, we can see that R3 advertises the same summary with a better cost! R4#sh ip ospf database summary 163.1.12.0 OSPF Router with ID (150.1.4.4) (Process ID 1) Summary Net Link States (Area 1) Routing Bit Set on this LSA LS age: 2 (DoNotAge) Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 163.1.12.0 (summary Network Number) Advertising Router: 150.1.3.3 LS Seq Number: 80000001 Checksum: 0xBBF1 Length: 28 Network Mask: /24 TOS: 0 Metric: 65 But R4 ignores it due to the fact that its not received via Area 0! So how does OSPFv2 improve upon this described behavior? It uses the inter-area routes received via the non-backbone area as a source of better information!

How Does OSPFv2 Perform Transit Path CalculationsOSPFv2 implements some improvements over the simple procedure of next-hop resolution for virtual-link connection. Specifically, it relies on the fact that the inter-area routes flooded into the transit area are congruent to the virtual-link and thus may not result in a routing loop they are advertised following the loopless tree topology. Thus, if those inter-area prefixes provide a better cost than the virtual-link path (X+Y as in the previous description) they could be used in place of the same prefixes learned via the virtual-link! However, this is optimization hold true only for inter-area prefixes injected from non-backbone areas, and the intra-area routes found in Area 0 itself. We are going to review the case of the inter-area routes first. Prior to that, we will quickly outline how OSPFv2 detects if an area has the Transit Capability. This is done in a pretty straighforward manner. If an ABR detects that it has a fully adjacent virtual link coming from Area A, it floods all of its router LSAs into this area with the special V bit set. All routers in Area A will see that

bit set, and learn that the area is effectively supporting the transit feature (V stands for virtual-link).

OSPF Transit Capability for Inter-area RoutesBack to our diagram above. If there is a virtual-link terminating on R3, this router is an ABR (per the RFC), and generates summary LSAs for the prefixes learned from Area 2. These summaries are flooded across Area 1 and R4 learns them. Next, R4 will receive the summary LSAs for the SAME prefixes over the virtual link from R5. When the OSPF process in R4 computes the best routes, it takes into account the fact that Area 1 is transit. Based on this, it attempts to find a BETTER path for the prefixes found in the summary-LSAs learned over the virtual link by looking at the inter-area routes received from Area 1. If it finds a match with a better metric, it simply uses that route over the one received across the virtual link! Look at the routing table of R4 when all the routers (R3, R4, and R5) have the capability transit enabled: The prefix 163.X.12.0/24 is now reachable via R3, even though the virtual link from R4 links us to R5! R4#show ip route ospf 163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks O 163.1.0.3/32 [110/64] via 163.1.0.3, 05:44:22, Serial0/0/0 O 163.1.0.5/32 [110/64] via 163.1.0.5, 05:44:22, Serial0/0/0 O IA 163.1.12.0/24 [110/129] via 163.1.0.3, 00:00:02, Serial0/0/0 ... Effectively, even though R4 has the same prefix received via Area 0, it now prefers path via R3 due to the transit capability feature. Check the summary LSA advertised by R3: R4#show ip ospf database summary 163.1.12.0 ... LS age: 1115 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 163.1.12.0 (summary Network Number) Advertising Router: 150.1.5.5 LS Seq Number: 80000001 Checksum: 0x8EE5 Length: 28 Network Mask: /24 TOS: 0 Metric: 10063 Summary Net Link States (Area 1) LS age: 1122 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 163.1.12.0 (summary Network Number) Advertising Router: 150.1.3.3 LS Seq Number: 80000001 Checksum: 0xBBF1 Length: 28 Network Mask: /24 TOS: 0 Metric: 65

LS age: 1127 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 163.1.12.0 (summary Network Number) Advertising Router: 150.1.5.5 LS Seq Number: 80000002 Checksum: 0x8CE6 Length: 28 Network Mask: /24 TOS: 0 Metric: 10063 However, this procedure will NOT work if you summarize the prefixes from Area 2 into Area 1 on R3. This is because there are no longer an exact match between prefixes, and OSPF cannot use them for path optimization. R3: router ospf 1 area 2 range 163.1.0.0 255.255.240.0 R4#show ip route ospf 163.1.0.0/16 is variably subnetted, 8 subnets, 3 masks O 163.1.0.3/32 [110/64] via 163.1.0.3, 05:48:51, Serial0/0/0 O IA 163.1.0.0/20 [110/65] via 163.1.0.3, 00:00:05, Serial0/0/0 O 163.1.0.5/32 [110/64] via 163.1.0.5, 05:48:51, Serial0/0/0 O IA 163.1.12.0/24 [110/10127] via 163.1.0.5, 00:00:00, Serial0/0/0 However take notice that you CAN summarize the inter-area prefixes in this case, even though it is undesirable for optimization. It is possible to summarize prefixes from non-backbone area into a transit area, but we will see that you cannot summarize prefixes from backbone area into a transit area.

What If the Area on the Other Side is Area 0?Now, what if instead of Area 2 we have Area 0? Thats an interesting scenario, because in this case, R4 will be receiving the information about 163.X.12.0/24 via type-1 LSAs from R5 and should prefer intra-area routes over inter-area at all times. However, the above described transit-area optimization works in this case as well! That is, R4 will look for a better path to reach the prefixes learned in router-LSAs via the inter-area LSAs in the transit area! The procedure only works for Area 0 intra-area prefixes, and not for any other intra-area routes. Here is what it looks like in a live scenario. Consider the diagram below, which is the same as the previous one, just having Area 2 changed to Area 0. All ABRs have the capability transit turned on.

Look at R4s routing table and notice that it has an intra-area route (via area 0) with the next hop pointing to R3: R4#show ip route ospf 163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks O 163.1.0.3/32 [110/64] via 163.1.0.3, 05:55:13, Serial0/0/0 O 163.1.0.5/32 [110/64] via 163.1.0.5, 05:55:13, Serial0/0/0 O 163.1.12.0/24 [110/129] via 163.1.0.3, 00:00:07, Serial0/0/0 O 163.1.13.0/24 [110/65] via 163.1.0.3, 00:00:50, Serial0/0/0 O 163.1.25.0/24 [110/10063] via 163.1.0.5, 00:00:30, Serial0/0/0 If we check the summary LSAs advertised by R3, we will find the same prefix for 163.X.12.0/24 that should appear in R4s routing table as an inter-area route, but INSTEAD is used as an corrector for the inter-area path learned via Area 0! R4#sh ip ospf database summary 163.1.12.0 OSPF Router with ID (150.1.4.4) (Process ID 1) Summary Net Link States (Area 1) LS age: 137

Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 163.1.12.0 (summary Network Number) Advertising Router: 150.1.3.3 LS Seq Number: 80000001 Checksum: 0xBBF1 Length: 28 Network Mask: /24 TOS: 0 Metric: 65 Whats really interesting, is that an intra-area route actually takes the INTER-area path! The transit capability essentially allows the use of non-backbone inter-area routes to optimize inter-area paths and area 0 intra-area paths IF the area in question is transit!

Virtual Links and SummarizationWe remember that this optimization could be broken by using summarization (area ranges) at the ABRs (R3 in our case). However, in the case of source Area 0, summarization will not work! R3 will IGNORE the range statements if they cover to the prefixes in area 0 and there is an activevirtual-link across any area. Whats the problem with that? The reason is that area 0 is the core transit area, and the prefixes learned via it could be used to reach the other inter-area routes. Summarizing area 0 information, while injecting it in a transit area, might result in routing loops in reaching those prefixes, as the same information will flow unsummarized down the chain of virtual links. Thus, OSPF will never summarize backbone-area prefixes when injecting them into a TRANSIT area. You may validate this by configuring area range statements: R3: router ospf 1 area 0 range 163.1.12.0 255.255.240.0 ! R4#sh ip ospf database summary 163.1.0.0 OSPF Router with ID (150.1.4.4) (Process ID 1) R4#sh ip ospf database summary 163.1.12.0 OSPF Router with ID (150.1.4.4) (Process ID 1) Summary Net Link States (Area 1) LS age: 766 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 163.1.12.0 (summary Network Number) Advertising Router: 150.1.3.3 LS Seq Number: 80000001 Checksum: 0xBBF1 Length: 28 Network Mask: /24 TOS: 0 Metric: 65 This is the side-effect of the virtual-link configuration with area 0 ranges. What if we disable the transit capability? In that case, optimization breaks down, but the summarization works!

R3, R4, R5: router ospf 1 no capability transit

R4#sh ip ospf database summary 163.1.0.0 OSPF Router with ID (150.1.4.4) (Process ID 1) Summary Net Link States (Area 1) LS age: 29 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 163.1.0.0 (summary Network Number) Advertising Router: 150.1.3.3 LS Seq Number: 80000001 Checksum: 0x7296 Length: 28 Network Mask: /20 TOS: 0 Metric: 1 R4#sh ip route ospf 163.1.0.0/16 is variably subnetted, 7 subnets, 2 masks O 163.1.0.3/32 [110/64] via 163.1.0.3, 06:10:26, Serial0/0/0 O 163.1.0.5/32 [110/64] via 163.1.0.5, 06:10:26, Serial0/0/0 O 163.1.12.0/24 [110/193] via 163.1.0.5, 00:01:21, Serial0/0/0

SummaryWe outlined the idea of the Transit Capability found in OSPFv2 and not present in OSPFv1. The key idea is that the inter-area routes found in a transit area could be used to optimize the routing paths instead of simply following the paths carved by the virtual links (OSPFv1). We found that: 1) This procedure optimizes the paths for inter-area routes and backbone intra-area routes. 2) This procedure blocks Area 0 prefix summarization to prevent routing loops. 3) This behavior is different from the one used in OSPFv1, which was transiting across the virtual-link paths.

OSPF Areas, Part 5, the Totally Not-So-Stubby Area, Posted in OSPF , Tutorials , 0 Comments

As a former English Major at the University of Massachusetts, Amherst, I really loved the oxymoron. You remember thosesharply dull or cruel kindness. Well, the OSPF protocol has one whopper of an oxymoron in its special areas The Totally, Not-So-Stubby area! When we last left our Area 11 in Part 4 of this blog series, it was a Not-So-Stubby Area, with thedefaultinformation-originate command used on the Area Border Router (ABR) in order to ensure a default route existed in the area. Here is the topology, and a look at the existing routing table on R3:

R3#show ip route Gateway of last resort is 192.168.1.2 to network 0.0.0.0 33.0.0.0/24 is subnetted, 1 subnets C 33.33.33.0 is directly connected, Loopback33 172.16.0.0/24 is subnetted, 1 subnets O IA 172.16.10.0 [110/21] via 192.168.1.2, 00:00:14, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.10.10.0 [110/20] via 192.168.1.2, 00:00:14, FastEthernet0/0 C 192.168.1.0/24 is directly connected, FastEthernet0/0 44.0.0.0/24 is subnetted, 1 subnets C 44.44.44.0 is directly connected, Loopback44 O*N2 0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:09, FastEthernet0/0 R3# Notice I have highlighted some Type 3 LSAs that exist on this router. These, of course, are Inter-Area routes that are permitted into the Not-So-Stubby area. If we want to eliminate them, we need to make the area Totally Not-So-Stubby. Let me go to the Area Border Router (R2) and remove the command area 11 nssa default-informationoriginate and replace it with the command area 11 nssa no-summary. Now, with that accomplished, let us examine the OSPF database and the routing table on R3: R3#show ip ospf database OSPF Router with ID (3.3.3.3) (Process ID 1) Router Link States (Area 11) Link ID count 2.2.2.2 3.3.3.3 ADV Router 2.2.2.2 3.3.3.3 Age 6 181 Seq# Checksum Link

0x80000003 0x00A194 1 0x80000003 0x0060CD 1

Net Link States (Area 11) Link ID ADV Router Age Seq# Checksum

192.168.1.2

2.2.2.2

6

0x80000002 0x001199

Summary Net Link States (Area 11) Link ID 0.0.0.0 ADV Router 2.2.2.2 Age 12 Seq# Checksum 0x80000001 0x00FC31

Type-7 AS External Link States (Area 11) Link ID 33.33.33.0 44.44.44.0 ADV Router 3.3.3.3 3.3.3.3 Age 180 180 Seq# Checksum Tag 0x80000001 0x00F06E 0 0x80000001 0x0063DA 0

R3#show ip route Gateway of last resort is 192.168.1.2 to network 0.0.0.0 33.0.0.0/24 is subnetted, 1 subnets C 33.33.33.0 is directly connected, Loopback33 C 192.168.1.0/24 is directly connected, FastEthernet0/0 44.0.0.0/24 is subnetted, 1 subnets C 44.44.44.0 is directly connected, Loopback44 O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:00:17, FastEthernet0/0 R3# Notice that the Type 3 LSAs do indeed disappear from the area. Also, notice that we do not need to instruct the Area Border Router to send the default route any more. It happens automagically once again like in a Totally Stubby area. Of course the Type 7 LSAs still exist in the area as a method to transport the redistributed routes in to the Area Border Router for the Type 5 LSA conversion process. I sincerely hope you enjoyed this blog series on OSPF areas. As always, thanks for choosing INE to assist you in your Cisco certification needs. Keep following the blog of courseI want to do a post soon for one of our awesome CCIE 2.0 customers, Terry Vinson. Terry wants me to take on the powerful VLAN Access Control Lists (VACLs) feature of Catalayst switches.

OSPF Route Filtering Demystified, Posted in OSPF , Tutorials , 0 Comments

IntroThere was a lot of blogging related to OSPF topics recently. In this post, I would like to clarify some common misunderstandings that many people have about OSPF route filtering. I have seen so many folks wrongfully understanding the underlying behavior so its about time to make the things clear.

OSPF Data StructuresTo begin with, avoid using the term LSA filtering with OSPF. You cannot really filter LSAs with the exception of one special case you filter the network reachability information. To understand this in depth, start by recalling that OSPF deals with the following data structures:

1) Topological information. Outlines the connections in the graph describing the routers and the links in the network. This is what OSPF LSAs are about they contain information about attached links. Think of LSAs as the objects that correspond to the edges of the graph. LSAs are stored in the LSBD link state database. No real routes are stored in the LSDB, since this is the database for topological objects. However, routing or network reachability information is attached to the LSAs. 2) Network Reachability information. Contains the actual IP subnets. This information is associated with the network graph edges and you may think of it as leaves connected to the edges. Routing information does NOT describe any connectivity, just the prefix associated with the link. This information is contained in the LSAs, but as an attribute, and is used to populate the routing table i.e. the RIB. 3) Main routing table. This is the routers RIB, as OSPF does not have a RIB of its own, unlike BGP. This structure is used when OSPF generates new summary or external LSAs as we see later. 4) Routers routing table. This structure is unique to OSPF, and contains the IP addresses to reach the border routers ASBRs and ABRs. It is used when calculating the respective inter-area routes, by adding the router path cost to the respective prefix advertised by this router. You may display the contents of this data structure by using the command show ip ospf border-routers.

OSPF route calculation overview1) Routers establish adjacencies to flood topological information. The flooding process in OSPF is pretty complicated, and ensures the LSAs are delivered to all routers in a single area. As mentioned, topological information is carried in the form of LSAs and cannot be filtered, which it is essential to the OSPF algorithm. The only thing that limits LSA propagation is the flooding domain associated with the particular LSA type. Using the topological information learned, all routers within an area build the consistent graph of the network connections. 2) After all routers have a consistent topology view, they may calculate intra-area paths using the SPF algorithm and finally associate the network reachability information with the paths. This is where the secondary, leaf-level information comes in play. The leaves are attached to the paths and the routing table entries are calculated. So keep this in mind first LSA flooding, then LSDB population, then SPF computations, and finally the RIB population. 3) After the intra-area paths have been calculated, inter-area routes are computed based on type-3/4 LSAs contents for other area information summarization. This process uses a quick and simple distance-vector computation algorithm, without the need for SPF computations. The routers routing table is used extensively during this process.

When you can REALLY filter LSAsNow, back to the case of LSA filtering. Some may recall the commands ip ospf database-filter all out or neighbor database-filter all out. Good point, but what it does is prevent the OSPF process from sending any LSAs out of the particular adjacencies. This could be done only if youre sure that the LSAs will be flooded to all routers in the area by some other means. This is the special case Ive been talking about previously. The purpose of this feature is to compensate for the absence of mesh-groups and limit the

amount of flooding on NBMA subnets shared by many routers.

Overview of OSPF route-filteringAll right, so if you cannot really filter LSAs, how do you perform route filtering with OSPF? Using the term route filtering is the correct way of saying LSA filtering. You may apply route filtering to OSPF using the following two general methods: 1) Preventing optimal paths generated by OSPF from entering the RIB. This is what you can do by applying the command distribute-list in under the OSPF process. This affects routes installed in the RIB. There is one special extension of this method to filtering the FA (forwarding address) to block external OSPF routes. 2) Affecting the LSA generation process, by changing the source information used to generate the LSAs. There is a bunch of ways to do this, each specific to a particular LSA type. To understand this completely, we need to recall all the basic LSA types and their flooding scopes.

How OSPF generates different LSA typesLSA type 1. Describes an attached circuit, different link types. This is the fundamental building block of the topology graph. This LSA is flooded within the single area and never gets past the ABRs. The sources of information for LSA type-1 are the directly connected links. If you want to remove the network reachability information, just remove the link LSA type 2. Generated only on the shared networks (BROADCAST/NON-BROADCAST network types) to minimize the amount of topological information generated. Imagine that you have 10 routers on a shared Ethernet segment. Normally, to fully describe the topology, every router would need to generate an LSA describing its connection to all other 9 routers. This would result in 90 LSAs. Using LSA type-2 and the Designated Router concept, every router needs to declare a connection to the DR, and the DR will generate a Type 2 LSA describing all routers on the segment (the bunch). In our example, this will result in 11 LSAs total. This LSA does not carry any real network reachability information with the exception of the netmask and the list of routers on the segment. It is used along with information from type 1 LSAs to describe the shared network. I like to think of it as a glue LSA. The flooding domain is one area as flooding stops at ABRs. LSA type 3. Now this type is a bit tricky and brings in a lot of confusion. It is generated by an ABR to tell the routers in one area about the network in another area. Essentially, the router pretends like all the foreign networks are attached to it. From a topological perspective, this is true, because areas never know anything about another areas topology this information is lost when crossing the area boundaries. How are Type 3 LSAs generated? First of all, keep in mind that OSPF generates those by walking the main routing table, not the LSDB. This is per RFC 2328 clause 12.4.3 and in full accordance with distance-vector protocol behavior. Every route in the table has additional OSPF information associated with it, such as area number, route-type (intra-area, inter-area, external) next hop, and so on. 1) The ABR goes over the network reachability information in the RIB associated with intra-are routes for the particular area X and summarizes them honoring the area X range command settings. This results in Type-3 LSAs being generated and advertised into all other areas. Pay attention to the following important things:

1.1) Only intra-area routes are summarized. You cannot summarize inter-ara routes installed by processing type-3 LSAs learned from Area 0. Those will generate new type-3 LSAs in the ABR and will propagated them into non-backbone areas unmodified. 1.2) The intra-area routes are summarized PRIOR to applying the distribute-list filter and blocking the routes from entering the RIB. This is needed to allow for generation of a summary route, even if you dont want the specific prefixes in the local RIB and calculate the correct metric if needed. Thus, even though OSPF walks over the RIB to gather the intra-area prefixes for summarization, it does so BEFORE applying the filter. The ultimate goal is making summarization the highest priority task, in order to increase network stability. 1.3) The OSPF metric for the summarized route is taken as the minimal among all intra-area routes. To ensure better routing stability, it is usually recommended setting the metric manually, to prevent LSA re-flooding in case some component route flaps and affects the summary metric. 2) Now, for dealing with the inter-area routes learned by the ARB, first of all, keep in mind that an ABR ONLY accepts and processes type-3 LSAs received from the backbone area. This is the well-know loop prevention mechanism built into OSPF, since OSPF behaves as a distance-vector protocol when dealing with inter-area routing information. This is a short description of how an ABR processes type-3 LSAs: 2.1) Ignore the type-3 LSA if it is NOT from the backbone area (prevents routing loops). 2.2) Walk over the inter-area routes learned via Area 0 in the RIB and generate respective type-3 LSAs which are flooded into the attached non-backbone areas. Thus, LSAs are effectively being re-generated based on the RIB contents. Next, consider an important aspect of this process. The re-generated summary LSAs are generated AFTER applying the OSPF filter associated with the routing-process via thedistribute-list in command. Thus, if you filter some of the inter-area routes from entering the RIB, the respective new summary LSAs will NOT get generated. This will stop routing information propagation into the attached non-backbone areas. This quickly summarizes the type-3 LSA generation process. Notice that filtering the routing information is not based on some LSA filtering procedure, but rather on the routes contained in the RIB. At this moment, some people may recall the command area X filter-list prefix {in|out}. Good news here this command applies after all summarization has been done and filters the routing information from being used for type-3 LSA generation. It applies to all three type of prefixes: intra-area routes, inter-area routes, and summaries generated as a result of the area X range command. All information is being learned from the routers RIB. Oh, almost forgot LSA type-3 flooding scope is one area, it never crosses ABR boundaries it just gets regenerated when needed! Now, here is a summary of inter-area router filtering commands (applicable only at an ABR): Method 1: Filter the inter-area routes generated at ABR router ospf 1 area 10 filter-list prefix in NAME Method 2: Filter out intra-area routes router ospf 1 area 10 range 1.1.1.0 255.255.255.0 no-advertise Method 3: Filter inter-area routes learned by ABR from Area 0 router ospf 1 distribute-list 1 in

LSA type 4 This type has always been confusing to many people. This LSA describes the metric that the ABR uses to reach the respective ASBR. This LSA contains the router-ID of the ASBR and the metric to reach it. ABRs generate type-4 LSAs based on the special router routing table which is visible when you issue the command show ip ospf border-routers. This command is the essense of the distance-vector OSPF behavior. During the inter-area path calculations, the ABR populates this table with host routing entries for every ABR and ASBR detected with the respective metrics. This table is never transferred to the main router routing table, but rather used for inter-area path computations and type-4 LSA generation. Effectively, the metrics in this table are used as metric offsets for the paths learned from ABRs and ASBRs. The ABR generates type-4 summary LSAs into every normal attached area, to make sure the routers in there can reach the prefixes from the ASBR. You cannot really filter the contents of this LSA, as they are taken from the router routing table. The information from this LSA is used to populate the non-ABR routers special router routing table. The flooding domain is one area as it stops at the ABR. LSA type 5 This LSA is originated by an ASBR (router redistributing external routes) and flooded through the whole OSPF autonomous system. You cannot limit the way this LSA is generated except to controlling the routes redistributed into OSPF. When a type-5 LSA is being generated, it uses the RIB contents and honors the summary-address commands in the ABR. You may filter the redistributed routes by using the command distribute-list out configured under the protocol, which is the source of redistribution or simply applying filtering with your redistribution. Method 1: router ospf 1 distribute-list 10 out rip ! access-list 1 deny 1.1.1.0 access-list 1 permit any Method 2: router ospf redistribute rip route-map RIP_TO_OSPF ! route-map RIP_TO_OSPF match ip address 1 Method 3: router ospf summary-address 10.0.0.0 255.255.25.0 no advertise There is yet one more way to filter the routing information found in type-5 LSAs. If the LSA contains non-zero FA (forwarding address) field, OSPF process will check for this address to be accessible via RIB (RFC specifies that only OSPF routes should be considered, but it seems IOS satisfies with any route) before installing the actual prefix into the RIB. If the FA is not accessible, the corresponding external prefix is not installed into the global routing table. We will discuss this type of filtering a bit later, when well be looking into type-7 LSAs. However, keep in mind that FA is non mandatory for type-5 LSA and is only assigned to a type-5 LSA under special conditions, outlined in the following document Common Routing Problem with OSPF Forwarding Address. Here is the list of the conditions:

OSPF is enabled on the ASBRs next hop interface AND ASBRs next hop interface is non-passive under OSPF AND ASBRs next hop interface is not point-to-point AND ASBRs next hop interface is not point-to-multipoint AND ASBRs next hop interface address falls under the network range specified in the router ospf command. Please refer to the URL provided for more epxplanations. There is only one more type of OSPF LSAs to discuss. Type 7 LSA These only exist at NSSA areas and have the flooding scope of a single area, as opposed to the whole domain for type-5 LSAs. The type-7 LSAs reaching ABRs are used to populate the local routing table and re-generate the new type-5 LSAs, originated now by the ABR. This is important since the ABR becomes an ASBR and re-originates the routes, you may use the commandsummary-address ADDR MASK no-advertise to block the type-5 LSA generation. There is another, less obvious way to do things: When an ABR generates type-5 LSAs, it adds the forwarding-address (FA) based on the information learned in the type-7 LSA. This information is originally inserted by the ASBR to help in optimal exit point selection. The use of forwarding-address with the type-7 LSAs is mandatory per the RFC, since there is just one translator, and it may lie on the sub-optimal path to the ASBR. Thus all routers in the OSPF autonomous system are supposed to rely on the FA for optimal routing to the translated prefixes. And here is the trick: if you filter the forward-address IP from the routing table in the ABR, using the command distribute-list in the type-5 LSA will not be generated!. Look at the following output, where R2 is an ABR for NSSA area 27: Rack1R2#show ip ospf database nssa-external OSPF Router with ID (150.1.2.2) (Process ID 1) Type-7 AS External Link States (Area 27) Routing Bit Set on this LSA LS age: 11 Options: (No TOS-capability, Type 7/5 translation, DC) LS Type: AS External Link Link State ID: 162.1.7.0 (External Network Number ) Advertising Router: 162.1.7.7 LS Seq Number: 80000001 Checksum: 0xDEB5 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 150.1.7.7 External Route Tag: 0 Routing Bit Set on this LSA LS age: 11 Options: (No TOS-capability, Type 7/5 translation, DC) LS Type: AS External Link Link State ID: 162.1.10.0 (External Network Number ) Advertising Router: 162.1.7.7

LS Seq Number: 80000001 Checksum: 0xBDD3 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 150.1.7.7 External Route Tag: 0 Rack1R2#show ip ospf database external OSPF Router with ID (150.1.2.2) (Process ID 1) Type-5 AS External Link States ... LS age: 26 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 162.1.7.0 (External Network Number ) Advertising Router: 150.1.2.2 LS Seq Number: 80000001 Checksum: 0x2193 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 150.1.7.7 External Route Tag: 0 LS age: 26 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 162.1.10.0 (External Network Number ) Advertising Router: 150.1.2.2 LS Seq Number: 80000001 Checksum: 0xFFB1 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 150.1.7.7 External Route Tag: 0 As you can see, R2 generates type-5 LSA with the same forwarding address found in type-7 LSA 150.1.7.7. Now we filter this IP address from entering R2s routing table: R2: access-list 1 deny 150.1.7.7 access-list 1 permit any ! router ospf 1 distribute-list 1 in And apply our verification once again:

Rack1R2#show ip ospf database nssa-external OSPF Router with ID (150.1.2.2) (Process ID 1) Type-7 AS External Link States (Area 27) LS age: 222 Options: (No TOS-capability, Type 7/5 translation, DC) LS Type: AS External Link Link State ID: 162.1.7.0 (External Network Number ) Advertising Router: 162.1.7.7 LS Seq Number: 80000001 Checksum: 0xDEB5 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 150.1.7.7 External Route Tag: 0 LS age: 222 Options: (No TOS-capability, Type 7/5 translation, DC) LS Type: AS External Link Link State ID: 162.1.10.0 (External Network Number ) Advertising Router: 162.1.7.7 LS Seq Number: 80000001 Checksum: 0xBDD3 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 150.1.7.7 External Route Tag: 0 Rack1R2#show ip ospf database external OSPF Router with ID (150.1.2.2) (Process ID 1) Type-5 AS External Link States And we can see that Type-7 to Type-5 translation is not working anymore, as the forwarding address is no longer reachable in the RIB. Notice that forwarding address should be accessible via the main RIB, not the routers routing table of OSPF. This special behavior is unique to the routes learned by processing the type-7 LSAs. Now what if you have to following topology:

And R3 is filtering the forwarding address for the type-5 LSAs originated at R4 using say area X range noadvertise or area X filer-list prefix {in|out} commands, so that R1 has no FA IP in its RIB. In this situation, R3 will have the route to the redistributed prefixes installed (it sees the FA!), but all other routers in the domain with the exception of the NSSA area internal routers will not. Even though they will receive the type-5 LSA, they will not be able to process them and use the information for routing the forwarding address will be unreachable. One way to overcome this issue is by using the command area X nssa suppress-fa to instruct R3 on setting the FA to itself.

Summary of the postWe went over almost all of the important route-filtering scenarios for OSPF. The key thing you should remember is that non-local route filtering for OSPF is only available at ABRs and ASBRs, the points where OSPF behaves as a distance-vector protocol with respect to inter-area routing information. Here is the list of points you need to remember: 1) You cannot filter LSAs directly, you can only manipulate the routing information used to generate LSAs. 2) The above routing information is taken from local routers RIB directly. 2.1) In the case of intra-area routes, RIB filters are applied after the type-3 LSAs are generated (intra-area routes are summarizable). 2.2) In the case of inter-area routes, RIB filters are applied prior to type-3 LSA generation (inter-area routes are not summarizable). 3) External AS routes can only be filtered at the ASBR. 4) NSSA routes can be filtered at an ASBR and the ABR performing the translation. 5) If the FA for an external prefix is NOT reachable, the router will NOT install it into the route table nor will it translate type-7 LSAs to type-5.

Futher Reading1) RFC 2328. Dont skip this if you are serious about understanding OSPF 2) OSPF Design Guide by Sam Halabi. Excellent introductory reading on OSPF.

3) Cisco IP Routing by Alex Zinin. A must read to anyone who wants in-depth understanding of IP Routing internals.

OSPF Areas, Part 1, The Backbone Area, Posted in OSPF , Tutorials , 0 Comments

Thanks to one of our brilliant CCIE R/S Written students, Nish, for his request of this series of INE blog posts. Nish is still struggling a bit with the different OSPF area types and how exactly they impact Link State Advertisements (LSAs). In this series, we will tackle each of the different OSPF areas in great detail, confirming our Level 1 knowledge at the command line as we progress. Here is the network we will use in this first post. Notice this simple network can be constructed easily in Dynamips, or with three pretty basic Cisco routers capable of OSPF version 2.

To prepare for this blog post, we have configured all of the underlying layer 2 and 3 connectivity. We have also configured OSPF per the diagram. Note the OSPF router IDs were set using the OSPF routermode router-id command. These addresses do not exist on the devices, and therefore they are not advertised in the protocol, and obviously, they are not reachable. So let us examine the first device, R1. This is an internal, backbone router. What do we expect to see in the OSPF database? Well, since there is broadcast media at work in that area, I expect to see an LSA Type 2, and we have another area, Area 11, so we should also see an LSA Type 3. Here is the actual OSPF database on the device: R1#show ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) Link ID count 1.1.1.1 2.2.2.2 ADV Router 1.1.1.1 2.2.2.2 Age 99 95 Seq# Checksum Link

0x80000002 0x001FEB 2 0x80000002 0x007761 1

Net Link States (Area 0)

Link ID 10.10.10.1

ADV Router 1.1.1.1

Age 99

Seq# Checksum 0x80000001 0x009476

Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 192.168.1.0 2.2.2.2 98 0x80000001 0x00F4CB R1# Interesting, OK, as an internal, backbone router, the first thing I notice is the fact that we only have one link state database here it is for Area 0 of course. OK, very interesting, we have LSA 1 types (Router Link States) for the Router IDs of R1 and R2 in that area. Wow, these are not even valid (reachable) IP addresses in the scenario. I guess this is how we can use these Router IDs when we create a virtual link. These Router IDs are tracked and shared by the OSPF speakers. The next entry is the LSA Type 2 (Net Link State) we expected. The advertising router is the local router (R1, RID: 1.1.1.1). We must be the Designated Router (DR), and that is indeed true. Finally, we have our LSA Type 3 (Summary Net Link State) that we expected from Area 11. Awesome. This is a fun and rewarding exercise. Predicting show command output based on our Core Knowledge (Level 1). Now, close your eyes and think about the show command output for the OSPF database we will see in R2. This is an Area Border Router (ABR), and also a backbone router. We immediately realize we should see LSA entries for Area 0 and Area 11. This poor router has to maintain two databases: R2#show ip ospf database OSPF Router with ID (2.2.2.2) (Process ID 1) Router Link States (Area 0) Link ID count 1.1.1.1 2.2.2.2 ADV Router 1.1.1.1 2.2.2.2 Age 905 899 Seq# Checksum Link

0x80000002 0x001FEB 2 0x80000002 0x007761 1

Net Link States (Area 0) Link ID 10.10.10.1 ADV Router 1.1.1.1 Age 905 Seq# Checksum 0x80000001 0x009476

Summary Net Link States (Area 0) Link ID 192.168.1.0 ADV Router 2.2.2.2 Age 902 Seq# Checksum 0x80000001 0x00F4CB

Router Link States (Area 11) Link ID count 2.2.2.2 3.3.3.3 ADV Router 2.2.2.2 3.3.3.3 Age 856 858 Seq# Checksum Link

0x80000002 0x00F747 1 0x80000002 0x00B680 1

Net Link States (Area 11) Link ID 192.168.1.2 ADV Router 2.2.2.2 Age 859 Seq# Checksum 0x80000001 0x006D44

Summary Net Link States (Area 11) Link ID ADV Router Age Seq# Checksum 10.10.10.0 2.2.2.2 904 0x80000001 0x0048C4 172.16.10.0 2.2.2.2 894 0x80000001 0x00C79B R2# Examine the above output line for line. There should be no surprises, and it should all fall right into place from your Core Knowledge about OSPF LSA Types now. Here is a look at the IP Routing table on this device, R2. Correlate the entries to those you see in the OSPF Database: R2#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set O C C R2# 172.16.0.0/24 is subnetted, 1 subnets 172.16.10.0 [110/11] via 10.10.10.1, 00:17:59, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets 10.10.10.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is directly connected, FastEthernet0/1

OSPF Areas, Part 2, Normal and Stub Areas, Posted in OSPF , Tutorials , 0 Comments

Welcome back to our series on OSPF areas. Click here for Part 1 of the series. It is time to focus on normal areas and stub areas in this post. Recall our topology:

We have gone to R1 and created a prefix (11.11.11.0/24) using a loopback interface. We run RIP version 2 on

this interface and redistribute this into OSPF Area 0. What should this create on R3 in Area 11 (a normal OSPF area)? Thats right a Type 5 LSA for an External prefix. Let us examine the OSPF database on R3 now and the accompanying IP routing table: R3#show ip ospf database OSPF Router with ID (3.3.3.3) (Process ID 1) Router Link States (Area 11) Link ID count 2.2.2.2 3.3.3.3 ADV Router 2.2.2.2 3.3.3.3 Age 1216 1215 Seq# Checksum Link

0x80000002 0x00023C 1 0x80000002 0x00C075 1

Net Link States (Area 11) Link ID 192.168.1.3 ADV Router 3.3.3.3 Age 1215 Seq# Checksum 0x80000001 0x003577

Summary Net Link States (Area 11) Link ID 10.10.10.0 172.16.10.0 ADV Router 2.2.2.2 2.2.2.2 Age 1281 1241 Seq# Checksum 0x80000001 0x0048C4 0x80000001 0x00C79B

Summary ASB Link States (Area 11) Link ID 1.1.1.1 ADV Router 2.2.2.2 Age 449 Seq# Checksum 0x80000001 0x0075B0

Type-5 AS External Link States Link ID 11.11.11.0 R3# ADV Router 1.1.1.1 Age 456 Seq# Checksum Tag 0x80000001 0x0075AB 0

R3#show ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets 172.16.10.0 [110/21] via 192.168.1.2, 00:24:41, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.10.10.0 [110/20] via 192.168.1.2, 00:24:41, FastEthernet0/0 11.0.0.0/24 is subnetted, 1 subnets O E2 11.11.11.0 [110/20000] via 192.168.1.2, 00:11:53, FastEthernet0/0 C 192.168.1.0/24 is directly connected, FastEthernet0/0 R3# Sure enough, there is the Type 5 prefix in the normal area. And we cannot forget about the LSA Type 4 (Summary ASB Link State). This informs the OSPF domain of the location of the Autonomous System Boundary Router (ASBR). I am sure you have been noticing how some of the LSAs in the database do not translate directly into routing table entries. For example, the LSA Type 4. This is reminiscent of the EIGRP topology table. That protocol sure tries to act link state as well! OK, well let us see what happens when we convert Area 11 into a STUB AREA. Remember, this is a simple configuration. All we need to do is go to ALL of the routers in the stub area (there can be many), and issue the O IA

router configuration command area 11 stub. Now that we have done that, let us examine the databases on R3. R3#show ip ospf database OSPF Router with ID (3.3.3.3) (Process ID 1) Router Link States (Area 11) Link ID count 2.2.2.2 3.3.3.3 ADV Router 2.2.2.2 3.3.3.3 Age 7 6 Seq# Checksum Link

0x80000005 0x001A23 1 0x80000005 0x00D85C 1

Net Link States (Area 11) Link ID 192.168.1.3 ADV Router 3.3.3.3 Age 6 Seq# Checksum 0x80000004 0x004D5E

Summary Net Link States (Area 11) Link ID 0.0.0.0 10.10.10.0 172.16.10.0 R3# ADV Router 2.2.2.2 2.2.2.2 2.2.2.2 Age 33 33 33 Seq# 0x80000001 0x80000003 0x80000003 Checksum 0x0075C0 0x0062AA 0x00E181

R3#show ip route Gateway of last resort is 192.168.1.2 to network 0.0.0.0 172.16.0.0/24 is subnetted, 1 subnets 172.16.10.0 [110/21] via 192.168.1.2, 00:01:23, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets O IA 10.10.10.0 [110/20] via 192.168.1.2, 00:01:23, FastEthernet0/0 C 192.168.1.0/24 is directly connected, FastEthernet0/0 O*IA 0.0.0.0/0 [110/11] via 192.168.1.2, 00:01:23, FastEthernet0/0 R3# Wow, things really changed here. Notice the Stub Area effect worked just as advertised in our Core Knowledge studies. The Type 4 and 5 LSAs were removed from the OSPF database! They were replaced with a special LSA Type 3. It is special because it is an automatically generated default route by the Area Border Router (ABR). Join us in the next part of this blog series where we examine the next OSPF area type, the Totally Stu