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.

Lab Attempt #1

As previously stated I had my first attempt at the CCIE Lab exam on Nov. 7.  I'm sure you've all likely figured out that I did not pass since there hasn't been any fanfare or celebration on my part.  But it was a learning experience and I don't really have any regrets about not being able to pass on the first go. 

During the  boot camp I took the week before Marko Milivojevic told me, and the rest of the class, that we all had a fighting chance of passing.  Well it turns out he was right.  I did have a fighting chance, but that was about it.  For me to have passed on the first go it would have required more luck than skill, and I don't really want this cert if it's because I'm lucky.

So, for those of you interested, here's how my day went.

Living the Dream

At last.  It's time.

Tomorrow I fly out to San Jose. I'm doing a 5 day boot camp next week, and then Monday Nov.7 I'll be attempting the CCIE Lab exam.  The last year and a half is about to culminate in one intensely immersed few days of routing, switching, and general conf t awesomeness.

I'll see you all when I get back.

Jason