Just another Cisco blog
Basic JUNOS Configuration
Today we’ll go over a very basic JUNOS configuration, we will configure the hostname, user account, IP addresses and a default route. The purpose of this article is to provide a look and feel for JUNOS.
First let’s login and take care of the basics:
root> configure [edit] root# set system host-name Olive1 [edit] root# set system login user colby class super-user authentication plain-text-password New password: Retype new password: [edit] root# commit and-quit commit complete Exiting configuration mode |
This is a simple config, we enter configuration mode, we set the hostname of the router then we configure a user named “colby” in the “super-user” class. “Super-user” is a pre-defined class in JUNOS, this class has full control of the router.
Anyone familiar with IOS can see that this is pretty different. The commands all start with “set” and they can be quite a bit longer. Let’s take a look at the hierarchical view of what we just did:
system {
host-name Olive1;
login {
user colby {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$IKhmMCbo$XNAWMDS"; ## SECRET-DATA
}
}
}
} |
Definitely not what I’m used to, but not so bad. Now we’ll configure the same thing with multiple commands from the hierarchy:
[edit] colby@Olive1# edit system [edit system] colby@Olive1# set host-name Olive1 [edit system] colby@Olive1# edit login [edit system login] colby@Olive1# set user colby class super-user authentication plain-text-password New password: Retype new password: |
I prefer to stay at the top of the hierarchy and use as few commands as possible, but it seems that many people like digging into the hierarchy. The rest of the configuration in this article will be from the top using as few commands as possible.
Next we’ll do a “show interfaces terse”, which is like our old pal “sh ip interface brief” in IOS:
colby> show interfaces terse Interface Admin Link Proto Local Remote dsc up up em0 up up em1 up up gre up up ipip up up lo0 up up lo0.16384 up up inet 127.0.0.1 --> 0/0 lo0.16385 up up inet lsi up up mtun up up pimd up up pime up up tap up up |
This looks a little different than “sh ip int b”, but it’s very easy to read. The interfaces we’ll be working with today are “em0″ and “lo0″, em0 is our ethernet interface (this is how they’re named in Olives running in VMs apparently), and lo0 is our loopback.
Let’s give em0 an IP address:
[edit] colby@Olive1# set interfaces em0 unit 0 family inet address 192.168.25.100/24 [edit] colby@Olive1#commit commit complete [edit] colby@Olive1# run show interfaces terse Interface Admin Link Proto Local Remote ... em0 up up em0.0 up up inet 192.168.25.100/24 ... lo0 up up |
We’ve set an interface on em0. The command configures a logical interface with an ipv4 address of 192.168.25.100/24 (255.255.255.0). We use “unit 0″ on this ethernet interface since it is not a tagged/trunk link. We have basically configured the equivalent to a subinterface in IOS, but this is normal practice for assigning IPs to interfaces in JUNOS.
Let’s give our loopback an IP too:
[edit] colby@Olive1# set interfaces lo0.1 family inet address 192.168.30.1/24 [edit] colby@Olive1# run show interfaces terse Interface Admin Link Proto Local Remote ... em0.0 up up inet 192.168.25.100/24 ... lo0.1 up up inet 192.168.30.1/24 |
The same as configuring a physical interface. Here’s a look at the hierarchy:
interfaces {
em0 {
unit 0 {
family inet {
address 192.168.25.100/24;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.30.1/24;
}
}
}
} |
Now we need a default route so we can send and receive traffic:
[edit] colby@Olive1# set routing-options static route 0.0.0.0/0 next-hop 192.168.25.1 [edit] colby@Olive1# run show route terse inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A Destination P Prf Metric 1 Metric 2 Next hop AS path * 0.0.0.0/0 S 5 >192.168.25.1 * 192.168.25.0/24 D 0 >em0.0 * 192.168.25.100/32 L 0 Local * 192.168.30.0/24 D 0 >lo0.1 * 192.168.30.1/32 L 0 Local |
That’s our very basic JUNOS configuration. We’ve configured a user, given the router a hostname, and set up IPs and routing. Here’s our hierarchy at the end:
system {
host-name Olive1;
login {
user colby {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$IKhmMCbo$XNAWMDS"; ## SECRET-DATA
}
}
}
}
interfaces {
em0 {
unit 0 {
family inet {
address 192.168.25.100/24;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.30.1/24;
}
}
}
} |
For reference, this is the same config in IOS:
hostname Router ! username colby privilege 15 secret [password] ! interface fa0/0 ip address 192.168.25.100 255.255.255.0 ! interface lo1 ip address 192.168.30.1 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 192.168.25.1 |
IOS needs more commands typed out, but the JUNOS commands are much longer. In my next JUNOS post I’ll go over OSPF and maybe NAT, if I ever figure out how to make it work.
Related Posts:
- ASA Bridge Groups
- 2960s Can Route
- Connecting Voice Gateways/CME to the PSTN
- Firewall Object Groups
- Testing link/circuit speed using Iperf
| Print article | This entry was posted by Colby on January 20, 2010 at 6:44 am, and is filed under Juniper, Tutorials. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
No trackbacks yet.
ASA Bridge Groups
about 5 months ago - 2 comments
Hello everyone. I know I’ve been neglecting this blog for too long. Can’t promise that things are going to change, but I have a good post for today.
I was recently exposed to some new technology while working with a customer. I had to learn it pretty quickly. This post is about a new feature in the Cisco ASA 8.4 code called Bridge Groups. This is essentially the addition of BVI interfaces, which have existed in IOS forever. This feature is useful when running an ASA transparently, but not physically inline. Running a firewall physically inline works well, but it can limit you to the number of available interfaces you have on each firewall. Adding physical interfaces to a firewall is expensive. This feature also saves you from using a context per firewalled VLAN on your ASA. Here we’ll use a 3750 for physical connectivity and use BVIs to force traffic through the firewall. Here is the physical topology:

