Broken Network's Quick and Dirty Guide to Traffic Shaping

This is a very brief look at Generic Traffic Shaping (GTS), Frame Relay Traffic Shaping (FRTS) and Class Based Traffic Shaping. Nothing more, nothing less. You won’t learn the finer points of traffic shaping from this post, but you will see configuration examples of all three so that you’ll know the difference between them when you see them in a config, or if you’re asked to configure a specific type.

Assigning Addresses over PPP using DHCP

This topic is something that seems to kick my ass every time I need to configure it.  For some reason I can easily remember how to set up PPPoE, and I can remember how to dynamically assign addresses to the clients using IPCP without issue.  But for some reason I have a real mental block when it comes to using DHCP instead.  To that end, it’s time to blog it!

Spoofing Source IP's with a Fortigate

Something new for the blog: A Fortinet post! 

I work for a Fortinet partner, and in the last few months I've been doing more and more work with their Fortigate line.  Tonight I just discovered a really handy "feature" that has allowed me to test a change that $Provider made to their routing that I wasn't able to test directly.  Details after the jump.

OSPF NSSA External LSA: Type 7

Still with me?  Good stuff!  We’re almost done.  Last up is the OSPF Type 7 NSSA External LSA.

OSPF External LSA: Type 5

Welcome to the OSPF Type 5 LSA!

The Type 5 LSA is used to advertise routes that are external to the OSPF domain within the OSPF domain (hence the External moniker). There are two types of Type 5 LSA’s: Type 1 and Type 2 (seriously?).  We’ll be looking at both here.

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!