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!

So here's my token "back in the saddle" blog post.

I've been doing anything other than studying lately.  Since my last attempt in May I've been rather demoralized, mostly exhausted, and utterly disinterested in looking at anything that remotely resembles the CCIE R&S lab exam.

I suppose failing the thing four times will have that effect on a person.

But enough screwing around.  I need to get this finished and move on with my life.

I have done a fair amount of thinking about this whole ordeal to date and I think I can see a few things that I should have done differently.  First, I should not have taken the lab four times already. The first time I really wasn't ready, but it was the first time and you have to get it over with and see where you are at some point.  I don't regret the first time, but the second I went back far too soon.  I got it in my head that I didn't really miss the first time by much and that I could have passed, but that really was not the case.  The third time I did pass config, but still no love.  It was close, the closest I've come to passing, so I don't feel too bad about that one, but number four was the same knee-jerk "I can do it!" reaction that two was, and again I went back far too soon.

That's four attempts total, in a little over 5 months.  Way too close together, and far too much me deluding myself about my abilities.

That's enough with the self loathing though.  Shit happens, and I am truly thankful for both a very understanding employer (who is footing the bill), and a supportive wife who hasn't yet reached the point where she wants her husband back (don't say it...).

The plan going forward is to take the next couple months to start over, and look at everything from the ground up. No rushing into a new date, and no delusions about my skill level. Time to take a good look at where my skills are, and ensure that the next time is the last. 

So here's my token "back in the saddle" blog post.  I hope you've enjoyed it. You can also count on more content rich, awe inspiring, witty technical writing that you've come to know and love from me.  Lots more.  Because you, the fan, deserve only the best :)

Crashing The Nexus

I had an interesting day yesterday.  I hit my first bug in Nexus, and it crashed the whole box.  As this happened first thing in the morning I got to spend the rest of the day cleaning up the mess. 

This happened on a 5596UP running 5.1(3)N1(1a)

If you have a config like this:

port-profile type ethernet iSCSI
  switchport mode access
  spanning-tree port type edge trunk
  spanning-tree bpduguard enable
  switchport access vlan 9
  state enabled

port-profile type port-channel Converged
  switchport mode trunk
  switchport trunk allowed vlan 4-5, 11
  switchport trunk native vlan 1000
  spanning-tree port type edge trunk
  spanning-tree bpduguard enable
  state enabled
 
interface port-channel17
  inherit port-profile Converged
  speed 10000
  vpc 17

interface Ethernet1/17
  switchport mode trunk
  switchport trunk native vlan 1000
  switchport trunk allowed vlan 4-5,11
  channel-group 17 mode active

Whatever you do, DO NOT DO THIS:

Nexus5K# en
Nexus5K# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Nexus5K(config)# int e1/17
Nexus5K(config-if)# inherit port-profile iSCSI

Upon trying to apply the new port profile before either removing the old one, or removing the phsycial interface from the port-channel the management session locked up, and after about 5 minutes a message came up saying the port profile manager process had crashed, and then the "System is going down for REBOOT now!" message.

TAC came back and said I'd hit this bug, but with a trigger not mentioned.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCty05702

Good times...

Frame Relay Pseudo Broadcasts -- The IRC Explanation

You can all blame Jeremy Gaddis for this being a Blog post. Taken from #cciestudy on irc.freenode.net.

19:04 < system5> jdsilva: you talking about my question as to whether psudo-broadcasting is
                 done as part of the routing protocol code or as part of the frame relay
                 implementation code?
19:05 < jdsilva> I don't know...  I didn't read any of the wall of text from you in my window
19:05 < jdsilva> was Pandom asking somethign related to a question you asked?
19:05 < system5> jdsilva: nope, two unrelated questions
19:05 < jdsilva> ok
19:06 < jdsilva> I was responding to Pandom
19:06 < system5> jdsilva: mine is a frame relay question I'm researching, his was about P2p
                 links
19:06 < jdsilva> I just sat down, and it was the latest thing I saw
19:07 < system5> jdsilva: the whole frame relay "pseudo broadcast" thing for routing updates
                 isn't something I really understand at the low level yet as in I don't
                 understand all the low level pieces of how it works
19:07 < jdsilva> there isn't a lot to it
19:07 < system5> I know that it does work and how to configure it, but I don't understand the
                 how or why it works
19:07 < jdsilva> the same frame is sent out every DLCI
19:07 < jdsilva> esy
19:07 < jdsilva> easy
19:08 < system5> jdsilva: it would need to look at the subnets and inverse arp though right? to
                 decide which DLCI's to forward out to?
19:08 < jdsilva> frame is at layer 2, it doesn't care about subnets
19:09 < jdsilva> it's operating on that multipoint interface, be it the physical, or a
                 subinterface
19:09 < system5> jdsilva: and which part of the router manages the pseudo broadcasting? does
                 the routing protocol pseudo broadcast to make up for an inadequacy in frame
                 relay? or does frame relay pseudobroadcast to trick the routing protocol?
19:09 < jdsilva> again, a routing protocol is up in layer 3
19:09 < jdsilva> totally irrelevant
19:10 < system5> ok so frame relay does the pseudo broadcasting to trick the routing protocol,
                 got it, because FR is in L2 and the IGP is in L3
19:10 < jdsilva> not just the routing protocol
19:10 < jdsilva> ok, go back to a blank slate for a second
19:10 < jdsilva> just you, floating in nothingness
19:10 < jdsilva> no frame, no routing protocols
19:10 < jdsilva> :P
19:10 < system5> jdsilva: k
19:11 < jdsilva> ok, add back in frame relay, but ONLY frame relay
19:11 < system5> k
19:11 < jdsilva> no layer 3 nonsense
19:11 < jdsilva> you have a multipoint frame relay interface
19:11 < system5> now all that matters is the DLCI because it's the L2 address, like mac address
                 is for ethernet :-)
