Author: ccie14023

Tac Tales #1: Case routing

Before I worked at TAC, I was pretty careless about how I filled in a TAC case online. For example, when I had to select the technology I was dealing with in the drop-down menu, if I didn’t see exactly what I had then I would go ahead and pick something at random and figure TAC would sort it out. And then I would get frustrated when I didn’t get an answer on my case for hours. Working in TAC showed me why. When you open a TAC case, and you pick a particular technology, your choice determines into which queue the case is routed. For example, if you pick Catalyst 6500, the case ends up in a queue which is being monitored by engineers who are experts on that platform. Under TAC rules (assuming it is a priority 3 case) the engineers have 20 minutes to pick up the case. If they don’t, it turns blue in their display and their duty manager starts asking questions. (In high touch TAC where I worked, we didn’t have too many blue cases, but in backbone TAC it wasn’t uncommon to see a ton of blue and even black (> 1hr) cases sitting in a busy queue.) If the customer categorized his case wrong, this meant it was sitting in the wrong queue. Now an engineer had to notice his case,...

Read More

Juniper’s mysterious inet.3 table

When I first started configuring MPLS on Juniper routers, I came across the strange and mysterious inet.3 table.  What could it possibly be?  When I worked in Cisco TAC I handled hundreds of MPLS VPN cases, but I never had encountered anything quite like inet.3 in IOS land.  As I researched inet.3 I found the documentation was sparse and confusing, so when I finally came to understand its purpose I decided to create a clear explanation for those who are searching in vain.  I will focus on the basics of how inet.3 works, leaving details of its use for later posts. For this lab I will use my standard MPLS topology, which I am borrowing from the excellent book This Week:  Deploying MPLS from my employer, Juniper networks, with some slight modifications.  For this example, I have already configured an IGP (ISIS) between the core routers, as well as MPLS and RSVP. We begin with no label switched paths (LSPs) on R2 at all: root@r2> show mpls lsp   Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0   Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0   Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 12345678910 root@r2> show mpls lsp Ingress LSP: 0 sessionsTotal 0 displayed, Up 0, Down 0 Egress LSP: 0 sessionsTotal 0 displayed, Up 0, Down 0 Transit LSP: 0...

Read More

IS-IS Levels and Adjacencies

In this post, we’ll be looking at IS-IS inter-area concepts, and hopefully clearing up some of the confusion ISIS areas create in the minds of engineers who are used to OSPF.  ISIS handles areas quite differently from OSPF, and if you think about ISIS areas in OSPF terms you are likely to be confused by some of this behavior.  The good news is that if you configure area numbers and enable ISIS, it should just work, but if you want to do anything more complex you will need a deeper understanding of how ISIS areas work.  I’ll assume you know the basics of ISIS, for example that it is not an IP native protocol, and just focus on the areas for now.  My intention here is not to go into all of the details of ISIS inter-area operation, but to help you sort out the basics in your mind so you can dive deeper in your studies. All output will be from Juniper routers, but should be self-explanatory enough for those of you using a different platform. When studying ISIS, you will typically come across an area diagram that looks like this: And as an OSPF engineer, you will typically think the following: Great!  The middle area (area 1) with the two L2 routers is like area 0.  The L1/L2 routers are the ABRs, which appear only on area...

Read More

Welcome!

This is my first post on this blog which I created some time ago and have left dormant.  Give that there are about twice as many blogs as people, it would seem best to start out with a statement of my purpose and intent. Before that, a little background:  I currently work for Juniper Networks, although I don’t claim to speak for them.  I am responsible for network architecture within IT, which gives a unique perspective since I am both a customer and a vendor.  I’ve been working in this industry for over 15 years, although my history with computers goes back farther than that.  I hold dual CCIE certifications in Routing/Switching and Security, and an M.S. in Telecommunications Management.  Non-technical credentials:  I hold an FAA Private Pilot’s certificate, I have studied and taught Ancient Greek and Latin. My hope is to provide several types of articles here.   I specialize in communicating technical concepts in simple and direct language, so I will be breaking down difficult technical subjects for my readers, focusing particularly on subjects that frustrate me.  (Don’t get me started on MSTP).  I will also provide frank commentary on the industry, its trends, and on training and certification.  I will also augment this with stories from my years as a network engineer that hopefully will keep things entertaining.  Finally I hope my language and humanities experience...

Read More