I’m trying to convey quite a bit of information with this diagram. We have a layer 3 switch as the “core” and an ASA 5505 trunked to it. We have two hosts, PC1 and Server which are in VLAN 50 and VLAN 25, respectively. VLAN 26 is only for management of the ASA. VLAN 50 (and 2050) is where we’ll focus for this post. I’m going to start with the config here as I think it will make more sense when I try to explain.
3750 Config:
vlan 25 name Servers vlan 50 name L2_Firewalled_Vlan50 vlan 2050 name L3_Firewalled_Vlan50 interface GigabitEthernet1/0/5 description ASA Inside switchport trunk encapsulation dot1q switchport trunk allowed vlan 26,50 switchport mode trunk spanning-tree portfast interface GigabitEthernet1/0/7 description ASA Outside switchport trunk encapsulation dot1q switchport trunk allowed vlan 2050 switchport mode trunk spanning-tree portfast interface Vlan25 description Servers-Media ip address 192.168.25.1 255.255.255.0 interface Vlan2050 ip address 192.168.50.1 255.255.255.0 |
This config is pretty basic. We have created some VLANs, configured some trunks and SVIs, etc. The key thing to notice here is that there is no L3 for VLAN 50, the L3 for PC1 exists in VLAN 2050.
ASA Config:
firewall transparent interface Ethernet0/1 switchport trunk allowed vlan 26,50 switchport mode trunk interface Ethernet0/2 switchport trunk allowed vlan 2050 switchport mode trunk interface Vlan26 nameif management bridge-group 2 security-level 100 interface BVI2 ip address 192.168.26.5 255.255.255.0 interface Vlan50 nameif inside bridge-group 1 security-level 100 interface Vlan2050 nameif outside bridge-group 1 security-level 0 interface BVI1 ip address 1.1.1.1 255.255.255.0 access-list inside-in extended permit ip any any access-group inside-in in interface inside route management 0.0.0.0 0.0.0.0 192.168.26.1 |
This is where the magic happens. First, we configure the firewall in transparent mode, then we configure out interfaces and allow the necessary VLANs, 50 and 26 (management) on the e0/1, which is the “inside” interface, and 2050 on e0/2, which is the “outside” interface. We then configure VLAN 26 for management and add it to bridge group 2, which has an IP and default route configured at the bottom, again, this is for management only. Then we configure VLANs 50 and 2050 with 50 as inside and 2050 as outside. Both VLANs are in bridge group 1. In my testing it appears that the BVI interface REQUIRES an IP address to pass traffic, but which IP you pick seems irrelevant, so I’ve used 1.1.1.1/24 here. Finally we have our inside-in access-list allowing any to any and we’ve applied it to the inside interface inbound.
Hopefully this is beginning to make sense. Essentially, all PC1 traffic destined outside of its subnet will traverse the firewall. When PC1 initiates traffic outside of its subnet, it will ARP for its gateway, which will begin on VLAN 50, then be bridged through the firewall to VLAN 2050. The 3750 will reply on 2050 which will be sent back to 50. All L3 traffic should flow this way. I’ve tried to make a diagram to show the flow:

Let’s do some testing:
C:\Users\PC1>telnet 192.168.25.10 22 SSH-2.0-OpenSSH_5.2 Protocol mismatch. Connection to host lost. C:\Users\PC1> |
Here we see that SSH is open from PC1 to Server.
Now let’s break that connectivity:
ASA(config)# access-list inside-in extended deny tcp any host 192.168.25.10 eq ssh ASA(config)# no access-list inside-in extended permit ip any any ASA(config)# access-list inside-in extended permit ip any any ASA(config)# sh run access-list inside-in access-list inside-in extended deny tcp any host 192.168.25.10 eq ssh access-list inside-in extended permit ip any any |
We added a deny statement for anything originating from the inside destined to TCP port 22 on Server and we allow everything else. We have verified that the ACL is correct.
Let’s test again:
C:\Users\PC1>telnet 192.168.25.10 22 Connecting To 192.168.25.10...Could not open connection to the host, on port 22: Connect failed C:\Users\PC1> |
The results are rather anti-climactic. The session just does not work.
It looks a bit more interesting on the ASA:
ASA# sh logg %ASA-4-106023: Deny tcp src inside:192.168.50.100/49198 dst outside:192.168.25.10/22 by access-group "inside-in" %ASA-4-106023: Deny tcp src inside:192.168.50.100/49198 dst outside:192.168.25.10/22 by access-group "inside-in" %ASA-4-106023: Deny tcp src inside:192.168.50.100/49198 dst outside:192.168.25.10/22 by access-group "inside-in" |
We see the session being denied on the ASA as expected.
That’s about it for this one. We can now run our transparent firewalls through an intermediate switch and we’re also able to run multiple VLANs through a transparent firewall without using up contexts. All we need to do to allow more VLANs to be firewalled is create the L2/L3 on the switch, add the VLANs to the trunks and configure the ASA with the appropriate SVIs and bridge groups (and ACLs). Hope this was useful.
Disclaimer: This is a very new feature to me. It’s working well in the lab, but please let me know if I have anything wrong or there is a better way to accomplish something.
Related Posts:
- Firewall Object Groups
- Cisco IOS Firewall Tutorial
- GRE/IPSEC Tutorial
- 2960s Can Route
- Connecting Voice Gateways/CME to the PSTN
2960s Can Route
about 11 months ago - 13 comments
I’ve been meaning to post this for some time. Awhile back there was a thread on Networking Forum where someone mentioned that 2960s can route now. The 2960 is now a layer 3 switch. I was skeptical, but then I was pointed to this link. I was very, very surprised. I’m not sure why Cisco decided to add this functionality to the 2960s, but I’m definitely grateful. As of 12.2(55)SE, 2960s are layer 3 switches (with some limitations which I’ll cover later). This knowledge came in handy shortly after reading that thread. I was working on a circuit upgrade for a remote side at my previous company. The circuit was ordered incorrectly and I ended up in need of a layer 3 switch ASAP. The tech we’d sent was leaving the next day, so there was no time to ship him anything. Luckily, we had some 2960s on site.
Configuring 2960s to route is pretty simple. The Switch Database Management template (SDM) needs to be changed to “lanbase-routing”. A reboot is (always) needed after changing the SDM template. After reboot, it’s just like enabling routing on any other L3 switch with the command “ip routing” from global config.
First we’ll change the SDM template:
SwitchA(config)#sdm prefer lanbase-routing Changes to the running SDM preferences have been stored, but cannot take effect until the next reload. Use 'show sdm prefer' to see what SDM preference is currently active. SwitchA(config)#^Z SwitchA#reload System configuration has been modified. Save? [yes/no]: y Proceed with reload? [confirm] |
After changing the SDM template, we are reminded that we’ll need to reboot and also given a command to verify the change after the next boot.
Now we verify:
SwitchA#show sdm prefer The current template is "lanbase-routing" template. The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 255 VLANs. number of unicast mac addresses: 4K number of IPv4 IGMP groups + multicast routes: 0.25K number of IPv4 unicast routes: 4.25K number of directly-connected IPv4 hosts: 4K number of indirect IPv4 routes: 0.25K number of IPv4 policy based routing aces: 0 number of IPv4/MAC qos aces: 0.125k number of IPv4/MAC security aces: 0.375k |
The change was successful and we’re given the details about this SDM template.
Now seems like a good time to touch on the limitations of the layer 3 capabilities on 2960s. As we see in the output above, we’re limited to 8 routed interfaces. These will be SVIs. At this point, the 2960s don’t support routed physical interfaces (“no switchport”). Another important note is that we’re only allowed 16 static routes and there is no dynamic routing capability.
Now we’ll enable IP routing and configure a couple SVIs:
SwitchA#conf t SwitchA(config)#ip routing SwitchA(config)# SwitchA(config)#int vlan 15 SwitchA(config-if)#ip add 192.168.15.1 255.255.255.0 SwitchA(config-if)# SwitchA(config-if)#int vlan 25 SwitchA(config-if)#ip add 192.168.25.1 255.255.255.0 SwitchA(config)#^Z SwitchA#sh ip route ... C 192.168.15.0/24 is directly connected, Vlan15 C 192.168.25.0/24 is directly connected, Vlan25 |
Even now, I’m still amazed that we can do this with a 2960. As expected, it’s working. We have two SVIs and we can see the routing table reflect this.
As you can all see, I’m still pretty wowed. There are many scenarios where layer 3 2960s could be useful.
Related Posts:
Connecting Voice Gateways/CME to the PSTN
about 11 months ago - No comments
Today we’ll go over the process to connect an IOS voice gateway/CME (Call Manager Express) to the PSTN. I set this up last night and thought it would be a good post. I’ll briefly touch on using a SIP trunk as backup/failover too.
I’ve been running a SIP trunk to Flowroute for quite awhile, but I just recently got a “landline” from my ISP because they’re doing a promotion where it’s basically free. I’m keeping my SIP trunk, but I’ll be using it as backup since all US calling through the ISP is free. I’m using a 2811 with an NM-HD-2V and a VIC2-4FXO.
First we’ll verify that the card is recognized and working:
EDGE#sEDGE#sh voice port summ
IN OUT
PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC
=============== == ============ ===== ==== ======== ======== ==
1/1/0 -- fxo-ls up dorm idle on-hook y
1/1/1 -- fxo-ls up dorm idle on-hook y
1/1/2 -- fxo-ls up dorm idle on-hook y
1/1/3 -- fxo-ls up dorm idle on-hook y |
Everything looks good there, the router is recognizing the card and its ports. 1/1/0 is connected to the ISP’s MTA.
Now we’ll configure the dial peers:
dial-peer voice 1 pots preference 1 destination-pattern 1[2-9].[1-9]....... incoming called-number .T port 1/1/0 forward-digits all ! dial-peer voice 2 pots preference 1 destination-pattern 1800....... incoming called-number .T port 1/1/0 forward-digits all ! dial-peer voice 3 pots preference 1 destination-pattern 911 incoming called-number .T port 1/1/0 forward-digits all |
We’ve configured three dial peers here. First note that the dial peer type is “pots”, this is used when the destination is an analog port (like FXO). Next you see the “preference” command, lower is better, making these peers more preferred than my SIP peers (with a preference of 2). The “destination-pattern” command is matching the dialed string, sort of like a static route. For the first dial peer, We’re matching 11 digits including the 1, area code (digits 2 through 9, wildcard which matches 0 through 9, and then digits 1 through 9), then seven wildcards matching 0 through 9. This is my convoluted way of blocking 900 numbers. For the incoming call, we’re matching any digits. The “port” command tells the router where to send the call when it matches the patter, port 1/1/0 here. Then we tell the router to forward all digits. This is important because it will strip the explicitly defined digits, which we don’t want here, we want all digits sent to the PSTN.
Next we’ll configure incoming calling, using Private-line Automatic Ringdown (PLAR):
voice-port 1/1/0 connection plar 5001 caller-id enable |
Not much to that one. We go into the port config and use the “connection plar ” command. PLAR tells the router to automatically forward to an extension when the line goes off-hook. So when this port gets an incoming call from the PSTN (which takes it off-hook), it will instantly forward it to extension 5001. We’ve also used the “caller-id enable”, which is pretty self-explanatory; it enables incoming caller-id on this FXO port.
That’s all for this one. This could be the first(ish) of many voice-related posts. I’ll be moving through the voice exams (hopefully quickly) in the next few months and if there is interest, I can try to do some posts on things I’m learning/studying. Real voice (CUCM) can be tough blog about because it’s mostly GUI based, which requires (lots of) screenshots. Making 11ty screenshots for every post could get old quick. Post in the comments if you’d like to see voice topics, and if you have anything specific you’d like to read about.
Disclaimer: I am, by no means, a voice guy (yet?), so if you see any errors please let me know in the comments. I can say that this works, but I wouldn’t doubt if it’s not the “best” way.
Related Posts:
Firewall Object Groups
about 11 months ago - No comments
Dropping in to do a quick post today. Sorry for the ridiculous lack of content lately. I’ve been busy with finding/changing jobs and new responsibilites and all that.
Today I’m going to cover “object groups” on ASAs. I was never a big fan of these, which I realized had a lot to do with using them behind others, not actually writing them myself. It takes awhile (for me, at least) to wrap your head around what the person before you was trying to accomplish. This is what put me off object groups. Though, I discovered that if I write them myself, I love them, lol. They can be hugely useful. They’re even available in IOS now (as of 12.4(20)T). Here’s an example of when they’d be used:
Scenario:
We need to allow several hosts (192.168.1.100-105) to access a group of servers (192.168.2.10-15) on multiple ports (21, 22, 25, 80, 443). Without object groups, this would produce a pretty lenghty ACL. First I’ll do the object group config, then I’ll show what it would look like with normal ACL entries.
object-group network OG_Hosts description host addresses network-object host 192.168.1.100 network-object host 192.168.1.101 network-object host 192.168.1.102 network-object host 192.168.1.103 network-object host 192.168.1.104 network-object host 192.168.1.105 ! object-group network OG_Servers description server addresses network-object host 192.168.2.10 network-object host 192.168.2.11 network-object host 192.168.2.12 network-object host 192.168.2.13 network-object host 192.168.2.14 network-object host 192.168.2.15 ! object-group service OG_Hosts-To-Server-Ports service-object icmp echo service-object icmp echo-reply service-object tcp eq 21 service-object tcp eq 22 service-object tcp eq 25 service-object tcp eq 80 service-object tcp eq 443 |
Pretty simple. We create some object groups matching IPs for the hosts and servers, then we match ICMP traffic and various TCP ports. Notice that there are two object group types used here, the first is “network”. This type allows us to specify IPs and subnets. The second type is “service”. This type allows us to match different ports and protocols.
Now let’s put it together in an ACL:
access-list ACL_Hosts-To-Servers extended permit object-group OG_Hosts-To-Server-Ports object-group OG_Hosts object-group OG_Servers |
Amazingly, we only need one line. We’ve configured an ACL line with three object groups. Notice that the ports actually come first, which threw me a bit when I first saw object groups in actions. Other than that, everything is relatively normal. We need to specify “object-group” before each one, and as usual, it’s source, then destination.
Now let’s look at part of the “show access-list” output. This will show us what the firewall sees and matches, and also what we were saved from typing manually:
Firewall# sh access-list ACL_Hosts-To-Servers access-list ACL_Hosts-To-Servers; 252 elements access-list ACL_Hosts-To-Servers line 1 extended permit object-group OG_Hosts-To-Server-Ports object-group OG_Hosts object-group OG_Servers 0xc08e86b0 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.100 host 192.168.2.10 echo (hitcnt=0) 0xb9c5e5bf access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.101 host 192.168.2.10 echo (hitcnt=0) 0x946345e5 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.102 host 192.168.2.10 echo (hitcnt=0) 0xc233a45f access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.103 host 192.168.2.10 echo (hitcnt=0) 0x509dadab access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.104 host 192.168.2.10 echo (hitcnt=0) 0xfa1dbbd2 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.105 host 192.168.2.10 echo (hitcnt=0) 0xedc7eaea access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.100 host 192.168.2.10 echo-reply (hitcnt=0) 0x77938723 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.101 host 192.168.2.10 echo-reply (hitcnt=0) 0x809068d5 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.102 host 192.168.2.10 echo-reply (hitcnt=0) 0x1730c200 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.103 host 192.168.2.10 echo-reply (hitcnt=0) 0xc555b262 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.104 host 192.168.2.10 echo-reply (hitcnt=0) 0xdd2ca47f access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.105 host 192.168.2.10 echo-reply (hitcnt=0) 0xb5d1bc04 |
I’m not pasting all 252 lines, that would just be a waste of space. You get the idea though, the firewall is showing us what our single ACE actually does. All those rules come from our one line. That’s the power of object groups.
Just a short one today. Again, sorry for the lack of posts. Hopefully I can get back to posting regularly. I hope this all made sense. If you have any questions, please post in the comments.
Related Posts:
- ASA Bridge Groups
- Cisco IOS Firewall Tutorial
- GRE/IPSEC Tutorial
- 2960s Can Route
- Connecting Voice Gateways/CME to the PSTN
Testing link/circuit speed using Iperf
about 1 year ago - 9 comments
Hi all!
It’s Jared from CCNPJourney.com. Colby had asked me a couple weeks ago if I would be interested in posting some articles on his blog as he’s been fairly busy lately, and of course I said yes. So I thought for my introductory post on the blog I would do a brief write-up on how to use Iperf!
For starters here’s a little bit of info on Iperf. Iperf is a tool that many system/network admins use to measure the bandwidth on a network, as well as the quality of the path on that network. It is capable of generating traffic using TCP and UDP. The TCP and UDP tests are useful for performing the following kinds of tests:
- Latency (response time or RTT): can be measured with the Ping utility.
- Jitter: can be measured with an Iperf UDP test.
- Datagram loss: can again, be measured with an Iperf UDP test.
- Bandwidth tests are done using the Iperf TCP tests.
Iperf also allows you to run simultaneous tests, and bi-directional. Developers in the community have also created a GUI for Iperf called Jperf, which is a Java based GUI that allows you to save settings, and more easily make changes to your settings. For information on Iperf head on over to the Wiki page, or their page over at SourceForge.
Now lets get down to business…
Lets start out by downloading Iperf. In this example I will be using the Windows version of Iperf, but feel free to use what you choose, it’s all the same switches regardless of the OS). You will need Iperf on a machine you wish to use for the “client” role, and one for the server”.
Once you have put the files on each machine we can begin. Start out by opening a command prompt and then navigating to the folder you have Iperf stored in. You will then enter the commands below, on the server and client respectively to begin your first basic Iperf test!
Server
Enter the command “iperf.exe -s”, without the quotes, to start Iperf in server mode (indicated by “-s”).??
The screenshot above shows what you will be presented with after you’ve started Iperf in server mode. It shows you the port that was automatically chosen (which can be manually changed), as well as the TCP window size, which again is chosen by default based on the OS, but can be changed.
Client
To start Iperf in client mode (using no arguments) enter the command “iperf.exe -c x.x.x.x”, where “x.x.x.x” equals the IP address of your Iperf server in the above step.

