• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Standard Disclaimers
  • Resume/Curriculum Vitae
  • Why Blog?
  • About
  • (Somewhat Recent) Publication List

packetqueue.net

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

Cisco

March 11, 2011 Cisco

Frame Relay Switch Setup

Read­ing Time: 5 min­utes

Edi­tor’s Note: Google Chrome seems to dis­like my site theme and is hyphen­at­ing absolute­ly every­thing.  Apolo­gies for that, and I’ll look into it just as soon as I get done with a few items on the “hon­ey-do” list.

If you are study­ing for the CCIE Rout­ing and Switch­ing exam, one of the tech­nolo­gies that is still heav­i­ly preva­lent is Frame Relay.  It is expect­ed that you know both the tech­nol­o­gy itself, and how to con­fig­ure it, but also how it inter­acts with and affects oth­er key tech­nolo­gies like OSPF and EIGRP.  Hav­ing the abil­i­ty to study Frame Relay, then, and get plen­ty of hands-on con­fig­u­ra­tion time becomes as impor­tant as with any­thing on the R&S 4.0 Blue­print.

While many net­work engi­neers are already famil­iar with Frame Relay from a con­sumer side–in oth­er words, from the per­spec­tive of an enti­ty which buys Frame Relay ser­vices from a provider–not many of us are famil­iar with the ser­vice provider por­tion of the equa­tion.  This makes set­ting up prac­tice labs dif­fi­cult if you are try­ing to study using your own equip­ment.  For­tu­nate­ly, you can set up your own Frame Relay switch fair­ly eas­i­ly, and that is what we’re going to walk through today.

A Frame Relay switch is the DCE device that sits inside a ser­vice provider’s net­work and moves the frames along from point A to point B.  There are many of these devices all work­ing togeth­er inside of your provider’s net­work to move your infor­ma­tion along, but for­tu­nate­ly for lab can­di­dates study­ing at home, you can eas­i­ly get by with just one.  Even more for­tu­nate is that you can use a fair­ly low pow­ered router to act as a Frame Relay switch, and not miss any­thing that you’ll need for pur­pos­es of the lab.

A quick note on the lab is in order here.  It used to be a part of the lab blue­print (dont’ ask me which one, or how far back in time) that you had to know how to set up a Frame Relay switch.  Cis­co has since tak­en that require­ment away, at least from the R&S lab, and so a lot of that knowl­edge isn’t com­mu­ni­cat­ed in teach­ing texts any longer.  What you’ll find in the lab itself is an already con­fig­ured Frame Relay switch that you’ll have no direct access to, but all of the infor­ma­tion you need to make your equip­ment talk to it.

It may seem coun­ter­in­tu­itive, but for a home lab the best device to use for a Frame Switch is actu­al­ly a router.  For instance, I’m using an old­er Cis­co 2621 mod­el for my Frame Switch, and it does every­thing I need it to do.  Ser­vice providers will typ­i­cal­ly use more spe­cial­ized gear, but all we’re going for in our stud­ies is a rea­son­able fac­sim­i­le.  If you want to spend a lot of mon­ey, fol­low the advice of so many oth­ers and spend it on your layer‑3 switch­es.

Anoth­er thing we want to briefly dis­cuss is inter­faces.  Gen­er­al­ly speak­ing, you can either fol­low the “run what’cha brung” phi­los­o­phy of just using what you have access to, or you can buy the inter­faces you want.  In my case I had a cou­ple of WIC-T1 cards that I’ve used, and then I bought a hand­ful of WIC-2T ser­i­al inter­face cards.  The key is to have a ser­i­al inter­face for each router you want to con­nect via the Frame switch.  So I have one T1 inter­face, and six ser­i­al inter­faces for a total of sev­en devices I can con­nect into the Frame “cloud”.  I find this to me more than ade­quate, though if you’re try­ing to dupli­cate a spe­cif­ic topol­o­gy you may need more or less.

