OSPF Summary LSA's: Type 3 & 4

And now for everyone’s favourite LSA, the Type 3 LSA!

Combined with everyone’s least favourite LSA, the Type 4 LSA!

OSPF Network LSA: Type 2

Welcome back to my LSA re-review. No need for a long winded intro here. Let’s get at it.

OSPF Router LSA: Type 1

Ahh yes, this is the part of the CCIE studying where I revisit topics that I’ve previously studied before but have since started to forget some of the finer details of. This is where my inability to pass the stupid lab combined with the finite amount of memory capacity I have becomes a pain in the ass and forces me to redo things. This is where I my blogging takes on a morose tone and I start to sound like a whiny little bitch.

OK, not really.

But this is where I am going to look at the six OSPFv2 LSA’s that we care about for the CCIE R&S lab. In detail. Hence the title.

First up; Type 1.

Misleading Virtual Link Status

Fun times in discussing OSPF VIrtual Links tonight.  Here's a quickie for posterity's sake.

R2#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 3.3.3.3 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 23, via interface Serial0/0/0, Cost of using 64
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:06
  Message digest authentication enabled
    Youngest key id is 1

But is it up?  The answer is yes, but nothing is working right now :)

Exploring the Cat3560 System MTU Command

A friend on Facebook asked the the following question in response to my first post on QinQ tagging:

Hey Jay, just curious if you can explain a bit further, but if there are two 802.1q tags, taking up 4 bytes each, should the system MTU be set to 1508? Also, say you have two customers each using VLAN 12 and they both want to be trunked across the service provider network, you would have to use different "access" VLAN's for the QinQ on the the customer facing interfaces, right? Say VLAN 99 for customer 1 and VLAN 100 for customer 2?

If I can answer the second question first, yes, that is absolutely correct.

For the first question though my first inclination was to reply saying that the system mtu command is used to specify the layer 3 payload, not the layer 2 payload (since the default is 1500 bytes).  This line of thought was due to the logic of the L2 MTU being 1518 (1500 plus an 18 byte Ethernet header/trailer) and thinking that switches allow an extra 4 bytes (1522 total) when a Dot 1Q tag is added.

But then I thought about this and the L3 MTU line of thought doesn't add up...  If it's the L3 MTU why are we adjusting it for the extra Dot 1Q tag at layer 2?  And if the system mtu command is for layer 2 then why is it only 1500 (1504 for QinQ) and not 1518, 1522, or even 1526 for a double tagged frame?

Quick!  To the DocCD!! There isn't a moment to lose!

QinQ (inQ) Part 2

In the last post I set up a simple 802.1Q tunnel.  Now I'm going to expand on that and illustrate some of the more advanced Layer 2 Protocol Tunneling that you can do on top of that.

The following is not for the faint of heart.  You will be amazed, you will be confused.  You may cry, and you may jump for joy.  If you choose to go on, you have been warned.

Or something.

QinQ (inQ) Part 1

This week I added 3 x 3560's to my home lab.  I don't feel that overall I'm especially weak on the layer 2 topics, in fact I think quite the opposite is true.  However, access to 3560's for labbing purposes has always been a bit harder for me so I decided to buy three of them out of my own pocket to help with the preparation.  And besides, these are full layer 3 switches so I can also use them to help out with the routing topics as well.

So for anyone counting, that brings my lab to 3 x 1841, 3 x 3560, 1 x 2621xm and 1 x 2621.  I do also have a 2950 and a 3500xl, but those are at my office and I'm not currently using them for labbing. This should be enough for me to lab up any tech that I need to.

Seeing as how the 2560's are new to me I of course wanted to play with something on them that I haven't been able to do on my routers.  By a purely random selection that ended up being QinQ tunneling.

So without further ado here's an actual blog post!

A quick note on capturing 802.1q tags

I've been putting together a forthcoming post on QinQ tunneling and as part of that I wanted to capture some 802.1Q tagged frames with SPAN and Wireshark to display.  I suppose my first mistake was trying to use Windows to do this...  But I was capturing packets with an 802.1Q tag in them, just not the multiple tags I expected of the QinQ frames.  I spent too many hours trying to figure out why it wasn't working the way I wanted it to, ripping apart the SPAN documentation, reading blog posts by bloggers I follow, and naturally, the Wireshark documentation itself.

Because I was seeing one tag I figured my Realtek PCIe GBE Family Controller network adapter must be able to handle tags, but why was it only striping off one tag and not both?

Turns out there is a fix here.  If you go into the device properties from the Device Manager, click on the advanced tab, there's a 'Priority and VLAN" setting.  In there the default was "Priority and VLAN Enabled".  To me I took this to me VLAN tags were enabled, so the NIC would understand tags and I would be able to see them.  This was incorrect.  What you want to do it set it to the disabled setting, and then the NIC will just blindly pass the frame on as is, and not process the tags!  With the setting enabled the NIC was processing the first tag, stripping it, and passing along the rest of the frame with my inner QinQ tag in tact!   Once I disabled this everything worked great and I was now capturing frames with multiple tags.

Stay tuned for the upcoming QinQ post!