packetqueue.net

Musings on computer stuff, and things... and other stuff.

Apple

iTunes Home Sharing

Read­ing Time: 3 min­utes

iTunes Home Sharing

A decent into the hell of Bon­jour and black tur­tle-necks

This is just anoth­er short exam­ple in what I’m expect­ing will be a recur­ring theme here on Pack­et Queue: atten­tion to detail.  As a net­work engi­neer, as in so many pro­fes­sions, pay­ing atten­tion to the lit­tle things can mean the dif­fer­ence between 10 min­utes of trou­bleshoot­ing and 3 days of unmit­i­gat­ed, sleep-deprived hell.  Luck­i­ly enough for me, the exam­ple I’m about to give wasn’t 3 days by any means, and since it was per­son­al and not busi­ness the urgency wasn’t the same as if a WAN link had failed.  That said, I want­ed it fixed.

My wife just bought a new computer—her first Mac since the original—and dur­ing the ini­tial mov­ing of files and such, I dis­cov­ered a nifty fea­ture of iTunes: Home Shar­ing.  Now, I have a large iTunes library at home already—something on the order of almost 180 Gigabytes—and want­ed her to be able to share that library on her new Mac.  After all, we’re not pirates; we just want to have access to our shared music library on any com­put­er or device in the house rel­a­tive­ly seam­less­ly.  So I read a quick lit­tle blurb on the how-tos and why-fores of home shar­ing (real men some­times read direc­tions) and turned it on.  Aside from the crick­ets, noth­ing hap­pened.  Sacre­bleu!

Bonjour?

Bon­jour! ¡No Hablo!

No, not a greet­ing but a name giv­en by Apple to their zero­conf imple­men­ta­tion that allows devices (print­ers, stor­age, shares, etc.) to auto-mag­i­cal­ly find one anoth­er.  This is the ser­vice that was sup­posed to make my iTunes library share­able between com­put­ers.  This is the ser­vice that was sup­posed to make every­thing in my dull world shiny again.  Not being over­ly steeped in the Apple world, how­ev­er, has made me nat­u­ral­ly sus­pi­cious of any­thing that “just works” as more often than not, said thing only “just works” if you “just use it in this one way”.  That nat­ur­al sus­pi­cion of mine was proven to be well-found­ed.

Upon read­ing up on Bon­jour, I dis­cov­ered that it uses mDNS (mul­ti­cast DNS) to find ser­vices.  Well, I thought, that would mean that mul­ti­cast rout­ing should work to fix my woes and I set off to work my mag­ic.  Of course, I had missed a crit­i­cal detail that would have saved me some time: the mul­ti­cast DNS imple­men­ta­tion that forms a part of Bon­jour uses the mul­ti­cast group address of 224.0.0.251.  If you haven’t noticed the prob­lem yet, nei­ther did I right away.  Had I noticed said prob­lem, I wouldn’t have com­plete­ly recon­fig­ured my ASA and 2811 for mul­ti­cast rout­ing, and I wouldn’t have start­ed trac­ing pack­ets with Wire­Shark:

The Mul­ti­cast range runs from 224.0.0.0 through 239.255.255.255 as every first-year net­work­ing stu­dent prob­a­bly knows.  But that range is like all oth­er ranges and has cer­tain reserved address­es with­in it.  In our case, the most inter­est­ing range is 224.0.0.0/24 which is known as the Local Net­work Con­trol Block, or some­times just Link-local.  Address­es in this range include the OSPF address­es of 224.0.0.5 and .6, and RIPv2 address of 224.0.0.9, among oth­ers. The salient detail being that these mul­ti­cast address­es are typ­i­cal­ly sourced with a TTL of 1 and are not to be sent off of the broad­cast domain in which they orig­i­nate.

My wire­less net­work, which my wife’s new Mac is on, is a dif­fer­ent VLAN (and hence, dif­fer­ent broad­cast domain) from my wired net­work.  In fact, between my three wire­less net­works and mul­ti­ple lab net­works, my home envi­ron­ment prob­a­bly has some­thing on the order of 25 dif­fer­ent broad­cast domains.  Def­i­nite­ly not the norm for the aver­age user, but also not uncom­mon if you start look­ing at more tech­ni­cal peo­ple or pro­duc­tion envi­ron­ments.  So, the bot­tom line is that Bon­jour and iTunes won’t work in my envi­ron­ment with­out an mDNS proxy or some oth­er trick­ery.

