BGP Conditionally Injected Loops

While writing up the previous post on BGP Conditional Route Injection I got an idea while I was verifying the information in the post. I thought I saw a way for a loop to form in that the injected route would be learned by a router making it send traffic in the wrong direction.

It turns out I was right.

BGP Conditional Route Injection

This is one of those “complicated” configs. There’s a bunch of typing involved, and the syntax need to be just so.  I labbed this up tonight and it didn’t work. I proceeded to stare at my config for the next 30 minutes before I saw my error. This, my friend, is how you fail the TS section. So in the hopes that I don’t pull the same stunt with this feature come Lab day you folks are now treated to another blog post!

VTP Transparent Mode Relay Caveat

As I get my fingers back in shape for the Lab I figured a little VTP practice tonight was in order.  VTP is fairly straightforward, so I wasn't expecting anything unusual when I started in on a little bit of config with a transparent VTP switch...

I've previously run under the assumption that a VTP transparent switch will relay VTP frames as long as it is in the same domain as the VTP frame it receives.  If there's a mismatch then the frame is discarded.  Well, this is still true, but there's a third scenario that I hadn't ever really considered before: the domain is set to NULL.

MPLS and the Next Hop

This week I discovered that in all my labbing it would seem that I have never tried to run L3VPN MPLS over a Frame Relay hub and spoke configuration using OSPF and the provider IGP with a broadcast network type.  The reason that I know I’ve never done this before is because it just doesn’t work.  This seems like a sneaky little scenario for a TS task so here’s what things look like should you ever encounter it.

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!

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...

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. 

IPexpert IOU Topology

IOU has been leaked.  L2IOU has been leaked. It was only a matter of time before someone did this...  Might as well be me :)

Here's a NETMAP file that recreates the IPexpert CCIE R&S topology, and a wrapper script to start it. And as my special gift, a bash script to convert the config files provided by IPexpert to a format that (L2)IOU can work with.

I might do up some diagrams at some point, but for now you'll have to figure it out from these text files. 

Enjoy!

IP Subnet-Zero

I thought it would be interesting to take a little stroll through history and look at something that really isn't relevant to today's network, but was something that you weren't allowed to use in days gone by.  As the blog title says, that something is IP Subnet-Zero.

ZER0 ZER0 ZER0 ZER0

What is IP Subnet Zero?  Well, it's a legacy command on Cisco routers the controls whether or not the use of the all zeros subnet is permitted.  What's the all zeros subnet?  To properly understand what the all zeros subnet is we need to first remember what classful networking was, and how things all got started in IP beginning with RFC 791. 

ZER0 ZER0 ZER0 ZER0

IOU Lab Topology #2

As I mentioned in my first IOU topology post I more frequently use another topology that has turned out to be better suited for my labbing needs than my first attempt.  Well, here is that topology.

IOU Lab Topology #1

Some time ago Cisco's IOU was leaked out to the web.  I was able to get a copy (don't ask where, I won't help you) and have managed to get it set up on a spare box at home.  There are a couple of really good tutorials on the Web that explain how to get it set up and working and how to build a lab topology.  I've built two topologies so far that I use to lab things up when needed, and I'd like to share the first with you now.

Lock-and-Key Security (Or how I learned to love the Dynamic ACL)

After a great February of blogs (for me anyway) I didn't manage to get a single post out in March.  Oddly enough March turned out to be a new record for pageviews...  Weird eh?

At any rate, I did do up another guest blog post for Steve on Networking-Forum.com on Lock-and-Key security..  If you're interested I encourage you to head on over and check it out.


http://www.networking-forum.com/blog/?p=2108

I hope you enjoy it.

IPv6 Will Make You Think Differently: We Don't Need No Stinking FHRP

I got into a discussion about the availability of HSRP for IPv6 being in higher end Cisco platforms but not the lower ones.  I didn't think too much of the question when first saw it, but in reading up on IPv6 last night I came across some of the details in Neighbour Discovery that I thought might be a good replacement.  Deep within RFC 2461 lies section 6.3.6:

6.3.6.  Default Router Selection

   The algorithm for selecting a router depends in part on whether or
   not a router is known to be reachable.  The exact details of how a
   node keeps track of a neighbor's reachability state are covered in
   Section 7.3.  The algorithm for selecting a default router is invoked
   during next-hop determination when no Destination Cache entry exists
   for an off-link destination or when communication through an existing
   router appears to be failing.  Under normal conditions, a router
   would be selected the first time traffic is sent to a destination,

   with subsequent traffic for that destination using the same router as
   indicated in the Destination Cache modulo any changes to the
   Destination Cache caused by Redirect messages.

   The policy for selecting routers from the Default Router List is as
   follows:

     1) Routers that are reachable or probably reachable (i.e., in any
        state other than INCOMPLETE) SHOULD be preferred over routers
        whose reachability is unknown or suspect (i.e., in the
        INCOMPLETE state, or for which no Neighbor Cache entry exists).
        An implementation may choose to always return the same router or
        cycle through the router list in a round-robin fashion as long
        as it always returns a reachable or a probably reachable router
        when one is available.

     2) When no routers on the list are known to be reachable or
        probably reachable, routers SHOULD be selected in a round-robin
        fashion, so that subsequent requests for a default router do not
        return the same router until all other routers have been
        selected.

        Cycling through the router list in this case ensures that all
        available routers are actively probed by the Neighbor
        Unreachability Detection algorithm.  A request for a default
        router is made in conjunction with the sending of a packet to a
        router, and the selected router will be probed for reachability
        as a side effect.

     3) If the Default Router List is empty, assume that all
        destinations are on-link as specified in Section 5.2.

Let's take a look at how we can use this to our advantage.

What the Heck is EIGRP Named Configuration?

While doing some MPLS labbing this week I came across something that I'd never seen before.  I decided that I wanted to use EIGRP as my PE-CE routing protocol, and I was using one router to simulate 4 CE's.  My line of thinking was that I'd just create four VRFs and it'd be no problem.  For some reason it never occurred to me that I could use 4 separate EIGRP instances in my config...  I instead just assumed that I could do a VRF aware EIGRP config without any trouble.  Well, I was wrong.  At least I was wrong in the way I originally tried to get it working.  So after a 'no router eigrp 1' I headed over to the DocCD and found me some EIGRP Named Configuration.

How IOS Cheats When Using the Network Command

When you type a command into the IOS CLI you normally expect IOS to execute your instruction as typed.  You don't expect IOS to modify what you typed, or to assume you meant something other than what you actually typed in.  In fact, to me that behavior is extremely undesirable.  I understand there are some assumed defaults where if you omit certain keywords then IOS imposes on for you.  That's fine.  But sometimes IOS changes what you typed in to something completely different.  The network command contains one such example.

Book Review: CCIE Routing and Switching Certification Guide 4th Edition

As part of studying for the CCIE R&S Written exam I got myself a copy of the CCIE Routing and Switching Certification Guide 4th edition by Wendell Odom, Rus Healy, and Denise Donahue.  This is the newly revised version for the CCIE R&S v4 written exam that came out very shortly after the new version of the exams did, and it's also the updated version of a book that's been around for a very long time.

I used this book extensively in my written exam preparation, and now that that piece is completed, I wanted to briefly reflect on this text and the role it played.  It was certainly a love/hate experience, and if you are considering this text in your own studies then you should definitely be aware of a few things prior to purchasing this book.