In the screenshot above you can see the final results of a basic Iperf test. Again presenting you with the TCP Window size and port that were chosen by default. You will also see the resulting bandwidth calculation as well as the amount of data transferred during the test.
Option Usage
Here’s a look at the output from entering the “iperf.exe -h” command.
Usage: iperf [-s|-c host] [options]
iperf [-h|--help] [-v|--version]
Client/Server:
-f, --format [kmKM] format to report: Kbits, Mbits, KBytes, MBytes
-i, --interval # seconds between periodic bandwidth reports
-l, --len #[KM] length of buffer to read or write (default 8 KB)
-m, --print_mss print TCP maximum segment size (MTU - TCP/IP header)
-o, --output <filename> output the report or error message to this specified file
-p, --port # server port to listen on/connect to
-u, --udp use UDP rather than TCP
-w, --window #[KM] TCP window size (socket buffer size)
-B, --bind <host> bind to <host>, an interface or multicast address
-C, --compatibility for use with older versions does not sent extra msgs
-M, --mss # set TCP maximum segment size (MTU - 40 bytes)
-N, --nodelay set TCP no delay, disabling Nagle's Algorithm
-V, --IPv6Version Set the domain to IPv6
Server specific:
-s, --server run in server mode
-D, --daemon run the server as a daemon
-R, --remove remove service in win32
Client specific:
-b, --bandwidth #[KM] for UDP, bandwidth to send at in bits/sec
(default 1 Mbit/sec, implies -u)
-c, --client <host> run in client mode, connecting to <host>
-d, --dualtest Do a bidirectional test simultaneously
-n, --num #[KM] number of bytes to transmit (instead of -t)
-r, --tradeoff Do a bidirectional test individually
-t, --time # time in seconds to transmit for (default 10 secs)
-F, --fileinput <name> input the data to be transmitted from a file
-I, --stdin input the data to be transmitted from stdin
-L, --listenport # port to recieve bidirectional tests back on
-P, --parallel # number of parallel client threads to run
-T, --ttl # time-to-live, for multicast (default 1)
Miscellaneous:
-h, --help print this message and quit
-v, --version print version information and quit
[KM] Indicates options that support a K or M suffix for kilo- or mega-
The TCP window size option can be set by the environment variable
TCP_WINDOW_SIZE. Most other options can be set by an environment variable
IPERF_<long option name>, such as IPERF_BANDWIDTH. |
That about sums up this post on Iperf. It’s really a very basic program that can help a lot in day to day troubleshooting. I plan to make another post on how to use Jperf as well, so keep an eye out for that!
Hope you enjoyed!
Related Posts:
- ASA Bridge Groups
- 2960s Can Route
- Connecting Voice Gateways/CME to the PSTN
- Firewall Object Groups
- %C4K_EBM-4-HOSTFLAPPING
%C4K_EBM-4-HOSTFLAPPING
about 1 year ago - 11 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.
Update: I’m including the error %SW_MATM-4-MACFLAP_NOTIF in this post, which is essentially the same issue.
Related Posts:
- ASA Bridge Groups
- 2960s Can Route
- Connecting Voice Gateways/CME to the PSTN
- Firewall Object Groups
- HSRP Tutorial
HSRP Tutorial
about 1 year ago - 12 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:
- OSPF Area Types: NSSA
- OSPF Area Types: Totally Stubby
- OSPF Area Types: Stub
- OSPF Authentication
- Simple IPv6 Tutorial
IOS Macros
about 1 year ago - 7 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:
- BGP Backdoor Lab
- OSPF Summarization
- OSPF Area Types: Not So Totally Stubby
- OSPF Area Types: NSSA
- OSPF Area Types: Totally Stubby
OSPF Summarization
about 1 year 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
- OSPF Area Types: NSSA
- OSPF Area Types: Totally Stubby
- OSPF Area Types: Stub
- OSPF Authentication
OSPF Area Types: Not So Totally Stubby
about 1 year ago - 1 comment
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 Summarization
- OSPF Area Types: NSSA
- OSPF Area Types: Totally Stubby
- OSPF Area Types: Stub
- OSPF Authentication