What both­ers me most about this rev­e­la­tion is that a lot of Apple’s soft­ware and periph­er­als work on this same sys­tem.  Air­port (Apple’s wire­less) as well as their print­er set­up, shares, etc. all work using Bon­jour so are, from at least a sim­ple view­point, bro­ken across broad­cast domains.  I’m guess­ing from Google search­es and such that it’s a minor­i­ty of users of iTunes who are con­cerned about this, and so it may not even make sense for Apple to address the prob­lem.  But if you extrap­o­late that out to every­thing else using Bon­jour, and con­sid­er a cor­po­rate net­work envi­ron­ment, I have to won­der how much of this con­tributes to Apple’s lack of pen­e­tra­tion into enter­prise net­works.

As always, if I’ve got­ten details wrong or you’d just like to offer your own opin­ion back and fur­ther the dis­cus­sion, I can be reached here on this blog or via @someclown on Twit­ter.

Share

Fail

Things I Hate, Episode 1

Read­ing Time: 3 min­utes

Things I Hate, Episode 1

Brought to you by the Imped­i­ment-to-Sales Sales depart­ment

It was not long ago that I was sit­ting across a con­fer­ence room table from our [insert large soft­ware ven­dor of choice here] expect­ing to have a con­ver­sa­tion about the fea­tures and ben­e­fits of upgrad­ing one of our major soft­ware pack­ages to the newest ver­sion.  This was our inter­nal mail sys­tem, and as we had quite a few inter­con­nect­ed sys­tems and sites, along with what we already knew of the major archi­tec­tur­al changes in the new ver­sion, we knew the upgrade would­n’t be easy.  So, we acqui­esced to our sales­per­son­’s requests and set up the meet­ing.  That was our first mis­take.

After the req­ui­site ini­tial pleas­antries were exchanged, we began dis­cussing the prod­uct in ques­tion.  We weren’t sold just yet on actu­al­ly doing the upgrade, so one of the first ques­tions we want­ed answered was basi­cal­ly just a sim­ple “Why do we want to upgrade?”  In oth­er words, we already have a work­ing sys­tem, so what does this newest ver­sion bring to the table vis-a-vis new fea­tures, ben­e­fits, man­age­abil­i­ty, etc.  Ask­ing this question–and expect­ing a clear, use­ful answer–turned out to be not only an exer­cise in futil­i­ty, but also mis­take num­ber two.

“It allows you to cre­ate pock­ets of col­lab­o­ra­tion by lever­ag­ing out-of-the-box, par­a­digm-shift­ing, syn­er­gies of strate­gic plan­ning.”

But what does it do?

“The new ver­sion bet­ter lever­ages ver­ti­cal inter­est seg­ments in a tran­si­to­ry user base, which rep­re­sents a shift­ing par­a­digm in strat­e­gy-focused mind-share and thought-lead­er­ship.”

The con­ver­sa­tion went on like that for a bit before we final­ly decid­ed to cut our loss­es and move on to some oth­er top­ics around our upcom­ing license renew­al, etc.  As it turns out, sub­stan­tial pock­ets of the sales-force at cer­tain large soft­ware ven­dors seem to be trained in a lan­guage that sounds a lot like Eng­lish, uses a lot of inter­est­ing words strung togeth­er in fair­ly obscure pat­terns, and in the end almost exact­ly fails to com­mu­ni­cate any­thing at all use­ful.  The unfor­tu­nate thing is that this was sup­pos­ed­ly the expert in the prod­uct line who could answer our questions–he was brought along to the meet­ing specif­i­cal­ly to speak “engi­neer-to-engi­neer.”

Now, I am not only a net­work engi­neer but also the IT Direc­tor for a mul­ti-nation­al man­u­fac­tur­ing firm.  I am used to strad­dling the line between engi­neer­ing and man­age­ment, and actu­al­ly pride myself on being able to com­mu­ni­cate com­plex engi­neer­ing prin­ci­ples to c‑level exec­u­tives in a way that makes sense, and accom­plish­es some­thing.  I don’t think that I’m so far gone on the engi­neer­ing side that I have to have a team of PhDs come in every time I want to learn about a prod­uct.  That said, I do expect that my time will be respect­ed and when I want to know what your prod­uct has to offer that you will take the rad­i­cal step as a ven­dor of bring­ing along some­one who knows what the hell they’re talk­ing about.