19:11 < jdsilva> it's frame relay becuase it's set to encapsulate exiting frame with headers as
                 defined by the frame relay forum
19:12 < jdsilva> yes, for the most part that's correct
19:12 < jdsilva> they do work very differently, but that's not really important here
19:12 < jdsilva> also for right now there's no inverse arp
19:12 < jdsilva> so only static frame mappings
19:13 < jdsilva> so we have a multipoint interface that knows to get to 1.1.1.1 send out dlci
                 1, and to get to 2.2.2.2 send out dlci 2
19:13 < jdsilva> (to keep it simple)
19:13 < system5> k
19:14 < jdsilva> so, now a packet is dispatched to the interface from the routing processor in
                 the router
19:14 < jdsilva> so all "routing" is now down
19:14 < Pandom> I get up to make a coffee and bam. One sec.
19:14 < jdsilva> or whatever process occurred to get the packet to the interface
19:14 < system5> Pandom: dude you are interrupting his awesome frame relay explanation
19:14 < jdsilva> it's irrelevant
19:15 < jdsilva> the interface receives the packet, and sees that the destination is a broadcat
                 address
19:15 < jdsilva> or a multicasst, or whatever
19:15 < jdsilva> it needs to go to more than one place
19:15 < jdsilva> that's really all it sees, it needs to go to more than one place
19:15 < jdsilva> so it makes copies of the packet
19:16 < jdsilva> it makes one copy for each dlci configured with pseudo broadcast enabled, as
                 defined in the frame maps
19:16 < jdsilva> so in our case, it makes two copies: for dlci 1 and dlci 2
19:16 < jdsilva> it then encapsulates both packets, one with a dst dlci of 1, and one with a
                 dst dlci or 2
19:17 < jdsilva> (that's not reaaly right, but it's good enough for now)
19:17 < jdsilva> and then it sends the two frames, one at a time
19:17 < jdsilva> two layer 2 unicasts
19:17 < jdsilva> to each dlci
19:18 < jdsilva> the layer 3 headers will still have the layer 3 multicast dst in the hedes
19:18 < jdsilva> but since there's no such thing as a broadcast or multicast in Frame it can't
                 send one
19:18 < jdsilva> so it sends one unicast for each dlci, to simulate a broadcast
19:18 < jdsilva> done
19:18 < jdsilva> life goes on

The New (Old?) CCIE R&S Lab Blueprint

So I'm hanging out in #cciestudy on irc.freenode.net (yes, you should come on by and get nerdy with us!) and the discussion turned to whether dot1q tunneling was on the blueprint.  I whipped out the printed copy I have on my desk and sure as heck, there is was: item 1.2.36.  However, it would appear that there is an "updated" version of the blueprint on Cisco's website that not only doesn't explicitly have dot1q tunneling on it, but it's 4 pages shorter than the copy I have!

Here's what is on Cisco's site right now:

http://www.box.com/shared/8a58de4ad249a23c2acd

The weird thing is this "new" version is dated 2009.

And here is the copy I have been working from for some time now:

http://www.box.com/shared/5a85f149952b99a67d01

This "old" version is dated 2010 and is a full 4 pages longer.

Now I realize it's just a blueprint, but WTF Cisco?  You don't have to be so brief about the exam topics.  It's hard enough, at least let people know what they should be studying.

The Ridiculously Long and Complicated BGP Command 'neighbor local-as'

Few commands in IOS are as seemingly long and as confusing to me as what the BGP command 'neighbor local-as' command can be.  This command can extend a further 3 more keywords that each change the behavior quite a bit.  I've studied this before, and I always think I have it down, then after some time I come back to it and sit there staring at my screen with a stupid look on my face and a little bit of drool coming out the corner of my mouth while I re-learn it again.  Here's to hoping that a little blog action finally once and for all gets this one into my head.

DHCP Based Security Part 3: Dynamic ARP Inspection

This post closes out a 3 post series on DHCP based security technologies for the Cat3560 (among others) switching platform.  We first took a look at DHCP Snooping, and then we built upon that with IP Source Guard.  Finally, we've come to Dynamic ARP Inspection, or just DAI.

DHCP Based Security Part 2: IP Source Guard

This is post two in a three post series on DHCP based switching security technologies.  Previously I looked at DHCP Snooping, and now I'm going to look at IP Source Guard.

DHCP Based Security Part 1: DHCP Snooping

There's 3 related switching security technologies for which I've had draft posts sitting around for some time now. I'm finally getting around to publishing them as I study away for my second lab attempt. I know it's the silly little technologies like these ones that can show up on a Lab and cause grief, so hopefully I don't forget all this come Jan 13th.

The first one we're going to look at is DHCP Snooping. 

Simple IPv6 Multicast Configuration

IPv6 Multicasting is something that's been confusing me a bit lately.  I think I finally have the basics figured out...  And I'm going to put there here so that you can read all about it.  Because you want to read all about it. Don't you?

I thought so.