Just another Cisco blog
Quick BGP Challenge #1
This is the first little challenge I’m posting on here. If you frequent the forums, you likely saw the one I had for OSPF. I thought of another challenge while talking to a buddy. Here’s the topology:
Make R1 prefer the path through R3 for the 192.168.1.0/24 network. The configuration must be on R1. Do not use Weight or Local Preference to accomplish this. Assume that all previous configuration is correct.
This one is a little different than the OSPF challenge in that there are many ways to accomplish it. I’ve thought of a few, I want to see what everyone else comes up with.
Go!
Related Posts:
| Print article | This entry was posted by Colby on May 12, 2010 at 8:34 pm, and is filed under Quick Challenge. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
No trackbacks yet.
%C4K_EBM-4-HOSTFLAPPING
about 1 week ago - 9 comments
This means loop!
A coworker came to me with an issue today. He asked if I’d ever seen this before and showed me:
.Aug 25 22:44:29 UTC: %C4K_EBM-4-HOSTFLAPPING: Host 00:00:85:DE:15:61 in vlan 54 is flapping between port Gi2/4 and port Gi2/2 .Aug 25 22:44:59 UTC: %C4K_EBM-4-HOSTFLAPPING: Host 00:00:85:DE:15:61 in vlan 54 is flapping between port Gi2/4 and port Gi2/2 .Aug 25 22:47:42 UTC: %C4K_EBM-4-HOSTFLAPPING: Host 00:00:85:DE:15:61 in vlan 54 is flapping between port Gi2/4 and port Gi2/2 |
I said “it means there’s a loop, give me the switch IP”. Then I began the mission of tracking down the loop. This was a pretty large site, but luckily I only had to go through a couple switches. Unfortunately this happened a couple hours ago and I didn’t save my work so we won’t be able to go through the real steps.
To track down a loop, you start with the “show mac-address-table address [flapping mac]” command:
SW1#sh mac-add add 0000.85de.1561
Unicast Entries
vlan mac address type protocols port
-------+---------------+--------+---------------------+--------------------
1 0000.85de.1561 dynamic ip GigabitEthernet2/2
54 0000.85de.1561 dynamic ip GigabitEthernet2/4 |
We see that the MAC is coming in on port gi2/2 and gi2/4. One port will lead us to where that MAC is plugged in and the other will lead us to the loop. Pick a port and start working through. This is where CDP comes in handy:
BLV0001S#sh cdp nei gi1/2
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
SW2 Gig 2/2 160 S I WS-C3560-4Gig 0/1 |
Next we move to that switch and so on and so forth. Eventually we will come to the switch with the loop. In this case one of our switches had a little workgroup switch plugged into two ports, in two separate VLANs, which is why it wasn’t caught by STP.
This was a short one, just quickly posting up a scenario I ran into today. Let me know if it needs more information or I left anything out.
Related Posts:
HSRP Tutorial
about 2 weeks ago - 9 comments
Today’s topic is HSRP (Hot Standby Routing Protocol). HSRP is a Cisco proprietary “First Hop Redundancy Protocol”. It is typically used for redundancy at the first hop from a client segment. It is used with two or more routers in a group who share a virtual IP address. One router is active at a given time and will reply to ARP requests. In this example, we have R1 and R2 in standby group 100 with a virtual IP of 192.168.100.1. This IP will be the default gateway for all hosts in VLAN 100. Here is the topology:
This is a basic topology, both R1 and R2 have connections to the internet. They are running HSRP on their FastEthernet 0/0 interfaces. Here’s the basic HSRP config:
R1(config)#interface fa0/0 R1(config-if)#ip address 192.168.100.2 255.255.255.0 R1(config-if)#standby 100 ip 192.168.100.1 R2(config)#interface fa0/0 R2(config-if)#ip address 192.168.100.3 255.255.255.0 R2(config-if)#standby 100 ip 192.168.100.1 |
Very simple so far. We use the “standby [0-255] ip [virtual ip address]” command.
Let’s verify the config:
R1#sh standby
FastEthernet0/0 - Group 100
State is Active
2 state changes, last state change 00:20:19
Virtual IP address is 192.168.100.1
Active virtual MAC address is 0000.0c07.ac64
Local virtual MAC address is 0000.0c07.ac64 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.696 secs
Preemption disabled
Active router is local
Standby router is 192.168.100.3, priority 100 (expires in 8.980 sec)
Priority 100 (default 100)
Group name is "hsrp-Fa0/0-100" (default)
R2#sh standby
FastEthernet0/0 - Group 100
State is Standby
1 state change, last state change 00:19:40
Virtual IP address is 192.168.100.1
Active virtual MAC address is 0000.0c07.ac64
Local virtual MAC address is 0000.0c07.ac64 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.836 secs
Preemption disabled
Active router is 192.168.100.2, priority 100 (expires in 9.544 sec)
Standby router is local
Priority 100 (default 100)
Group name is "hsrp-Fa0/0-100" (default) |
The main command we’ll use with HSRP is “show standby”. It gives us quite a bit of information, we see the group number (100), we see that R1 is the active router in the group, we also see information about state changes, the VIP, timers, other useful details, and priority, which we’ll talk about next.
HSRP routers use “priority” to determine which router should be active, the default is 100. We’ll set R1′s priority to 110, forcing it to be the active router. We will also use interface tracking, which tells the router to decrement its priority if the tracked interface goes down. Here we’ll track both routers’ Fa0/1 interfaces, which connect them to the internet. We will also enable preemption, which will cause the router with the highest priority to become active. Here’s the config:
R1(config)#int fa0/0 R1(config-if)#standby 100 priority 110 R1(config-if)#standby 100 preempt R1(config-if)#standby 100 track fa0/1 20 R2(config)#int fa0/0 R2(config-if)#standby 100 preempt R2(config-if)#standby 100 track fa0/1 20 |
We’ve configured R1 to decrement its priority by 20 if its fa0/1 interface goes down, this will cause R2 to become active for the group.
Now we’ll test the config:
R1(config)#int fa0/1
R1(config-if)#shut
R1(config-if)#
*Mar 1 00:38:29.495: %TRACKING-5-STATE: 1 interface Fa0/1 line-protocol Up->Down
R1(config-if)#
*Mar 1 00:39:51.747: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Active -> Speak
R1(config-if)#
*Mar 1 00:40:01.747: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Speak -> Standby
R1(config-if)#^Z
R1#sh standby
FastEthernet0/0 - Group 100
State is Standby
4 state changes, last state change 00:00:45
Virtual IP address is 192.168.100.1
Active virtual MAC address is 0000.0c07.ac64
Local virtual MAC address is 0000.0c07.ac64 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.568 secs
Preemption enabled
Active router is 192.168.100.3, priority 100 (expires in 8.556 sec)
Standby router is local
Priority 90 (configured 110)
Track interface FastEthernet0/1 state Down decrement 20
Group name is "hsrp-Fa0/0-100" (default) |
It worked as expected. R2 transitioned to active for the group. When we no shut R1′s fa0/1 interface, we should see it regain its active status for the group.
Let’s verify:
R1(config)#int fa0/1
R1(config-if)#no shut
R1(config-if)#
*Mar 1 00:43:23.251: %TRACKING-5-STATE: 1 interface Fa0/1 line-protocol Down->Up
R1(config-if)#
*Mar 1 00:43:24.759: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Standby -> Active
R1(config-if)#^Z
R1#sh s
*Mar 1 00:44:03.479: %SYS-5-CONFIG_I: Configured from console by console
R1#sh standby
FastEthernet0/0 - Group 100
State is Active
5 state changes, last state change 00:00:41
Virtual IP address is 192.168.100.1
Active virtual MAC address is 0000.0c07.ac64
Local virtual MAC address is 0000.0c07.ac64 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.360 secs
Preemption enabled
Active router is local
Standby router is 192.168.100.3, priority 100 (expires in 8.376 sec)
Priority 110 (configured 110)
Track interface FastEthernet0/1 state Up decrement 20
Group name is "hsrp-Fa0/0-100" (default) |
No surprise here, it’s back being the active router for standby group 100.
In my experience, HSRP is very, very common. I’ve seen it used in nearly every medium to large company I’ve worked with. I hope this post has been helpful.
Related Posts:
IOS Macros
about 3 weeks ago - 6 comments
Here’s another short (but hopefully useful) post. We’ll be going through IOS Macros.
I’ve never used IOS Macros before, but I was asked about a problem today, and a macro seems to be an ideal solution. A friend of mine is an engineer for a service provider with a very large network. He has been tasked with implementing passive interfaces as the default for OSPF across the network. Most of the devices which will be modified rely on OSPF for management connectivity. When he runs the “passive-interface default” command, he will lose connectivity before he is able to run “no passive-interface [interface]” to restore connectivity. Macros tell the router to run the predetermined commands for us, which will save us from getting locked out.
The topology is simple and not worth a diagram. R1 and R2 are connected via their FastEthernet0/0 interfaces. They are running OSPF on this interface.
Here’s the config:
macro name Passive-Interface-Default router ospf 100 passive-interface default no passive-interface fa0/0@ |
We give the macro a name, then we set the commands to be run, we close it out with the @ sign. Here are the commands entered on the router:
R1(config)#macro name Passive-Interface-Default Enter macro commands one per line. End with the character '@'. router ospf 100 passive-interface default no passive-interface fa0/0@ R1(config)# |
First we’ll verify out neighbor relationship:
R1#sh ip ospf neigh Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DR 00:00:34 10.1.12.2 FastEthernet0/0 |
Neighbors are up, everything looks good.
Now we’ll try out the macro:
R1(config)#macro global apply Passive-Interface-Default R1(config)# *Mar 1 00:06:44.111: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Mar 1 00:06:44.511: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading Done R1(config)# |
The command is “macro global apply [macro name]“. Notice that it is run from global config mode. We see that it worked, our neighbors dropped and reformed in under a second.
Let’s verify the config:
R1#sh run | sec ospf router ospf 100 passive-interface default no passive-interface FastEthernet0/0 |
No suprises there either, everything worked as expected.
Macros are another under-documented and likely under-used technology built into IOS. They can be very valuable if you need to make remote changes that are likely to affect your connectivity to the device.
Again, sorry for the lack of updates. Just got back from a four day Disaster Recovery test in Philadelphia and also still chugging away with ITIL. I’m expecting to be done with ITIL very soon at which point I will be back to Cisco study with a vengeance.
Related Posts:
Educational IOS Petition
about 2 months ago - 3 comments
Greg at Etherealmind has created a petition for an educational IOS version. Details:
We the undersigned ask you to sign our petition.
We are the people who are learning about Data networking and Cisco IOS software. As students and practitioners, we need to learn theory and knowledge and then to take that knowledge and practice on Cisco IOS software.
We want to be able to practice that knowledge, and demonstrate our competence. We know that you are considering the value. This petition is to show our need for this solution. Wendel Odom discusses the possibility Cisco Considers IOS for Certifcation Self Study and we are calling for Cisco to make an option available.
This experience and knowledge we gain gives us the capability to make the most of Cisco equipment for our employers, your customers. We help drive the best return on investment, and keep the network performing in the way that your customers expect.
We can test configurations prior to making and be better prepared. We can develop more complex configurations than would otherwise be possible, and not blame the equipment afterwards.
We resolve problems more quickly, we make better designs and we have greater confidence in our work. We raise less support cases (and reduce your costs) by being to perform our own testing and validation.
Whether we are resellers, consultants, students or just interested in learning, we all need an practical method to access IOS and practice.
Therefore, we are asking Cisco Systems to make a version of IOS available for educational and testing purposes.
Greg Ferro
I encourage everyone reading this to sign it!
Related Posts:
Studying ITILv3
about 2 months ago - 8 comments
Sorry for the horrible lack of updates lately. I had to shift focus a bit to meet a job requirement. It’s come down from the top that everyone in the North American Network group within my company needs to get the ITILv3: Foundations cert by September of this year (ugh!). I’ve been cramming it like crazy and hope to knock the exam out in the next couple weeks. If that all works out I can get back to Cisco stuff and hopefully some decent posts.
If anyone is curious about ITIL, it’s terrible, lol. Supposedly it’s a valuable cert, so I can’t complain too much, but it’s just so boring. I love networking, so Cisco certs are actually fun for me. ITIL is just painful.
Anyway, check out my blogroll to get your networking fix.
Related Posts:
OSPF Summarization
about 2 months ago - 10 comments
This post is about OSPF Summarization. We’ll be using a familiar topology and going over two ways to summarize with OSPF.
There are two conventional ways to summarize networks in OSPF, we can use the “area range” command and the “summary-address” command. “Area range” is used on the ABR to summarize networks between areas. The “summary-address” command is used on the ASBR to summarize external networks.
Here’s the topology:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. On R1 I’ve added Lo11-14 and used “ospf 100 area 0″ under the respective interfaces. On R2 I’ve added Lo15-18 and used “redistribute connected subnets”. Let’s look at the RIBs on a couple routers:
First we’ll check out “sh ip route” on R1:
R1#sh ip route
...
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 01:13:32, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.123.3, 01:12:38, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.123.3, 01:03:47, FastEthernet0/0
172.30.0.0/24 is subnetted, 4 subnets
O E2 172.30.6.0 [110/20] via 10.1.123.2, 00:06:11, FastEthernet0/0
O E2 172.30.7.0 [110/20] via 10.1.123.2, 00:06:11, FastEthernet0/0
O E2 172.30.5.0 [110/20] via 10.1.123.2, 00:06:11, FastEthernet0/0
O E2 172.30.8.0 [110/20] via 10.1.123.2, 00:06:11, FastEthernet0/0
C 192.168.4.0/24 is directly connected, Loopback14
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.34.0 [110/74] via 10.1.123.3, 01:12:39, FastEthernet0/0
C 10.1.123.0 is directly connected, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Loopback11
C 192.168.2.0/24 is directly connected, Loopback12
C 192.168.3.0/24 is directly connected, Loopback13 |
Lots of routes here. The ones to note are the 172s showing as External Type 2, which are R2′s loopbacks. Also notice our connected loopbacks.
Now let’s check out the RIB on R4:
R4#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
172.30.0.0/24 is subnetted, 4 subnets
O E2 172.30.6.0 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
O E2 172.30.7.0 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
O E2 172.30.5.0 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
O E2 172.30.8.0 [110/20] via 10.1.34.3, 00:01:26, Serial0/0
O IA 192.168.4.0/24 [110/75] via 10.1.34.3, 00:01:26, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:01:26, Serial0/0
O IA 192.168.1.0/24 [110/75] via 10.1.34.3, 00:01:26, Serial0/0
O IA 192.168.2.0/24 [110/75] via 10.1.34.3, 00:01:26, Serial0/0
O IA 192.168.3.0/24 [110/75] via 10.1.34.3, 00:01:26, Serial0/0 |
Here we see the loopbacks from R1 as Inter-Area, and the loopbacks from R2 as External Type 2.
Now we’ll configure the “area range” command to summarize R1′s loopbacks on R3 (ABR):
R3(config)#router ospf 100 R3(config-router)#area 0 range 192.168.0.0 255.255.248.0 |
Seems almost too easy. We use “area 0 range [IP] [Summary Mask]“.
Let’s verify on R4:
R4#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
172.30.0.0/24 is subnetted, 4 subnets
O E2 172.30.6.0 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
O E2 172.30.7.0 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
O E2 172.30.5.0 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
O E2 172.30.8.0 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:04:51, Serial0/0
O IA 192.168.0.0/21 [110/75] via 10.1.34.3, 00:00:13, Serial0/0 |
It worked! We shrunk all those loopbacks from R1 into a single summary route.
Now we’ll summarize on R2 (ASBR) using the “summary-address” command.
R2(config)#router ospf 100 R2(config-router)#summary-address 172.30.0.0 255.255.240.0 |
Again, pretty easy stuff, we used the “summary-address [IP] [Summary Mask]” command on R2 (ASBR) to summarize its loopbacks.
Let’s look at R4′s RIB now:
R4#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:37:55, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:02:15, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:04:01, Serial0/0
172.30.0.0/20 is subnetted, 1 subnets
O E2 172.30.0.0 [110/20] via 10.1.34.3, 00:02:15, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:37:55, Serial0/0
O IA 192.168.0.0/21 [110/75] via 10.1.34.3, 00:33:17, Serial0/0 |
It worked this time too. We see two summaries now, one Inter-Area summary for R1′s loopbacks, which we summarized on R3 (ABR) and also a External Type 2 summary for R2′s loopbacks which we configured on R2 (ASBR) itself.
Something to note before I end this one, when we create summary routes the router will install a “discard route” to null locally. This helps prevent routing loops. It will not interfere with the networks we summarize for as they are longer matches. Here are the two examples:
R2#sh ip route | i Null O 172.30.0.0/20 is a summary, 00:09:02, Null0 R3#sh ip route | i Null O 192.168.0.0/21 is a summary, 00:39:27, Null0 |
That’s OSPF Summarization in a nutshell. There are some other tricks you can use when summarizing, I may go into them in another post. Or you guys could talk about them in the comments. 
Related Posts:
OSPF Area Types: Not So Totally Stubby
about 2 months ago - No comments
This is the last post in a series about OSPF Area Types. Today we’ll go over Not So Totally Stubby Areas. We’ll be using the same topology as the NSSA post, but this time we will inject a specific route (40.40.40.0/24) from the ASBR (R4) instead of a default.
Quick refresher, OSPF Not So Totally Stubby Areas have intra-area routes (Type 2 LSAs) and also external routes in the form of Type 7 LSAs, which are converted to Type 5 LSAs by the ABR. No inter-area routes (Type 3 LSAs) are permitted in a Not So Totally Stubby Area and a default route will be injected by the ABR.
(For more detailed information on LSAs and Area Types, check out this post.)
Here’s the topology:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. I’ve redistributed loopbacks on each router (“redistribute connected subnets” under the OSPF process) to give us some external routes, and I added 34.34.34.34/32 to Area 34 so we have an intra-area route to look at. I’ve also added a static route on R4 (40.40.40.0/24) which I’m injecting into OSPF with the “redistribute static subnets” command. Let’s look at some show commands BEFORE we make area 34 a Not So Totally Stubby Area:
First we’ll check out “sh ip route ospf” on R3:
R3#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.123.1, 00:04:20, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 00:04:20, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.34.4, 00:03:33, Serial0/0
40.0.0.0/24 is subnetted, 1 subnets
O E2 40.40.40.0 [110/20] via 10.1.34.4, 00:02:57, Serial0/0 |
Here we see all the loopbacks and the static (40.40.40.0/24) come through as external type 2, which is the default.
Now let’s check out the RIB on R4:
R4#sh ip route
...
Gateway of last resort is not set
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:04:51, Serial0/0
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:04:51, Serial0/0
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
40.0.0.0/24 is subnetted, 1 subnets
S 40.40.40.0 is directly connected, Null0
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.34.0 is directly connected, Serial0/0
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:04:51, Serial0/0 |
We see one intra-area route (O – LSA 2) to 34.34.34.34/32, one inter-area route (O IA – LSA 3) to 10.1.123.0/23 and three external type 2 (O E2 – LSA 5) routes to the respective loopbacks. Also notice the static (40.40.40.0/24) to null0, which we’re injecting into the OSPF domain.
Now we’ll configure area 34 as not so totally stubby:
R3(config)#router ospf 100 R3(config-router)#area 34 nssa no-summary R4(config)#router ospf 100 R4(config-router)#area 34 nssa |
Easy stuff, we configure area 34 with “nssa no-summary” on R3 (ABR), then we configure R4 (ASBR) with “nssa” for area 34.
Let’s examine the new RIB on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:01:50, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O N2 3.3.3.3 [110/20] via 10.1.34.3, 00:01:50, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.34.3, 00:01:50, Serial0/0 |
We now have only three OSPF routes, our O (LSA 2) for the 34.34.34.34/32 network, our O*IA default route, which is injected from R3 (ABR) and the N2 (LSA 7) route for R3′s loopback, which is being redistributed with the “redistribute connected subnets” command on R3.
Here’s R4′s OSPF Database:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 255 0x80000006 0x00A1D5 3
4.4.4.4 4.4.4.4 252 0x80000009 0x0025E4 2
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 3.3.3.3 272 0x80000001 0x00DE4B
Type-7 AS External Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Tag
3.3.3.3 3.3.3.3 271 0x80000001 0x00E69F 0
4.4.4.4 4.4.4.4 256 0x80000001 0x0090B4 0
40.40.40.0 4.4.4.4 256 0x80000001 0x00A339 0 |
We see the router LSAs for R3 and R4, which are normal. Next we see the Type 3 LSA for the default route R3 is injecting and finally we see three Type 7 LSAs, one for each external network injected into area 34.
Last we’ll look at R1′s RIB so we can see how Not So Totally Stubby Areas affect the OSPF domain:
R1#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O IA 34.34.34.34 [110/11] via 10.1.123.3, 00:14:31, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 00:15:24, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.123.3, 00:14:31, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.123.3, 00:05:40, FastEthernet0/0
40.0.0.0/24 is subnetted, 1 subnets
O E2 40.40.40.0 [110/20] via 10.1.123.3, 00:05:40, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.34.0 [110/74] via 10.1.123.3, 00:14:31, FastEthernet0/0 |
The table looks normal. The important thing to note here is that the external routes from R4 are showing up as O E2 (LSA 5s), which we know is caused by R3 converting them from the Type 7s which only exist in NSSAs to Type 5s, which are allowed in normal areas.
Not So Totally Stubby Areas sound odd, and I’ve never seen them in the real world, but they are fair game on the CCIE lab, and you may come across them in a real network. The key concepts are simply that LSA Type 5s are not allowed in Not So Totally Stubby Areas, external routes will show as N (LSA 7s) in the RIB and are converted to Type 5s on the ABR before leaving the area. Also remember that the ABR injects a default route like a normal Totally Stubby Area.
Related Posts:
OSPF Area Types: NSSA
about 2 months ago - 3 comments
Today we’ll go over Not So Stubby Areas (NSSA). We will be using a slightly different topology here, we will make R4 an ASBR with a connection to the internet.
Quick refresher, OSPF NSSAs have inter and intra-area routes (Type 2 and Type 3 LSAs) and also external routes in the form of Type 7 LSAs, which are converted to Type 5 LSAs by the ABR.
(For more detailed information on LSAs and Area Types, check out this post.)
Here’s the topology:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. I’ve also redistributed loopbacks on each router (“redistribute connected subnets” under the OSPF process) to give us some external routes, and I added 34.34.34.34/32 to Area 34 so we have an intra-area route to look at. I’ve also added a static default route on R4 which I’m injecting into OSPF with the “default-information originate” command. Let’s look at some show commands BEFORE we make area 34 an NSSA:
First we’ll check out “sh ip route ospf” on R3:
R3#sh ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.123.1, 00:03:42, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 00:03:42, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.34.4, 00:04:22, Serial0/0
O*E2 0.0.0.0/0 [110/1] via 10.1.34.4, 00:03:59, Serial0/0 |
Here we see all the loopbacks and the default come through as external type 2, which is the default.
Now let’s check out the RIB on R4:
R4#sh ip route
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:06:39, Serial0/0
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:06:02, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:06:02, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:06:39, Serial0/0
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.34.0 is directly connected, Serial0/0
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:06:39, Serial0/0
S* 0.0.0.0/0 is directly connected, Null0 |
We see one intra-area route (O – LSA 2) to 34.34.34.34/32, one inter-area route (O IA – LSA 3) to 10.1.123.0/23 and three external type 2 (O E2 – LSA 5) routes to the respective loopbacks. Also notice the static default to null0, which we’re injecting into the OSPF domain.
Now we’ll configure area 34 as an NSSA:
R3(config)#router ospf 100 R3(config-router)#area 34 nssa R4(config)#router ospf 100 R4(config-router)#no default-information originate R4(config-router)#area 34 nssa default-information-originate |
Pretty basic config, we configure area 34 as NSSA on R3 (ABR), then we remove the “default-information originate” command from R4 (ASBR) and use “area 34 nssa default-information-originate” to change the area to an NSSA and inject the default route.
Let’s examine the new RIB on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:02:56, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O N2 3.3.3.3 [110/20] via 10.1.34.3, 00:02:56, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:02:56, Serial0/0 |
We see some cool stuff here, our O and IA routes are still present, but we also have an N2 (LSA 7) route now for R3′s loopback, which is being redistributed.
Here’s R4′s OSPF Database:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 300 0x80000005 0x00A3D4 3
4.4.4.4 4.4.4.4 299 0x80000004 0x002FDF 2
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
10.1.123.0 3.3.3.3 492 0x80000002 0x005A3F
Type-7 AS External Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 4.4.4.4 304 0x80000001 0x008ADD 0
3.3.3.3 3.3.3.3 491 0x80000001 0x00E69F 0
4.4.4.4 4.4.4.4 304 0x80000001 0x0090B4 0 |
First we see the router LSAs for R3 and R4, which are normal. Next we see the Type 3 LSA for 10.1.123.0 and finally we see three Type 7 LSAs, one for each external network injected into area 34.
Last we’ll look at R1′s RIB so we can get a full picture of how NSSAs affect OSPF domains:
R1#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O IA 34.34.34.34 [110/11] via 10.1.123.3, 00:20:46, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.123.2, 00:22:14, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.123.3, 00:20:46, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O E2 4.4.4.4 [110/20] via 10.1.123.3, 00:08:16, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.34.0 [110/74] via 10.1.123.3, 00:20:46, FastEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 10.1.123.3, 00:08:16, FastEthernet0/0 |
The table looks normal. The important thing to note here is that the external routes from R4 are showing up as O E2 (LSA 5s), which we know is caused by R3 converting them from the Type 7s which only exist in NSSAs to Type 5s, which are allowed in normal areas.
NSSAs are interesting, I’ve never seen one used in production, but I can see how they may be needed in some situations. The key concepts are simply that LSA Type 5s are not allowed in NSSA, external routes originated in the NSSA will show as N (LSA 7s) in the RIB and are converted to Type 5s on the ABR before leaving the area.
Related Posts:
OSPF Area Types: Totally Stubby
about 3 months ago - 4 comments
This is the first post in a series about OSPF Area Types. Today we’ll go over Totally Stubby areas. We’ll be using the same topology as the Stub post. I’m also reposting the first portion of that here since it will be the same.
Quick refresher, OSPF Totally Stubby Areas allow only intra-area routes and a default route generated by the ABR (Type 2 LSAs – the default route comes through as a Type 3 LSA, but no other Type 3s are allowed). Inter-area and External routes (Type 5 LSAs) are not allowed in totally stubby areas.
(For more detailed information on LSAs and Area Types, check out this post.)
Here’s the topology:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. I’ve also redistributed loopbacks on each router (“redistribute connected subnets” under the OSPF process) to give us some external routes, and I added 34.34.34.34/32 to Area 34 so we have an intra-area route to look at. Let’s look at some show commands BEFORE we make area 34 totally stubby:
First we’ll check out “sh ip route ospf” on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:01:17, Serial0/0
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:01:17, Serial0/0 |
As expected, we see everything. 34.34.34.34/32 has come through as an intra-area route (O – LSA 2). We see our loopbacks from each router come through as external (O E2 – LSA 5, something to note is E2 routes do not increment cost as they traverse the network, so we see a cost of 20, which will be the same throughout the OSPF domain). Last we see 10.1.123.0/24 as an inter-area route (O IA – LSA 3).
Now let’s check out the OSPF Database on R4:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 3 0x8000000C 0x00EF87 3
4.4.4.4 4.4.4.4 2 0x8000000D 0x00ABEB 1
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
10.1.123.0 3.3.3.3 113 0x80000003 0x00B2EB
Summary ASB Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 119 0x80000001 0x0057CA
2.2.2.2 3.3.3.3 119 0x80000001 0x0029F4
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 1.1.1.1 1293 0x80000001 0x009BFC 0
2.2.2.2 2.2.2.2 1303 0x80000001 0x004F41 0
3.3.3.3 3.3.3.3 119 0x80000004 0x00FC88 0
4.4.4.4 4.4.4.4 3 0x80000004 0x00B0CC 0 |
Lots of output, but nothing crazy. We see our LSAs for area 34, and our redistributed loopbacks as external LSAs.
Now we’ll configure area 34 totally stubby:
R3(config)#router ospf 100 R3(config-router)#area 34 stub no-summary R4(config)#router ospf 100 R4(config-router)#area 34 stub |
There isn’t much to the config at all, as we can see. The command is “area n stub no-summary”, this tells the ABR not to send Type 3s into the area. On the non-ABR(s) we simply specify the area as a stub, the “no summary” keyword is only needed on the ABR.
Let’s examine the new RIB on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:02:04, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.34.3, 00:02:04, Serial0/0 |
Very small table. Here we see that all the external routes are gone, but intra-area route to 34.34.34.34 is still in the table. Our only other OSPF route is the default generated by R3.
Finally we’ll look at the OSPF Database:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 665 0x8000000B 0x000A72 3
4.4.4.4 4.4.4.4 300 0x8000000A 0x00957D 2
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 3.3.3.3 1214 0x80000001 0x0057DA |
It is much smaller now. We see the router LSAs and a single inter-area LSA, the default route from R3.
Totally Stubby areas are pretty basic once you understand Stub areas and LSAs in general. The key concepts are simply that LSA Type 3s and Type 5s are not allowed in totally stubby areas, and also that a default route is generated by the ABR.
Related Posts:
OSPF Area Types: Stub
about 3 months ago - 5 comments
This is the first post in a series about OSPF Area Types. Today we’ll go over Stub areas. This one will be somewhat short on config, but should have a good amount of show commands.
Quick refresher, OSPF Stub Areas allow inter- and intra-area routes (Type 2 and Type 3 LSAs). External routes (Type 5 LSAs) are not allowed in stub areas.
(For more detailed information on LSAs and Area Types, check out this post.)
We’ll be using the same topology we used for OSPF Authentication:
I’m not going through the basic OSPF config, so assume everything is configured as the diagram suggests. I’ve also redistributed loopbacks on each router to give us some external routes, and I added 34.34.34.34/32 to Area 34 so we have an intra-area route to look at. Let’s look at some show commands BEFORE we make area 34 a stub:
First we’ll check out “sh ip route ospf” on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:01:17, Serial0/0
1.0.0.0/32 is subnetted, 1 subnets
O E2 1.1.1.1 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 10.1.34.3, 00:01:17, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:01:17, Serial0/0 |
As expected, we see everything. 34.34.34.34/32 has come through as an intra-area route (O – LSA 2). We see our loopbacks from each router come through as external (O E2 – LSA 5, something to note is E2 routes do not increment cost as they traverse the network, so we see a cost of 20, which will be the same throughout the OSPF domain). Last we see 10.1.123.0/24 as an inter-area route (O IA – LSA 3).
Now let’s check out the OSPF Database on R4:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 3 0x8000000C 0x00EF87 3
4.4.4.4 4.4.4.4 2 0x8000000D 0x00ABEB 1
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
10.1.123.0 3.3.3.3 113 0x80000003 0x00B2EB
Summary ASB Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 119 0x80000001 0x0057CA
2.2.2.2 3.3.3.3 119 0x80000001 0x0029F4
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 1.1.1.1 1293 0x80000001 0x009BFC 0
2.2.2.2 2.2.2.2 1303 0x80000001 0x004F41 0
3.3.3.3 3.3.3.3 119 0x80000004 0x00FC88 0
4.4.4.4 4.4.4.4 3 0x80000004 0x00B0CC 0 |
Lots of output, but nothing crazy. We see our LSAs for area 34, and our redistributed loopbacks as external LSAs.
Now we’ll configure area 34 as a stub:
R3(config)#router ospf 100 R3(config-router)#area 34 stub *Mar 1 00:13:39.675: %OSPF-5-ADJCHG: Process 100, Nbr 4.4.4.4 on Serial0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset R4(config)#router ospf 100 R4(config-router)#area 34 stub *Mar 1 00:03:25.923: %OSPF-5-ADJCHG: Process 100, Nbr 3.3.3.3 on Serial0/0 from LOADING to FULL, Loading Done |
Simple configuration, we configured area 34 as a stub under the OSPF process. Notice that the neighbors go down and reform once they match.
Let’s examine the new RIB on R4:
R4#sh ip route ospf
34.0.0.0/32 is subnetted, 1 subnets
O 34.34.34.34 [110/65] via 10.1.34.3, 00:01:33, Serial0/0
10.0.0.0/24 is subnetted, 2 subnets
O IA 10.1.123.0 [110/74] via 10.1.34.3, 00:01:33, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.34.3, 00:01:33, Serial0/0 |
Here we see that all the external routes are gone, but intra- and inter-area routes are still in the table. The inter-area route to 10.1.123.0/24 is still there, and we also have a default route, which is showing as an inter-area route as well.
Finally we’ll look at the OSPF Database:
R4#sh ip ospf d
OSPF Router with ID (4.4.4.4) (Process ID 100)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 259 0x8000000E 0x000475 3
4.4.4.4 4.4.4.4 258 0x80000010 0x008983 2
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 3.3.3.3 308 0x80000001 0x0057DA
10.1.123.0 3.3.3.3 308 0x80000004 0x00CED0 |
It is much smaller now. We see the router LSAs and only two inter-area LSAs, the default route and the route to 10.1.123.0/24.
I was planning on putting a debug in here as well, but I didn’t really get anything interesting enough to add.
OSPF Stub Areas are relatively simple, but can be confusing when first digging into OSPF. The key concepts are simply that LSA Type 5s are not allowed in stub areas, and also that a default route is generated by the ABR. I very much expect to see stub areas of some sort on the CCIE lab.
about 3 months ago
I wont post out the full configuration, as it would just be a couple of access lists and a route map on top of standard BGP configuration, but if Weight and LP can’t be used, I’d just use MED, given no other attributes before it are being used.
Another way would be to prepend AS’s with an AS Path access list on R2 to R1, so that R3 is seen as the route with the lowest hop count.
about 3 months ago
I also noticed after I’d posted that, you could only change the config on R1…I believe a similar approach is still possible though on R1
about 3 months ago
Your ideas would work. Not creative enough though. :p
about 3 months ago
Set the AD to be lower for that particular prefix/neighbor?
about 3 months ago
Hmm. How would you accomplish that?
about 3 months ago
static route would be the easyst way
routemap (if destination = 192.168.1.0/24 send it out the R3 int)
about 3 months ago
Route-map? That’s PBR, not a static route.
And this is a BGP challenge, not a static route/PBR challenge, lol.
about 3 months ago
Use route-map and access-list to set a lower MED for the 192.168.1.0/24 route received from R2
about 3 months ago
actually meant those as 2 different options
about 3 months ago
Ah. Well still, use BGP.
about 3 months ago
Colby, in this case u can indeed set the AD for particular route lower or higher, like MrPaul said.
It is doable just like in EIGRP and OSPF.
distance
about 3 months ago
argh, somehow my code is replaced with a smiley.
i meant,
distance [AD] [source ip] [wildcard] [ACL]
about 3 months ago
And you can apply it to a specific neighbor?
about 3 months ago
yes, with configuring the source-ip.
about 3 months ago
How about prepending announcements received from R2, with a route-map in the inbound direction, on R1?
router bgp 100
neighbor R2 remote-as 234
neighbor R2 route-map prepend-last-as in
neighbor R3 remote-as 234
!
route-map prepend-last-as permit 10
set as-path prepend last-as 2
about 3 months ago
Yep, that would work!
about 3 months ago
use the set origin command in the route-map configuration mode, the bgp path selection process simply does the rest. lol
about 3 months ago
R1(config)#route-map R2Origin permit 10
R1(config)#set origin incomplete
R1(config)#exit
R1(config-router)#nei R2 route-map R2Origin in