The moral of the sto­ry is that we did not then, nor have we since, upgrade to that new prod­uct ver­sion.  Not out of spite or any bad feel­ings for the ven­dor as a whole, but sim­ply because we final­ly found the answers we need­ed from a com­bi­na­tion of white papers and some peer groups with whom we main­tain rela­tion­ships with.  For you ven­dors who can’t seem to artic­u­late what your prod­uct actu­al­ly does with­out using a hodge-podge of terms poached from a buzz-word bin­go card, my gen­er­al gut reac­tion is that your prod­uct is prob­a­bly not unique or help­ful in any mean­ing­ful way–and that is not the first impres­sion you as a ven­dor or sales­per­son want to make.  I sus­pect I am not alone in that feel­ing, either.

Share

Uncategorized

Vacation is over. Now get y’er ass back to work

Read­ing Time: 1 minute

Well, it’s over.

Vaca­tions always seem way too short.  All of the months of plan­ning, dream­ing, work­ing out the lit­tle myr­i­ad details: then, 10 days in Cozumel and South­ern Cal­i­for­nia and it’s done.

C’est la vie.

That does, how­ev­er, mean that it is right about time for me to final­ly post some­thing use­ful here.  To that end, look for my new post­ing on rebuild­ing access to your ESX Host Serv­er after you bun­gle a Cis­co Nexus 1000v migra­tion.  Not that I would know any­thing about that.  *Ahem*

Some­times the best lessons are the ones we teach our­selves.  Often inad­ver­tent and unpleas­ant, yes, but the most long last­ing.

Share

ASA

Back from China

Read­ing Time: 4 min­utes

Back from China

After rough­ly one week in Shang­hai, Chi­na to set up a new site on our cor­po­rate net­work, it is painful­ly appar­ent that I need to get back into this writ­ing busi­ness.  The dates on my posts belie my weak attempts at cov­er­ing up my lazi­ness.  That said, there were at least a cou­ple of things of note worth using up a few words on.

Note One (where it real­ly is some­one else’s fault)

Due to an unfor­tu­nate series of poor deci­sions, poor project man­age­ment, and a quite sud­den and unrea­son­able expec­ta­tion of deliv­ery dates, we [IT] were forced to poach some band­width from a sis­ter com­pa­ny of ours who had a slight excess in the man­u­fac­tur­ing facil­i­ty where our new office was to be set up.  By slight, I mean exact­ly 256kb.  For those of you not accus­tomed to see­ing the abbre­vi­a­tion for kilo, well, you’re too young.  More on that in a moment.

All of that aside, we engi­neered the cir­cuit all the way from the provider’s edge in Shang­hai, back to our facil­i­ties on the West Coast and ver­i­fied traf­fic was flow­ing.  Once we got to Shang­hai and hooked up our router and start­ed build­ing out the net­work behind it, we noticed that we could­n’t move any traf­fic at all.  With a quick extend­ed ping using the inside net­work inter­face as the source, as well as some trace-routes from oth­er places, we ver­i­fied that the provider had neglect­ed to put a route in the BGP tables for the new net­work.  Thank God for 24-hour NOC sup­port, and with­in 30 min­utes that prob­lem was resolved.

Note Two (where the author tries to check the turn-sig­nal flu­id)

As we moved on to cre­at­ing and join­ing up a shiny new R2 Read-only Domain Con­troller (RODC) every­thing went off the rails.  Time­outs galore.  DNS would­n’t resolve quick­ly enough to allow the new DC to join the for­est.  Off I go on a jol­ly search for default time­out set­tings, reg­istry tweaks, offline meth­ods to install a DC (ugly at best) and gen­er­al­ly going fur­ther down the rab­bit hole of com­plex­i­ty, even going so far as to direct anoth­er engi­neer work­ing for me to prep for a call to Microsoft (nev­er fun.)

Hav­ing already racked a lot of gear, we decid­ed to call it a night and come back fresh in the morn­ing.  I always find it help­ful to con­tem­plate prob­lems like this over a good sin­gle-malt Scotch.  So I did, a few times, and that led to morn­ing and a face-palm moment.  To wit:

In the cab on the way to the office the next day it occurred to me that I should check the secu­ri­ty on the fire­walls back home.  I knew I did­n’t put any ACLs on that new link, know­ing I’d be test­ing and I pre­fer to test in the absence of arti­fi­cial prob­lems, then crank down the screws once I’m con­fi­dent of the design.  I thought, how­ev­er, that I had over­looked a NAT exemp­tion or some­thing else and decid­ed to spend some qual­i­ty time check­ing that por­tion of the infra­struc­ture.