about 2 years ago
Great article, thanks!
How would you compare the flexibility of the JUNOS command line to the IOS? Being unix based, does it allow multiple piping of output and regex searching? I really wish IOS could get some of that…
about 2 years ago
That’s a good question. My experience with JUNOS is obviously quite limited, but it does seem to have more flexibility than IOS. You have a ton more options when piping outputs, I believe you can use regexes too.
about 2 years ago
What kinda box you working on here? I have been hacking away on an srx240 pair (clustered) here at work. It is a neat adventure, but I will stick with IOS anyday. Good article! Will enjoy seeing the NAT config…..source and destination…..fun
about 2 years ago
This was done on an Olive running in a VM on my ESX box.
I have a J2300 on the way, hopefully I get it before the weekend, but who knows.
about 1 year ago
Thanks for the tutorial, you are my new best friend.
about 1 year ago
Ha, thanks!
Nice blog.
about 1 year ago
What a fantastic article,and the blog theme is so Beautiful,could you tell me where can download this theme.
about 6 months ago
Hi,
The weird thing is after i have installed my olive i can not see the ethernet interfaces em0 and em1 when i execute the show interfaces terse
Is there any idea?
[edit interfaces]
root@koko# run show interfaces terse
Interface Admin Link Proto Local
dsc up up
fxp0 up up
fxp0.20 up up inet 20.1.1.1/30
fxp0.30 up up inet 30.1.1.1/30
fxp0.32767 up up
gre up up
ipip up up
lo0 up up
lo0.0 up up inet 100.1.1.1
lo0.16384 up up inet 127.0.0.1
lo0.16385 up up inet
lsi up up
mtun up up
pimd up up
pime up up
tap up up