Category Archives: Networking

Achievement Unlocked: JNCIA Certification

After having a few Cisco certifications under my belt, I felt it would be wise to start diversifying my skills. When I received a free exam voucher it pushed me to go for it. As far as exam content goes, 65 multiple choice questions with a few multiple choice/multiple answer questions was it. No simulations or interactive questions. I passed with minimal studying. If you do not have your JNCIA certification and you are thinking of going for it, I would recommend taking a shot at it. As long as you have some basic networking skills, can do some binary math, and have used JunOS, you will probably pass. One downside is that it is only valid for 2 years, instead of 3 like Cisco.


IPv6 Subnetting – Practical Uses

The concept of IPv6 subnetting may be intimidating to some, but it really is no different than in IPv4.  In fact, I believe it’s easier!  Sure we are moving from a 32 bit, dotted-decimal address to a 128 bit, coloned-hex address, but the idea is the same: break a network down into a number of smaller segments.  My goal here is to identify real-world use cases so you can see exactly how it applies to real life.

When learning about IPv4 subnetting, no doubt you were given questions like “Company ABC has a /16 network, with 1,000 office locations.  Anticipating 10% growth over the next 10 years, how many networks can be created, and how many hosts will fit in each of those networks?” or something along those lines.  Fortunately, in the IPv6 world, we don’t care about the number of hosts per subnet.  Why not?  Great question!  First we must understand a few differences with IPv6.  First, there are no broadcasts.  Communication destined for multiple nodes utilizes multicast.  Second, the standard IPv6 network is a /64, meaning 64 bits of the 128 bit address are used for the network portion, and 64 bits are used for the host portion.  64 bits allows for 2^64 or 18,446,744,073,709,551,616 hosts!  So basically, unless it’s a point-to-point link, we don’t care how many hosts are in it.  What we do care about, however, is the number of subnets we can create from an address block.

Everyone knows that 8 bits is called a byte, but did you know that 4 bits is called a nibble?  That’s not just useless trivia, but it’s a valuable thing to know when subnetting IPv6 because you will be breaking the addresses up on the nibble boundaries.  More on this later.

The smallest allocation assigned by most registrars is a /48.  A /48 is typically assigned to a “site.”  A site is defined as a single geographic location, which could be a single high-rise office building, or a small campus.  Let’s say you are assigned the following /48 prefix:  2001:db8:1::/48.  Remember, the 48 means the first 48 bits of the address is the network portion, and theoretically, the remaining 80 bits can be used for subnetting.  Practically, though, you don’t really want to allocate smaller than a /64, so that leaves you 16 bits for subnetting.  2^16 is 65,536 which means you can create that many /64 networks from your /48.

Now suppose you want to aggregate these 65,536 networks in smaller chunks.  Here’s where the nibble comes in.  The first nibble boundary in subnetting a /48 exists at /52.  How’d I know that?  Simple, 48 + 4 = 52.  Subnetting at this first nibble boundary allows you to break your /48 into 16  /52 networks.  They will be:

  • 2001:db8:1::/52
  • 2001:db8:1:1000::/52
  • 2001:db8:1:2000::/52
  • 2001:db8:1:f000::/52

That leaves you with 12 bits for subnetting.  2^12 is 4,096, which means your /52 can be broken down into 4,096 /64 networks.  As you can see, it can be very easily determined what network 2001:db8:1:2205:223:6cff:fe93:a3f4 is in.  In a campus environment with a dozen or so routing areas, a /48 can be broken down into 16 /52s, then assign each /52 to a distribution block/OSPF area, and then have a /64 assigned to each VLAN in that area.  You can even number your subnets with the VLAN ID!  If you have VLAN 205 in routing area 2, the 4th coloned-hex portion would be 2205.  This makes it really easy to glance at an address and be able to tell what part of the network it is on.

 Say you want to break your /48 down into more than 16 segments.  The next nibble boundary is at /56 (48 + 4 + 4 = 56).  This gives you 8 bits to use for subnetting.  2^8 is 256.  So your /48 is broken down into 256 /56 networks.
  • 2001:db8:1::/56
  • 2001:db8:1:0100::/56
  • 2001:db8:1:0200::/56
  • 2001:db8:1:ff00::/56
You have 8 bits left for the network portion, so your 256 /56s can each contain 256 /64 networks.  See where I’m going with this?  A /56 subnetting design may be practical for an organization with multiple dozens of locations.
Hopefully this information is useful in your IPv6 subnetting adventure!

So much time wasted for such a stupid problem

Let me preface this by saying that remotely rebooting a router/firewall always has associated risks; however, this one may never cross your mind as I’ve found out the hard way.  Apparently, Juniper does not want you to have a Cisco terminal server (aka reverse telnet) connected to their devices’ console ports.

I had been planning on upgrading from JUNOS 11.4R1.6 to the latest 12.1 release because I’ve noticed some weird/undocumented issues with its DHCP server implementation (to make a long story short, DHCP acknowledgments were taking excessively long to process and send out in response to a request).  After the old “request system software add … reboot” command I sat and patiently waited for the box to come back to life; unfortunately, it never did.

Almost by accident, I stumbled upon Juniper KB17145 entitled “SRX reboot can have problems when console cable is connected to Cisco terminal server.”  My favorite sentence is: “misconfiguration on the Cisco port can cause SRX not to boot properly”

This is how Juniper wants you to configure the Cisco serial port:

line aux 0
  session-timeout 7200
  exec-timeout 0 0
  no exec
  transport preferred none
  transport input all
  stopbits 1

So I applied their recommended configuration, rebooted the SRX, and magically, it booted properly!

Utilize Cisco AUX Port for Reverse Telnet

Since I’m too cheap/poor to buy an asynchronous serial module (NM-16A/NM-32A) for a Cisco terminal server, or an OpenGear console server, I’ve figured out how to configure the AUX port to perform the same function.  Typically the AUX port is used to connect a dial-up modem to the device for dial-in access.  You can identify the line number by running “show line” from the command line:

#show line
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
      0 CTY              -    -      -    -    -      0       0     0/0       -
*     5 AUX   9600/9600  -    -      -    -    -      2       0     0/0       -
*     6 VTY              -    -      -    -    -      5       0     0/0       -
      7 VTY              -    -      -    -    -      0       0     0/0       -
      8 VTY              -    -      -    -    -      0       0     0/0       -
      9 VTY              -    -      -    -    -      0       0     0/0       -
     10 VTY              -    -      -    -    -      0       0     0/0       -

Line(s) not in async mode -or- with no hardware support:

As you can see, the AUX port is showing up as line 5.  This is important.

Next, put some configuration on the AUX port:

line aux 0
 transport input all
 flowcontrol hardware

Now you can either access the line from your device’s console, or from a remote host.  Assuming the device’s IP address is, from a remote host you can telnet to on port 2005 (05 is the two digit line number), enter your credentials to the device, and gain access to the AUX port.  Once attached to the AUX port you have access to the console’s connection.  In this case, it is connected to a Juniper SRX which requires authentication for console access.

$ telnet 2005
Connected to cme.
Escape character is '^]'.

User Access Verification

Username: eric

ROUTER (ttyu0)

login: eric

--- JUNOS 11.1R2.3 built 2011-05-06 05:59:38 UTC
[email protected]>

15 Days of Hell Pays Off

Well it’s been a long two weeks but it’s finally over!  Goodbye Plano, TX!  Hello CCNP certification!  I’ve successfully passed all three exams (ROUTE 642-902, SWITCH 642-813, and TSHOOT 642-832) and now plan to study for my CCIE.