The con­fig­u­ra­tion of a Frame switch is actu­al­ly very sim­ple, as you’ll see, though atten­tion to detail does mat­ter.  I’m assum­ing here, by the way, that you already know how to set up your router for basic access, clock, etc., so I won’t cov­er that here.  So, the first step in con­fig­ur­ing your router to be a Frame switch is to put it into Frame switch­ing mode using the com­mands:

ip cef
frame-relay switching

 

These com­mands turn on Cis­co Express For­ward­ing, put the router into a Frame switch­ing mode, and change quite a bit of the default behav­ior, so don’t expect to use this device as a router in any lab topol­o­gy you’re work­ing on.  This device will be just a Frame switch and noth­ing more.

The next step is to con­fig­ure the indi­vid­ual inter­faces you’ll con­nect your oth­er routers to, and you have a lot of choic­es here.  I don’t know exact­ly how the R&S lab devices are set up, so I’m just going to give you the con­fig­u­ra­tion I use.  I’ll post the con­fig­u­ra­tion below, and then go over the key comands:

interface Serial0/1
no ip address
encapsulation frame-relay
logging event subif-link-status
logging event dlci-status-change
clock rate 8000000
no frame-relay inverse-arp
frame-relay intf-type dce
frame-relay route 220 interface Serial0/2 120
frame-relay route 221 interface Serial0/0 320

 

The first few lines of the con­fig­u­ra­tion should be famil­iar to you already.  We’re set­ting our inter­face encap­su­la­tion to frame-relay, and then log­ging on a cou­ple of events.  The log­ging is com­plete­ly up to you, and not nec­es­sary one way or anoth­er.  I just find them help­ful.  Next we set the clock rate, and we tell the inter­face that we are the DCE end of the con­nec­tion.  Remem­ber, in a Frame Relay net­work the clock­ing (DCE end) comes from the line or provider side, so this is what you’ll want.  If I am work­ing with a T1 ser­i­al inter­face, I’ll also need a line for that:

service-module t1 clock source internal

 

This can change depend­ing on the type of card and how you have it con­fig­ured.

Now, the oth­er options we have here require a lit­tle more expla­na­tion.  The “no frame-relay inverse-arp” com­mand does just what it says, and you can argue for the Frame switch hav­ing this turned on, or off.  In most cas­es in the lab, you’ll be instruct­ed to not use inverse arp on the DTE devices, so I’ve just turned that func­tion­al­i­ty off on my Frame switch from the out­set.  It’s real­ly your call.

The next two lines begin­ning with frame-relay route are the ones that always seem to cause con­fu­sion.  You can read the first line as “If some traf­fic comes in from DLCI 220, with a des­ti­na­tion of DLCI 120, send it out inter­face Ser­i­al 0/2”.  Sub­sti­tute DLCI 221 and 320 on the next line, but oth­er­wise read it the same.  So if I now plug in a router to inter­face Ser­i­al 0/1, and assign DLCI 220 and 221 to two dif­fer­ent sub-inter­faces (for instance, dif­fer­ent options are pos­si­ble) the Frame switch will know what to do with that traf­fic.

So, if we have a dia­gram that looks like the fol­low­ing:

Then we have a con­fig­u­ra­tion for inter­faces that looks like so:

interface Serial0/0
no ip address
encapsulation frame-relay
logging event subif-link-status
logging event dlci-status-change
service-module t1 clock source internal
no frame-relay inverse-arp
frame-relay intf-type dce
frame-relay route 320 interface Serial0/1 221
frame-relay route 321 interface Serial0/2 121
!
interface Serial0/1
no ip address
encapsulation frame-relay
logging event subif-link-status
logging event dlci-status-change
clock rate 8000000
no frame-relay inverse-arp
frame-relay intf-type dce
frame-relay route 220 interface Serial0/2 120
frame-relay route 221 interface Serial0/0 320
!
interface Serial0/2
no ip address
encapsulation frame-relay
logging event subif-link-status
logging event dlci-status-change
clock rate 8000000
no frame-relay inverse-arp
frame-relay intf-type dce
frame-relay route 120 interface Serial0/1 220
frame-relay route 121 interface Serial0/0 321

 