So, I got my cof­fee at the office (thank­ful­ly the office man­ag­er is a Kiwi who favors Star­bucks) and start­ed to look over the con­fig­u­ra­tion of the fire­walls.  Right there was my face-palm moment: an ACL which, in some secu­ri­ty-con­scious delu­sion I had put on the link in ques­tion, allow­ing ICMP traf­fic and deny­ing every­thing else.  *GAAAAAH*  Long sto­ry short, I changed the ACL and every­thing “mag­i­cal­ly” start­ed work­ing.

All I can say here is that it does­n’t mat­ter who you are, or how much expe­ri­ence with trou­bleshoot­ing you have, always start with the sim­ple stuff first.  Some of the best advice I ever got was from an instruc­tor of mine who was fond of say­ing “be the pack­et.”  By that he just meant that you have to start from the pack­et’s point of view and slow­ly work through every­thing that hap­pens to said pack­et from begin­ning to end.  Wiring, arp­ing, rout­ing, etc. what­ev­er.  Be the pack­et.

Also, don’t be afraid to admit mis­takes.  They will hap­pen and hope­ful­ly oth­er peo­ple around you can learn from them.  At least after they’re done laugh­ing.  Which some­times takes a while.

Note Three (hey you kids, get off my @#$ lawn)

I just want­ed to take a quick moment to address the inevitable ques­tions about our link at 256kb, and the mus­ings that I obvi­ous­ly must have meant mb instead.  Band­width is always seen as one of those more is bet­ter kind of things, and ignor­ing the temp­ta­tion to toss out the stan­dard bandwidth/delay screed here, let me just tell you that you can get by with less than you think. By the way, those of us who can remem­ber when a 2400 baud modem was blow-your-hair-back fast (mul­ti­ple lines of text at once!) tend to be more prag­mat­ic about these things.

On that link we cur­rent­ly have a domain con­troller run­ning, sev­er­al work­sta­tions with email and our main cor­po­rate ERP soft­ware.  We also, and this is what I real­ly like, have two 7900-series IP phones run­ning.  These are both homed to our main CUCM, Uni­ty and IPCC servers back in the U.S. and have excel­lent call qual­i­ty.  In fact, we test­ed a phone call (no local call­ing for these phones in Chi­na) from those phones in Shang­hai, through the CUCM in the U.S., and back to a U.S. homed cell phone in Shang­hai and got no dis­cern­able jit­ter.

Moral of the sto­ry?  You can get by with less band­width than you think.  Would I choose to?  Hell no!  🙂

Share

Uncategorized

Shanghai Dreaming…

Read­ing Time: 1 minute

Wow I’ve been busy late­ly.  I real­ized this not just from how I feel and by look­ing at my meet­ing cal­en­dar, but also because I just noticed the month that has gone by since my last post­ing.  Time flies when you don’t know what’s going on.

I’ve got some things in the queue, notably around the Nexus 1000v soft­ware switch­es for VSphere.  Best prac­tices, expe­ri­ences in con­fig­u­ra­tion, some tips that might save your bacon dur­ing and after imple­men­ta­tion, and some ran­dom bitch­ing about Cis­co’s chang­ing rec­om­men­da­tions for how best to con­fig­ure the man­age­ment and data VLANs.  Hope­ful­ly that’s enough of a teas­er to get you watch­ing this space, or bet­ter yet by sub­scrib­ing to the RSS feed (I ful­ly sup­port lazi­ness.)  I can tell you, how­ev­er, that it could be anoth­er cou­ple of weeks or so as I am off to Shang­hai, Chi­na for a week or so to set up a new office.  Assum­ing our install date for the MPLS link is cor­rect, in any case.

Share

802.1x

802.1x for Wired Networks (Part 2)

Read­ing Time: 6 min­utes

One of the nice things about work­ing with Cis­co equip­ment, as opposed to many oth­er brands, is that you tru­ly do get a smor­gas­bord of fea­tures and capa­bil­i­ties.  On the flip side of that coin, how­ev­er, the bad thing about work­ing with Cis­co equip­ment is that you can real­ly paint your­self into a cor­ner with fea­tures, even when you know what you’re doing.  Many fea­tures and capa­bil­i­ties that you have access to on a mul­ti­lay­er switch (or bridge, layer‑2 router, for­warder, oth­er nom-de-jour) con­flict with one anoth­er, are just not near­ly as use­ful as they might seem at first glance, or bring a num­ber of gotchas to the prover­bial ball-game, often far out­weigh­ing any ben­e­fits inher­ent there­in.  Dynam­ic VLAN assign­ment with 802.1x is one of those fea­tures.

If you’ve read the first part in this series on dot1x, or are gen­er­al­ly famil­iar with the tech­nol­o­gy, you know that dot1x on a wired net­work allows a sup­pli­cant (soft­ware on your PC) to com­mu­ni­cate with an inter­me­di­ary (the switch) in order to facil­i­tate hard­ware lev­el authen­ti­ca­tion of assets on the cor­po­rate net­work.  In oth­er words, the switch acts as a traf­fic-cop and only allows known sys­tems to gain even layer‑2 access to the net­work.  This hap­pens in many cas­es pri­or to oth­er types of authen­ti­ca­tion and autho­riza­tion and can be part of an over­all secu­ri­ty strat­e­gy on your net­work.

When you try to do more with wired dot1x is where things get a lit­tle more fun.  And by fun I mean goug­ing your eyes out with dull imple­ments, or ran­dom­ly beat­ing the near­est co-work­er with the weight­ed end of a con­sole cable.  Doing more in this case refer­ring to assign­ing com­put­ers on your net­work to spe­cif­ic VLANs based on what­ev­er poli­cies you use to do these things.

For argument’s sake, and because we’ve already estab­lished that you’re prob­a­bly a masochist for doing things this way, let’s just assume that you are using VTP (VLAN Trunk­ing Pro­to­col) to keep your VLANs con­sis­tent across all switch­es in a giv­en cam­pus or build­ing.  Let’s also assume that you have  a cou­ple of VTP Servers, and all oth­er switch­es are in client mode.  This would also be a good time to men­tion VTP Pass­words, domains, and care­ful plan­ning, but I think we’ve estab­lished that you might be a bit of a rene­gade.  So we’ll move on.

If you’ve already got­ten through the first part of this series, then you already have your switch­es talk­ing to a back­end access and autho­riza­tion serv­er; most like­ly this is NPS on Win­dows 2008 Serv­er or some oth­er RADIUS serv­er tied into your user data­base.  The main thing you have to do on the RADIUS side that is dif­fer­ent for this con­fig­u­ra­tion is to deter­mine what user groups, or com­put­er groups, etc. are going to be assigned to what VLAN.

So your main switch con­fig­u­ra­tion, assum­ing NPS, could look some­thing like this and would be defined under the Radius Clients sec­tion of Net­work Pol­i­cy and Access Ser­vices:

 

All this does is estab­lish a con­nec­tion pro­file which allows your switch (or what­ev­er device) to speak to the NPS serv­er.  For net­work poli­cies we’ll have two defined for our exam­ple:

 

One of these is for the IT group, as you might have guessed.  The oth­er is for a Guest access group that we’ll talk about soon.  These poli­cies, by the way, are very flex­i­ble and can be writ­ten in a myr­i­ad of dif­fer­ent ways.  The exam­ples here are just one par­tic­u­lar way of imple­ment­ing this type of con­trol.

If we break open one of our poli­cies to look at it, you’ll see some­thing like so:

 

We actu­al­ly have a lot more in this sec­tion that we’re not show­ing, includ­ing many dia­log box­es and con­fig­u­ra­tion tabs.  The sum­ma­ry above, how­ev­er, is enough to give you a gen­er­al sense of what’s going on.  While the whole break­down is beyond the scope of what I’m writ­ing here, a cou­ple of the key things you’ll want to take note of are:

  1. Tun­nel-Pvt-Group-ID: This is the VLAN you want to assign to this group.  This had bet­ter match what exists in your VTP domain, on the switch or switch­es in ques­tion.
  2. Tun­nel-Type: This is pret­ty self-explana­to­ry, but I’ve seen it over­looked.
  3. Tun­nel-Medi­um-Type: The 802 here refers to, you guessed it, 802.1x

This is all fair­ly stan­dard serv­er-side NPS or IAS con­fig­u­ra­tion for Win­dows.  Oth­er sys­tems will, of course dif­fer­ent and have their own idio­syn­crasies to deal with.  I assume that you or some­one you work with is famil­iar with this on some lev­el, as almost all major enter­prise net­works these days use a cen­tral data­base like Active Direc­to­ry to not only con­trol user access to the net­work gen­er­al­ly, but also to authen­ti­cate and autho­rize all man­ner of con­nec­tions from wire­less dot1x to SSL VPN.

On the Cis­co side, things are actu­al­ly con­sid­er­ably clean­er as you might expect.  Since you should already have dot1x work­ing from our first part in this series, only a few changes are nec­es­sary:

  1. Define a guest VLAN (in our exam­ple we’re using this but it is far from nec­es­sary)
  2. Define a quar­an­tine, or authen­ti­ca­tion fail­ure VLAN (again, our exam­ple, etc.)
  3. Define con­fig­u­ra­tion for indi­vid­ual switch ports, or more like­ly for ranges.

Steps one and two above shouldn’t need explain­ing if you’ve come this far: just make the VLANs and be done with it.  For step three, we’re going to use the fol­low­ing con­fig­u­ra­tion:

dot1x pae authenticator
dot1x port-control auto
dot1x timeout quiet-period 5
dot1x timeout server-timeout 10
dot1x max-reauth-req 1
dot1x guest-vlan 405
dot1x auth-fail vlan 404
dot1x auth-fail max-attempts 1

 

Note that we are using a few extra options here that aren’t, strict­ly speak­ing, need­ed (the time­outs, qui­et peri­ods, etc.)  Don’t let those dis­tract you from the core ele­ments.  The dot1x guest-vlan and auth-fail vlan state­ments in par­tic­u­lar are inter­est­ing.  What we’re basi­cal­ly doing here are a cou­ple of things:

  1. When the switch port receives an EAPoL from the sup­pli­cant (PC) indi­cat­ing dot1x capa­bil­i­ty, the cre­den­tials are test­ed.  If they are good, the device is auto­mat­i­cal­ly put into the appro­pri­ate VLAN as pre­scribed by our RADIUS serv­er.
  2. If fail­ure occurs dur­ing authen­ti­ca­tion (ie; EAPoL capa­ble, but wrong cre­den­tials, etc.) then the device is put into the auth-fail VLAN (404 in this case.)
  3. If the device in ques­tion has no dot1x capa­bil­i­ty or the capa­bil­i­ty is turned off (no EAPoL seen) then the device is put into the guest VLAN (405 in this case.)

 

Note that if you have voice VLANs set up, these are unaf­fect­ed by the dot1x con­fig­u­ra­tion.  Also, you have options to force a port into a per­ma­nent autho­rized or unau­tho­rized state (using the dot1x port-con­trol force-autho­rized or force-unau­tho­rized com­mand) if you need this func­tion­al­i­ty.

So when all put togeth­er, what does this con­fig­u­ra­tion get you besides a headache?  Seam­less and dynam­ic con­trol of clients, as well as some pret­ty good secu­ri­ty.  You have the clients you know being put into their assigned VLANs regard­less of where in the net­work they are.  This can be good if you rely heav­i­ly on VLAN access con­trol lists (VACLs) for secu­ri­ty.  Clients who fail autho­riza­tion are imme­di­ate­ly dumped into what can be set up as a black-hole VLAN and then dealt with as need­ed.  Every­one else—those we don’t know or are old­er clients—can be put into a guest VLAN where maybe we just give them access out to the Inter­net at large and pos­si­bly a print­er.  This is a handy fea­ture for audi­tors or cus­tomers who may set up in a con­fer­ence room and need some access, but very lim­it­ed.  Anoth­er use for this might be in con­junc­tion with a Net­work Access Con­trol (NAC) sys­tem.  In this case you could test for appro­pri­ate patch lev­els of clients, appro­pri­ate fire­wall set­tings, unau­tho­rized soft­ware or what­ev­er, then dump the client into a quar­an­tine VLAN for reme­di­a­tion.

In the next part of this series I’ll explore some switch port secu­ri­ty fea­tures that are arguably more use­ful than dot1x, but con­flict in some way forc­ing you to make a choice.  We’ll also talk about the things that can break in some way when run­ning dot1x.  Ulti­mate­ly secu­ri­ty pol­i­cy will be deter­mined by busi­ness needs—in my case we have a pret­ty heavy secu­ri­ty bur­den due to the busi­ness we’re in.  You, how­ev­er, may find the headache of dot1x is too much to deal with when com­pared with the admin­is­tra­tive over­head to man­age it.  You may also decide that the things you give up to run it just aren’t worth the cost.  Hope­ful­ly, when we’re all done you’ll have enough infor­ma­tion to make that choice intel­li­gent­ly.

Share