These are records that I could listen to over and over again, and sometimes I even just let them loop.
In no order:
Interface delays are used in metric calculation on EIGRP. Knowing what they are upfront can help a bit when you are planning out what your metrics are going to be in your fancy EIGRP design. Here are the ones that I have; this list will be updated as I find more.
Serial: 2000
Ethernet: 1000
FastEthernet: 100
As interesting as it may be, the details of OSPF can be a bit daunting. A big part of that is that there are types of this and types of that all over the place. Two important types that you’ll use a lot and should know pretty well are area types and LSA types. I’ve come up with a pretty good way to learn both and to correctly associate the two.
To save you some time if you are already familiar with OSPF and just want to get the skinny, here it is (we’ll recap at the end too):
OSPF Special Area Types
OSPF has a few extra types of areas aside from your standard, run-of-the-mill area. All of the special area types revolve around the term “stub”. A stub area is an area that only has 1 way in and out (as far as the OSPF process is concerned). Their purpose typically has to do with minimizing the utilization of memory, CPU, and bandwidth by limiting/filtering certain types of link-state announcements the areas send and receive. The flexibility required to make this possible is actually where the link-state announcement (LSA) types come into play.
Aside from a regular OSPF area, Cisco routers support the following area types:
OSPF LSA Types
I’ll keep this part as short as possible, but keep in mind that one could go on for pages discussing LSA type specifics. There are 11 types of LSAs in OSPFv2. For our discussion, I’m going to just tell you what a hand full (plus 1) of the LSA types are and what they are for, then we’ll get down to associating them to the various area types.
Type 1 LSAs are your standard intra-area link-state announcement. There is nothing special about them, they just do their job, punch the clock, and head home. These are the bread and butter of intra-area routing.
Type 2 LSAs only, only, only come from a DR (designated router). Remember those? They are the elected (by priority or by router-id) official of the broadcast network. Type 2 LSAs come from the DR to tell the rest of the world who is attached to the broadcast link.
Type 1 and 2 never cross area borders, and by virtue that the protocol is link-state, you can’t keep them from moving about the area.
Type 3 LSAs are summaries of routes that are sent inter-area.
Type 4 LSAs are also summary routes, but they specifically deal with ASBR (autonmous system boundry routers). In fact, the only thing that they do is provide information about the ASBR.
Type 5 LSAs are used to deliver external information. This is the information that is learned from outside of OSPF and was introduced by redistribution at some point.
Type 7 LSAs are the same as type 5 LSAs. Redundant? Kinda, but hang in there, there is a reason for it. As stated above:
Now that you know what the LSAs are, what the area types are, and these rules, let’s try to figure out what kind of LSAs are allowed to cross the ABR for the following special area types:
All of these are valid area types on Cisco routers.
So with the 4 rules in mind, starting with example #1. We won’t have type 1 or 2 for sure - they never cross an ABR anyway. “stub” means that we won’t have type 5. As it looks, we’ll be permitting type 3 and 4 (summaries), blocking 5 (info from outside of OSPF), and letting everything else through.
Example 2 is the same as above, only it has our key words of “not-so”. That means that even though we’re not letting type 5 through, we’re allowing type 7. When the type 7 hit the ABR, they get translated into type 5 to go out to the rest of the network. This may seem stupid on the surface, but digging deeper reveals the point. The key is that we’re saving our area from processing all of the type 5 LSAs from all of the other areas. Let’s say we have enough power (processor/memory, etc) to process our own area’s information, but we’re not able to handle dealing with everyone else’s.
Example #3 is the most efficient of any of these. Looking at the rules we see that stub filters type 5, and “totally” filters 3 and 4. Since we know that ABRs don’t transit type 1 and 2, we’re pretty much done. So how does it work? Well, the point of a stub, if you recall, is that there is only 1 exit point for the network. So…. OSPF just sends a default route and that is it. Intra-area routes within the stub area are still going to make their way into the LSDB and the routing table, but the only way out to the rest of the world is via the default route.
Example #4 is like #3, but type 7 LSAs get through for the same reason as example #2. Did you get all that? =) We filter everything, but we have an ASBR somewhere within our totally stubby area. As such, we need routes that are being introduced to us from that avenue to be sent out to the rest of the network. We send type 7 LSAs to the ABR, it changes them to type 5 on the way out, and everyone is happy.
I have a pet peeve about the way the word propagate is used to describe the exchange of DNS records. I think that this stems from spending years performing DNS admin duties at various ISPs. You have no idea how many times I’ve heard people inaccurately state that “updated DNS records will be available as soon as the information propagates to the Internet, which usually takes about 24 hours because DNS is slow.” Call me pedantic, but this kills me.
While it is not denotatively incorrect to use propagate when referring to DNS information exchanges, it is by far a contextual stretch within the realm of connotative interpretation. The definition of propagation does not specifically state that information (in this case) is being disseminated by a proactive, complete, and automatic outbound process. Thereby it qualifies as an accurate term for DNS information exchange. However, the typical connotation implied when people use the word propagate in relation to DNS records is that the aforementioned process takes place, and *that* is what is inaccurate.
DNS information is organized in a tree form so that you can go to the the bottom of the tree and find what you are looking for from there. Your DNS servers are configured to, either themselves or through other servers, eventually reach the root (.). From there they can get can ask about “com”. They then query servers that know about “com” and ask who is responsible for information about “example”. They get NS records back and then query the servers responsible for “example.com”. The very second that the NS for example.com is up (and properly configured), and the root servers are configured with an NS entry pointing to that server regarding records for example.com, that domain is available. THAT VERY SECOND. At no point in this process was information propagated throughout the Internet.
The area that understandably trips people up is the concept of cacheing of DNS information. People often say “updated DNS records will be available as soon as the information propagates to the Internet, which usually takes about 24 hours because DNS is slow” but what they mean is “It may take up to 24 hours for some servers to expire their cache and then, if asked, will query for the the updated information.” Those two things are exactly opposite. One involves information dissemination, while the other involves information elimination.
The misconception that I wish to squash can be wrapped up in one statement: DNS information doesn’t propagate as routing information does. A DNS server in no way discovers other DNS servers to proactively share the information that it has. The only two ways DNS servers give out information is if they are reacting to a query, or they are notifying other servers that they were specifically configured to notify (like their secondaries). They in no way propagate information throughout the Internet. If you’re records are not visible now when you directly query the server (try the dig command line tool on a unix-like box near you), then you have a configuration problem, not a propagation problem.
Thanks for listening, I had to get that off my chest.
HSRP can be handy when you have redundant routers on your network as it allows you to configure multiple routers with a single virtual IP. One router takes the primary role, the others are a backup just in case something happens. The cool thing is that hosts that have their gateway configured to be the virtual IP never notice anything has changed.
We’ll assume a few things:
Configuration:
Router 1:
router1#conf t Enter configuration commands, one per line. End with CNTL/Z. router1(config)#int fa0/1 router1(config-if)#ip address 10.10.10.2 255.255.255.0 router1(config-if)#no ip redirects router1(config-if)#standby 1 ip 10.10.10.1 router1(config-if)#standby 1 priority 110 router1(config-if)#standby 1 preempt
Router 2:
router2#conf t Enter configuration commands, one per line. End with CNTL/Z. router2(config)#int fa0/1 router2(config-if)#ip address 10.10.10.3 255.255.255.0 router2(config-if)#no ip redirects router2(config-if)#standby 1 ip 10.10.10.1 router2(config-if)#standby 1 priority 105 router1(config-if)#standby 1 preempt
Done. Now, for a little explaination. The “1″ after the standby is a group. For now suffice to say that while you don’t have to use them, it is potentially a better idea than not. The priority here is a “highest priority wins” situation. The default is 100. In this configuration we have set router 1 to be the primary, and router 2 to be secondary. We give them the preempt option to make sure that the router with the highest priority takes over whenever it is available.
There are a lot of other options for HSRP, but this should get you up and go and let you worry about details later. Here for you again are both configs that you can throw into notepad, edit, and then paste into your device.
Router 1:
interface FastEthernet0/1 ip address 10.10.10.2 255.255.255.0 no ip redirects standby 1 ip 10.10.10.1 standby 1 priority 110 standby 1 preempt
Router 2:
interface FastEthernet0/1 ip address 10.10.10.3 255.255.255.0 no ip redirects standby 1 ip 10.10.10.1 standby 1 priority 105 standby 1 preempt
Good luck.
The fastest way to get OSPF working is to put this on every router:
P1R1#conf t Enter configuration commands, one per line. End with CNTL/Z. P1R1(config)#router ospf 1 P1R1(config-router)#network 0.0.0.0 255.255.255.255 area 0 P1R1(config-router)#
This is not a great idea or at all an optimal configuration, but it will get OSPF talking and will include all interfaces in the routing process.
You can make sure to include all static routes by adding the following:
P1R1(config-router)#redistribute static subnets
To follow up with an option that will let you specify interfaces more specifically while still getting all of your connected interfaces:
P1R1(config-router)#redistribute connected subnets
Well, there you are. Not a great idea, but this is a super-quick way to enable OSPF on your network. The configuration is generic enough to go on (almost?) any Cisco router or layer 3 switch that is OSPF capable. Here it is again without the prompts for your cut-and-paste pleasure:
router ospf 1 redistribute connected subnets redistribute static subnets network 0.0.0.0 255.255.255.255 area 0
Good luck!
For a variety of reasons you may want to keep routes that have been learned by a routing protocol from reaching the forwarding table or for a less “believable” protocol to take precedence over a more “believable” protocol. In this post we’ll explore some of those options. We do this to the end that knowing about these options gives you the flexibility to use them, in addition to being aware that someone else may have used them and that is why routes that you are expecting to see in the routing table are not there.
While you may know that administrative distance is there and know what it is for, you should also be aware that it is very configurable. You may not have known, but…
Pretty neat, huh?
To change the AD for an entire routing protocol, the method depends on the protocol, but they are all really similar. No matter which routing protocol you’re using, the AD always gets changed under the routing process. In this example we’ll use OSPF.
First lets check out what OSPF’s contribution to the routing table looks like before we start noodling.
P1R1#sh ip route ospf
10.0.0.0/24 is subnetted, 4 subnets
O IA 10.1.2.0 [110/65] via 10.1.0.2, 00:01:39, Serial1/1
O 10.1.4.0 [110/2] via 10.1.1.3, 00:01:39, FastEthernet0/0
P1R1#
There we are, good old standard OSPF all around. We have an inter-area route and an intra-area route. Let’s make some adjustments.
P1R1#conf t Enter configuration commands, one per line. End with CNTL/Z. P1R1(config)#router ospf 1 P1R1(config-router)#distance ? <1-255> Administrative distance ospf OSPF distance P1R1(config-router)#distance 120 P1R1(config-router)#
That’s it. Now when we back out of the routing process and go to an exec prompt, we can see the fruits of our labor:
P1R1#sh ip route ospf
10.0.0.0/24 is subnetted, 4 subnets
O IA 10.1.2.0 [120/65] via 10.1.0.2, 00:00:01, Serial1/1
O 10.1.4.0 [120/2] via 10.1.1.3, 00:00:01, FastEthernet0/0
P1R1#
Notice that the OSPF routes have an administrative distance of 120; mission accomplished. Next let’s talk about just altering the administrative distance for just one route type.
P1R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
P1R1(config)#router ospf 1
P1R1(config-router)#distance ospf ?
external External type 5 and type 7 routes
inter-area Inter-area routes
intra-area Intra-area routes
P1R1(config-router)#distance ospf intra-area 130
P1R1(config-router)#end
P1R1#sh ip route ospf
10.0.0.0/24 is subnetted, 4 subnets
O IA 10.1.2.0 [120/65] via 10.1.0.2, 00:00:05, Serial1/1
O 10.1.4.0 [130/2] via 10.1.1.3, 00:00:05, FastEthernet0/0
Now, for routes that are intra-area, that is, routes within our current area of area 1, we have an AD of 130 while every other route learned via OSPF should be still at 120 (from before).
We can remove the statements, and we’re back to scratch.
P1R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
P1R1(config)#router ospf 1
P1R1(config-router)#no distance 120
P1R1(config-router)#no distance ospf intra-area 130
P1R1(config-router)#end
P1R1#sh ip
*Feb 4 19:13:56.863: %SYS-5-CONFIG_I: Configured from console by console
P1R1#sh ip route ospf
10.0.0.0/24 is subnetted, 4 subnets
O IA 10.1.2.0 [110/65] via 10.1.0.2, 00:01:39, Serial1/1
O 10.1.4.0 [110/2] via 10.1.1.3, 00:01:39, FastEthernet0/0
From here, let’s look at changing the AD for just a specific route. Maybe we want to leave everything intact with an AD of 110, but for a single subnet. In this example we’ll change 10.1.4.0 to an AD of 155. This is a bit more complicated than the other options because we are adding the extra step of creating an access-list to match our networks. Next, the syntax is a bit different than what we have been working with so far. We start off with “distance 155″ much like the first part of this exercise, but then we quantify the routing source before we reference our access list. This allows us the opportunity to be even more granular with our matching. While I won’t go too much further into this here, let’s just say that you could keep your normal AD set except for when you get the route from a certain router. Here I am going to say that 0.0.0.0 (any IP) and wildcard mask 255.255.255.255 (all “I don’t care” bits) so that any route source (any router) that sends us routes matching access-list 10 (10.1.4.0/24) matches and will set the AD to 155.
P1R1(config)#access-list 10 permit 10.1.4.0 0.0.0.255 P1R1(config)#router ospf 1 P1R1(config-router)#distance 155 0.0.0.0 255.255.255.255 10 P1R1(config-router)#end P1R1# *Feb 5 00:09:25.134: %SYS-5-CONFIG_I: Configured from console by console
With the configuration complete, we’re ready to check out how we did. Fingers crossed…
P1R1#sh ip route ospf
10.0.0.0/24 is subnetted, 4 subnets
O IA 10.1.2.0 [110/65] via 10.1.0.2, 00:02:30, Serial1/1
O 10.1.4.0 [155/2] via 10.1.1.3, 00:02:30, FastEthernet0/0
P1R1#
There you go!
For a final note on our Administrative distance portion I want to remind you that the higher the value of the administrative distance, the less believable it is considered by the router. Also, be aware that if you set an AD to 255, it will NEVER get into the routing table. Take a look…
P1R1(config)#router ospf 1
P1R1(config-router)#distance 255 0.0.0.0 255.255.255.255 10
P1R1(config-router)#end
*Feb 5 00:51:55.398: %SYS-5-CONFIG_I: Configured from console by console
P1R1#sh ip route ospf
10.0.0.0/24 is subnetted, 3 subnets
O IA 10.1.2.0 [110/65] via 10.1.0.2, 00:00:05, Serial1/1
P1R1#
Not there. But what’s this? It *IS* in the link-state database! Check it…
P1R1#sh ip ospf database
OSPF Router with ID (10.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.1.1.1 10.1.1.1 1110 0x8000000D 0x00ED69 2
10.1.2.2 10.1.2.2 1018 0x8000000B 0x00CA8B 2
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.1.0 10.1.1.1 1110 0x8000000B 0x0076A2
10.1.2.0 10.1.2.2 1018 0x8000000B 0x005EB7
10.1.4.0 10.1.1.1 847 0x8000000B 0x005FB5
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
10.1.1.1 10.1.1.1 1110 0x8000000C 0x00BC36 1
10.200.200.13 10.200.200.13 863 0x8000000C 0x00B2E7 2
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.1.1 10.1.1.1 1110 0x8000000B 0x009AC5
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.0.0 10.1.1.1 1129 0x8000000B 0x00F9E0
10.1.2.0 10.1.1.1 1129 0x8000000B 0x00EDE9
P1R1#
There you have it. The AD of 255 killed the 10.1.4.0/24 route.
That pretty much wraps up this post. I hope you enjoyed our little adventure in manipulating administrative distances - I know that I’ll have a hard time sleeping tonight =). Please email if you have any questions or comments, or if you feel that something was not clearly explained or if you feel that something is in error.
For quite a long time my girlfriend has been trying to talk me into moving into a new apartment. I’ve been all for it, but there have been times that the right places aren’t available, we don’t have the money, or it is too cold to think of moving. Coming up to spring, I’ve run head-first into another frenzy of non-stop requests to move. Eager to get passed being nagged about this apartment thing so that I can move on to being nagged about getting married, having kids, buying a house, getting new cars, getting new furniture, getting new curtains, getting a country club membership, sending the kids to a private school, karate lessons, music lessons, soccer, football, baseball, basketball, and finding a good college for them, I decided to concede and move.
Fortunately, in spite of all of the stress that moving causes there has been one benefit overall. We now have a hard copy of most of the Internet as she has printed it out as she has gone along her apartment search. If you are missing any part of the internet or a server has become unreachable, please contact me and I’ll mail you the sections you need.