I hope that helps out, and as always if you have any ques­tions or clar­i­fi­ca­tions please drop me a line here or on twit­ter where I’m known as @SomeClown.

Share

February 18, 2011 Cisco

Nexus Crash

Read­ing Time: 5 min­utes

As is typ­i­cal in the world of IT, prob­lems have a way of sneak­ing up on you when you least expect it, then vicious­ly attack­ing you with a Bil­ly-club.  Often this hap­pens when you are asleep, on vaca­tion, severe­ly ine­bri­at­ed, or have already worked 40-hours straight with no sleep.  In my case, Super-Bowl Sun­day at around 8:30pm was my time to get the stick.  And get it I did.

For rea­sons too sad to war­rant com­ment, and far too irri­tat­ing to explain in a fam­i­ly forum like this, our ESX host servers all became dis­con­nect­ed from our SAN array.  The root prob­lem was some­thing else on layer‑2, and got resolved quick­ly, but the vir­tu­al world was not so quick to recov­er.  In ret­ro­spect, the prob­lem was not a bad one, but when you’ve been drink­ing and can’t see the obvi­ous answer you tend to dig the hole you’ve fall­en into deep­er rather than climb prompt­ly out.

By way of back­ground, we are cur­rent­ly run­ning VSphere 4.0, with a few servers hav­ing 32GB or mem­o­ry and 8‑cores, and a few hav­ing 512GB of mem­o­ry and 24-cores. All ESX Hosts are SAN boot­ing using iSC­SI ini­tia­tors on a ded­i­cat­ed layer‑2 net­work.  We use Nexus 1000v soft switch­es and have our ESX Hosts trunk­ed using 802.1q to our Core (6506‑E switch­es run­ning VS-S720-10G super­vi­sors).  Every­thing is redun­dant (dupli­cate trunks to each Core switch) and using ether-chan­nel with mac-pin­ning).  So there you have that, for what it’s worth.  Now back to the crashed servers.

We reboot­ed all of the ESX host servers, and with the excep­tion of some FSCK-com­plain­ing they all came up quite nice­ly.  The prob­lem was that none of the vir­tu­al machines came up.  Let me add that we have the domain con­trollers, DHCP, DNS, etc. on these hosts.  Crap.

So the first thing I did in my addled state was to add DHCP scopes to the DHCP servers at anoth­er office across the coun­try, and point the VLANs off “that-a-way” by chang­ing the ip helper-address on each VLAN on the Core.  That got DHCP and DNS back online.  As you can prob­a­bly guess by now, I was Mac­Gyver-ing the sit­u­a­tion nice­ly, but real­ly didn’t need to.  That’s one of the prob­lems when you’re in the trench­es: you tend to think in terms of right-now instead of root cause.

The next thing I did was to start bring­ing up the vir­tu­al machines one-by-one using the com­mand line on the ESX hosts.  Why?  Because I had no domain authen­ti­ca­tion and the VSphere Client uses domain authen­ti­ca­tion.  Here is where some­one in a live talk would be inter­rupt­ing me to point out that the VSphere Client can always be logged into using the root user of the hosts, even when domain authen­ti­ca­tion is set up for all users.  Yes, that is true and it would have been handy to know at the time.

In order to bring up the vir­tu­al machines, I had to first find the prop­er name by issu­ing:

vmware-cmd –l

from the com­mand line.  This com­mand can take a while to run, espe­cial­ly if you have a lot of VMs sit­ting around, so go get a cup of cof­fee.

Once I had that list I pri­or­i­tized the machines I want­ed up first, and issued the:

vmware-cmd //server-name.vmx start

com­mand on each one.  That should have been the end of the boot-up dra­ma, but it wasn’t.  As it turns out, a mes­sage popped up (and I don’t remem­ber the exact phras­ing) to the effect of “you need to inter­act with the vir­tu­al machine” before it would fin­ish boot­ing.  So, now I issued the:

vmware-cmd //servername.vmx answer

com­mand and got some­thing that looked about like this:

Virtual machine message 0:
msg.uuid.altered:This virtual machine may have been moved
or copied.
In order to configure certain management and networking
features VMware ESX needs to know which.
Did you move this virtual machine, or did you copy it?
If you don't know, answer "I copied it".
0. Cancel (Cancel)
1. I _moved it (I _moved it)
2. I _copied it (I _copied it) [default]

Well, I didn’t know so I select­ed the default option (I copied it) and went on my way.  That is fine in almost every cir­cum­stance and got all of my servers boot­ed up.  It did not, how­ev­er, entire­ly fix the prob­lem.  In fact, even though all of my servers were boot­ed, none could talk or be reached on the net­work.

This is where a lit­tle famil­iar­i­ty with the Nexus 1000v soft switch­es comes in handy.  Very briefly, the archi­tec­ture is made up of two parts: the VSM or Vir­tu­al Super­vi­sor Mod­ule and the VEM or Vir­tu­al Eth­er­net Mod­ule.  The VSM cor­re­sponds rough­ly to the super­vi­sor mod­ule in a phys­i­cal chas­sis switch, and the VEMs are the line cards.  The inter­est­ing bit to remem­ber for our dis­cus­sion is that the VSMs (at least two for redun­dan­cy) are also Vir­tu­al Machines.

Some of you may have guessed already what the prob­lem turned out to be, and are prob­a­bly chortling self-right­eous­ly to your­self right about now.  For the rest of us, here’s what hap­pened:

I fig­ured out the log-in-using-root thing and got the VSphere client back up and run­ning (oh, not before hav­ing to restart a few ser­vices on the Vir­tu­al Cen­ter Serv­er, which is not a vir­tu­al machine, by the way.  I’m not total­ly crazy!).  Once I got that far I could log in to the Nexus VSM, and look at the DVS to see what was going on.  All of my uplink ports (except for ones hav­ing to do with con­trol, pack­et, vmk­er­nel, etc.) were in an “UP Blocked” state.

The short-term fix (again, the Mac­Gyver job) was to cre­ate a stan­dard switch on all hosts and migrate all crit­i­cal VMs to that switch.  That didn’t, how­ev­er, fix the prob­lem per­ma­nent­ly and besides, we like the Nexus switch­es and want­ed to use them.  With that in mind, and a day or two to nor­mal­ize the old sleep pat­terns, I set up call with VMware sup­port.  This actu­al­ly took longer than I expect­ed since I had to wait for a call-back from a Nexus Engi­neer, and they are appar­ent­ly as rare as hon­est sales-peo­ple or Uni­corns.  That said, I did get a call back and we pro­ceed­ed to trou­bleshoot the prob­lem.

One thing that sur­prised me was that it took the Nexus Engi­neer a bit longer than I would have thought to find the prob­lem, but even once he did it took longer to get res­o­lu­tion because we had to get Cis­co involved.  The prob­lem, as it turns out was licens­ing.

When you license the Nexus, you receive a PAK and you use that to install the VSM.  Once you do that, you have to request your license using the Host UID of the now installed VSM.  Cis­co then sends you a license key that you install from the com­mand-line of the VSM.  This is all some­what stan­dard and not sur­pris­ing.  What was sur­pris­ing was that we would have to do this at all con­sid­er­ing we had been licensed at the high­est lev­el (Enter­prise, superdy-duper­ty cool or some­thing) for years.

What hap­pened was that the copy VSphere made in order to get each Vir­tu­al Machine back up after our crash changed the Host UID of the VSM vir­tu­al machine(s).  Thus, the license keys were no longer valid and all host uplink ports went into a blocked state.  (I’ll save you the obvi­ous gripe I have with the Nexus not offer­ing any kind of com­mand-line mes­sage about our licens­ing being hosed.)  This is where we had to get Cis­co Licens­ing involved, as we had to send them the old license key files and the new Host-UID infor­ma­tion so that they could gen­er­ate new keys.  Con­sid­er­ing I was only on the phone with them for only 15 min­utes, it was as pleas­ant an expe­ri­ence as I’ve ever had deal­ing with Cisco’s Licens­ing depart­ment.  At least that’s some­thing.

