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!

RIP Distribute-lists and the Extended ACL

Here’s a neat trick that’s an easy one to screw up or forget the syntax on.  In RIP (and EIGRP as well I believe) you can use an extended access-list to filter out specific routes advertised by specific neighbours.  This is done using the source and destination fields of the extended ACL to specify source of the routing update, and the route(s) you want to filter respectively.

Example after the jump.

Help Please: PPP Multilink

I'm going to try something a little different for this post.  Usually I take something that I've been labbing that I find interesting, or challenging, and document it for memory retention and your reading enjoyment.  This time I've got a config-let for PPP Multilink that I found quite by accident that I don't know is "right" or not.  It works, so that would mean it's right enough, but I'm hoping that someone out there can point me at some supporting documentation that can clarify what the difference is between this method and what I'll call the more traditional method, and why you would use one over the other.

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.

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!

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 :)

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

Lab Date Booked

I've been rather terrible at updating this thing again...  I'm really a rather terrible blogger aren't I?

Don't answer that.

Well one thing I have been doing is putting the plan into motion, and to that end today I booked a Lab exam date.  Nov. 7 I'll be walking into Cisco in San Jose and finally taking this big bad test.

I have a lot of work to do between now and then.  Let the good times roll :)

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!