After fix­ing the licens­ing, the ports unblocked and I went through the tedi­um of adding back adapters to the Nexus, mov­ing servers, etc.  At the end of the day, how­ev­er, it is all back to nor­mal and work­ing.  There are a lot of lessons learned here, and you’ll no doubt pull your own, but the one over­rid­ing thing to be on the look­out for is that, under cer­tain cir­cum­stances, if your Nexus VSMs are part of a crash and come back up, look to licens­ing first before trou­bleshoot­ing any­thing else.  Oh, and try to sched­ule your major sys­tem crash­es for a more con­ve­nient time… when you’re sober.  Just say­ing.

Share

October 4, 2010 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

August 11, 2010 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

August 10, 2010 Cisco

New Post Delay…

Read­ing Time: 1 minute

For all of you pay­ing any atten­tion at all, I owe you an apol­o­gy on the com­plete lack of writ­ing the last week or so.  Last week, how­ev­er, a large pile of back­o­rdered Cis­co gear showed up at the office and need­ed to be staged *imme­di­ate­ly* or as close to that as could rea­son­ably be expect­ed.  We’re in the throes of a com­plete infra­struc­ture upgrade and every­thing sort of backed up unex­pect­ed­ly with the recent deliv­ery prob­lems from Cis­co.  I would ques­tion how that becomes my prob­lem, but after 16+ years doing this pro­fes­sion­al­ly, I already know the answer to that ques­tion.  At any rate, look for a new post in my series on 802.1x in the next day or so.

Share

July 29, 2010 802.1x

802.1x for Wired Networks (Part 1)

Read­ing Time: 3 min­utes

Most of you are prob­a­bly famil­iar with the IEEE 802.1x spec­i­fi­ca­tion, at least in gen­er­al terms, but are more than like­ly used to see­ing it applied in the con­text of wire­less net­works and ser­vices.  In this mul­ti-part series, I’m going to explore the use of 802.1x as it applies to wired net­works.  In part I we’ll begin with what 802.1x is and what it isn’t, fol­lowed by some basic con­fig­u­ra­tion adher­ing to Cisco’s cur­rent best prac­tices rec­om­men­da­tions.  Then, in part II we’ll fol­low-up with a more com­plex con­fig­u­ra­tion that you real­ly, real­ly don’t want to use but I put out as an aca­d­e­m­ic exam­ple of what can be done if you like the kind of com­plex­i­ty that will guar­an­tee you or your sup­port staff nev­er sleep again.  We’ll also talk about what hap­pens when you mix oth­er secu­ri­ty fea­tures with 802.1x.

Dot1x, as I’ll be refer­ring to it from now on, is at its most fun­da­men­tal lev­el sim­ply a method for ver­i­fy­ing that a device con­nect­ed to your net­work is who it appears to be.  If a com­pa­ny-owned com­put­er con­nects to the net­work, we let them have access to cer­tain resources.  If some­one con­nects an unau­tho­rized com­put­er (per­son­al lap­top, etc.) to the net­work, they have no access to any­thing.  This is the basic idea behind dot1x when we’re talk­ing about wired net­works.

Dot1x is not encryp­tion, and doesn’t pro­vide any kind of pri­va­cy or anti-replay pro­tec­tion like IPsec.  It isn’t intend­ed for that.  Think of dot1x as login secu­ri­ty for your switch ports.  If your switch ports are con­nect­ed through to wall jacks, with no authen­ti­ca­tion, then rogue machines have at least lim­it­ed (lay­er 1 and 2) access to, at min­i­mum, the VLAN or net­work that switch port is a part of.  Is that enough to cause dam­age to your net­work?  You’ll have to decide for your­self based on your own appetite for risk and inter­nal secu­ri­ty poli­cies.

So, what do we do to make it all work?  I’m glad you asked.  You’ll need to do four things, of which I’ll cov­er the two that hap­pen on the Cis­co side:

(1)    Con­fig­ure your switch to act as an authen­ti­ca­tor

(2)    Con­fig­ure indi­vid­ual switch ports to use dot1x

(3)    Con­fig­ure your Radius Serv­er to pro­vide authen­ti­ca­tion and autho­riza­tion to clients

(4)    Turn on dot1x authen­ti­ca­tion on your clients (Win­dows, Mac, Lin­ux, etc.)

The first step is fair­ly straight for­ward, and that is to tell your switch you want to do dot1x authen­ti­ca­tion.  In order for this to work you have to have AAA enabled which is going to change your entire login method, so def­i­nite­ly play around with in a lab if you’re not famil­iar with it already.  So, the com­mands we want look like this, entered from Glob­al Con­fig mode:

! Turn on aaa authentication
aaa new-model
! Define our Radius server, port, and shared secret (must match
! with our server setup)
radius-server host 10.0.0.1 auth-port 1812 key abc123
! Here we tell the switch that our default authentication method is to
! use the Radius host we defined above
aaa authentication dot1x default group radius
! Enable dot1x on the switch
dot1x system-auth-control

 

Now that we have the switch set to authen­ti­cate clients to our Radius (Remote Authen­ti­ca­tion Dial-in User Serv­er) Serv­er, we have to make sure the Radius serv­er has some poli­cies defined.  This is beyond the scope of what I’m going to cov­er in this post, though if I get enough com­ments request­ing it I can cov­er that por­tion in anoth­er post.  Basi­cal­ly you’re just telling your Radius serv­er (typ­i­cal­ly IAS or NPS on some ver­sion of Win­dows Serv­er) that the switch will be con­tact­ing it for client authen­ti­ca­tion, and what that client can and can’t do once authen­ti­cat­ed (the autho­riza­tion piece.)

The next step is to con­fig­ure your clients to use dot1x authen­ti­ca­tion, and this is dif­fer­ent for each client OS you use.  Win­dows clients need to have a ser­vice turned on which is not on by default, where­as Mac­in­tosh has the ser­vice turned on but not con­fig­ured.  For Lin­ux and all man­ner of mobile devices, there are as many options as there are devices, so I’ll leave that as an exer­cise for the read­er.  As above with the Serv­er sec­tion, if I get enough com­ments I can cov­er the Win­dows and Mac­in­tosh con­fig­u­ra­tion piece in anoth­er post.  Mobile devices and Lin­ux I have lim­it­ed expe­ri­ence with as per­tains to dot1x set­up.

The last step in this whole busi­ness is to turn on dot1x authen­ti­ca­tion on a per port or port-range basis.  Keep in mind that you’ll want to test this before turn­ing on carte-blanche as I’ve seen a lot of mis­con­fig­u­ra­tion in the ini­tial set­up and the last thing you want is a horde of scream­ing users look­ing for your head on a stick.  There­fore, to turn on one port, pre­sum­ably for test­ing, we do like so from inter­face con­fig­u­ra­tion mode:

dot1x port-control auto
! kind of anti-climactic isn’t it

 

That is the basic con­fig­u­ra­tion of dot1x on a Cis­co switch.  In part II of this series, I’ll explore some more com­plex con­fig­u­ra­tions, as well as some less-than-ide­al ram­i­fi­ca­tions of com­bin­ing oth­er secu­ri­ty fea­tures with dot1x.  As with any­thing you con­fig­ure in the realm of secu­ri­ty in par­tic­u­lar, it is always a trade-off between secu­ri­ty and usabil­i­ty and dot1x is no excep­tion.  Test, test, and test some more.

Share
  • « Previous Page
  • Page 1
  • Page 2
  • Page 3
  • Page 4
  • Page 5
  • Next Page »

Copyright© 2022 · by Shay Bocks