Posts Tagged ‘Cisco’

Cisco Live Sunday Labtorial

This post is late in coming, considering that I’ve been back from Cisco Live for a good couple of weeks now. Nevertheless I’m posting it now, so hopefully someone finds the information useful.

Without going into the details of the entire Cisco Live experience, I’d just like to talk about the class I took on the first Sunday of the show–or the day before the show officially starts, depending on who you talk to.

On Sunday I attended a full-day mock CCIE R&S lab (Session LTRCCIE-3001). This was an instructor-led affair, with Bruce Pinsky (Distinguished Engineer) and Bruno van de Werve (Product Manager) acting as facilitators and proctors. Considering Bruno’s experience as both a proctor for the actual R&S lab, and now the head of the R&S program, this was an experience well-worth having if only for the ability to ask questions.

Unfortunately for all of us, and through no fault of either Bruce or Bruno, the in-class network was crashed from the moment we all got there. There were a number of failures, including some bad cables (how do you miss that in testing) which resulted in all of us essentially sitting around for over an hour.

To make up for the delay in getting started, someone from Cisco came in and apologized and handed out gift cards to Mandalay Bay. It was a nice gesture, but considering the gift cards had a face value of five dollars, it might have been better to not hand out anything. It had the affect of actually irritating several students, and giving the rest of us something to joke about for a while. The class cost $1000 (or 10 Cisco Learning Credits) so the value of even an hour should have been closer to $125 or so.

After that snafu, and a brief presentation by Bruno and Bruce on numbers of CCIE in the world, with breakdowns by region, we got started with the meat of the class: the labs themselves. We were all looking forward to this, since it was being run by Cisco and had the smell of real-world vs. some of the third-party labs (note that I use third party labs for training, and have no problems with them, but this was officially sanctioned and so had a little something extra, at least in “feel.”)

The troubleshooting section came first, and used the same system as the real lab so that was a nice touch. In our case we had only five trouble tickets to complete in one hour vs. the real lab which has ten in two hours. I believe this was done to facilitate the “instructor led” nature of the class, and allow us to ask plenty of questions. Bruce and Bruno were stellar in this regard, coming around to any student with a question and helping them to understand the problem or just passing out hints to those who still wanted to figure it out on their own.

I learned a lot about myself and my troubleshooting techniques during this portion of the day, as I got bogged down on the first ticket and blew the rest of my time. It was a relatively straightforward ticket where a particular address wasn’t answering an ICMP Echo to another device. It was a few routers together, with BGP. I spent the entire hour re-architecting the BGP–down to bare metal and rebuilding the config from scratch–and almost was done when time expired. As it turned out, it was a simple address statement that was missing.

Bruno got a chuckle out of this and pointed out that the lab is not intended as a “best practices” lab. He said that in most cases you won’t be removing configuration at all during the TS section; you’ll simply be adding something missing or correcting route statements, etc. It was helpful for me to hear this and to go through the experience, because it taught me that I really need to focus on finding the simple problem quickly and not rebuilding things the way I think they ought to be built. After 17 years in the industry, that’s a difficult habit to change, but one I’ll have to in order to be successful on the real lab.

After a brief recap and break, we moved on to the configuration section. For the most part there were no surprises here, and I had my Layer-2 (Frame, Spanning-tree, VTP, etc.) and IGP (RIP, OSPF, and EIGRP here) set up quickly enough. Redistribution was what you’d expect, with a lot of everything going every which way. Again, no one in their right mind would ever design that network, but it’s what you can expect to see in the lab.

The one thing I did miss and had to have Bruno point out to me, is in a redistribution task regarding OSPF. The task wanted a route from one area to show up in area 0. I got the route there, but Bruno said that I had it wrong. Reason? The area where the route originated was discontiguous, or detached from area 0. We all know that typically means you want a virtual link, but since the task didn’t specify this I simply brought the route into area 0 as an external. Bruno said that the task “implied” a virtual link, and while I disagree with the wording of the task and the nature of implied configurations, it was helpful to hear since this is likely the same kind of thing I’ll see in the real lab.

Where I slowed down–and I knew I would–is on the MPLS and BGP configuration sections. As a long-time enterprise engineer, I simply don’t touch either of these technologies in the real-world, and I haven’t spent enough time with them in the lab to feel comfortable. I still muddled my way through some of it, but with the amount of time it took I’d never make it through the real lab. The message for me here is that I really need to take some time with these technologies until I not only understand them well, but can configure them quickly.

Overall, this was a very valuable experience and one I would heartily recommend to anyone looking to take the R&S lab. It gave valuable insight into the time pressures you’ll face, as well as the number of tasks, the wording, and the level of difficulty you can expect to see. This is just one more reason that Cisco Live is where you want to be every year if you’re at all serious about your networking career.

Incoming search terms for the article:

Share
Tags: , , ,

Cisco Live 2010 Photos

Cisco Live!

I just wanted to drop a quick note here to let everyone know that I plan on blogging a little more frequently this week, as I’ll be in Las Vegas for the annual North American Cisco conference: Cisco Networkers/Live. I can’t promise I’ll be in my room slaving over long, elaborate breakdowns of technology–maybe an in depth review of whiskey selections by bar–but I will try to post some pictures and information about what I’m seeing and hearing during the show. In years where I haven’t been able to attend the show, I always liked seeing and hearing from folks who did. Now it’s my turn to give back something, so watch this space…

Oh, and keep up with real-time information on twitter where I hide behind the handle @someclown, or G+ where I can be found at: http://gplus.to/someclown.

Share

IPv6 Half-truths

This post will be a short one, and mostly just comes from a discussion I had the other day with another engineer.  It turns out that even among people who are comfortable with IPv6, and maybe even have experience deploying it, a lot of misinformation still persists.  Hopefully I can correct a couple of those today.  I also tossed in a hot-potato at the end just to see how many folks get hopped up.  Discussion is welcome, and in addition to comments here I can be found on twitter hiding behind the handle: @someclown.

You must turn on IPv6 by using the IPv6 unicast-routing command.

Not true.  This is one of the more persistent, yet wildly incorrect, pieces of information regarding IPv6.  I have even seen many training centers and instructors at the CCIE level get this one wrong and it falls into the category of attention to detail.  What this command actually does is enable unicast routing for IPv6, just as it says.  To actually enable IPv6 you simply need to go to any interface and use the ipv6 enable command.  And yes, you can enable IPv6 on the interface without enabling unicast routing.  Of course, it would be helpful to have an address on the interface as well.

Yes, but if you don’t turn on unicast routing you can’t route IPv6 traffic.

Not strictly speaking true.  You can still set up a default route for IPv6 traffic and get it off of your system.  To the extent that you want to argue whether or not this is actually routing is fine, but you can move IPv6 traffic off of your local device using a default route, and never have enabled routing for IPv6.

Using a /127 address on point-to-point links is wrong, wrong, wrong.

This is an interesting one, and usually sparks a fair amount of debate.  Up until very recently, the recommendation across the board (RFC 4291) was to use /64 addresses even on point-to-point links, ostensibly because the IPv6 space is so big anyhow, and because several protocols will break (notably subnet-router anycast, specified in RFC 3627).  While I’m not disputing that this is what the current best-practices reflect, I will say that RFC 6164 which has a status of Proposed Standard makes a fairly compelling case for using /127 on point-to-point links.  I’m sure this won’t be resolved anytime soon, standards or no, but I would say that if you have a compelling reason for using /127 and know what you’re doing it for, go for it.  Just be aware that standards can change, and you don’t want to leave a steaming pile for the poor person who has to follow you.

Incoming search terms for the article:

Share
Tags: ,

Home CCIE Study Lab

So, a lot of people who are working towards their CCIE certifications end up building home labs for studying.  The reasons are many and varied, but mine boiled down to two primary ones:

 

(1) My study hours don’t always match well with what slots the online rack vendors have available.

(2) I just like physical equipment and the flexibility it provides in both studying and in research.

Also, I just wanna.

With that said, one of the next things people want to know is what gear it is that I have, and how do I have it configured.  Therefore, with the recent posting frequency here severely lacking, writing about my lab is a nice way to get something fresh on the blog and hopefully it provides something useful to someone out there.  I’m going to break this down into two general categories: equipment that I have purely for my Cisco CCIE lab, and other equipment that I have either for my home network or for random reasons.

Random Non-Lab Specific Equipment List:

  1. WS-2950T-24 switch
  2. Two 1142N access points
  3. Wireless Controller Module (NME-AIR-WLC6-K9) which is pretty fun, but breaks bonjour and so is the bane of my existence (see previous post here.)
  4. ASA 5505 with IPS module, running bot-net filter and some other things.  This is also the main gateway for the home network, connecting up to the cable modem.  It’s also the IPsec endpoint for my always-on connection to the office and segments my home network, lab network, work network, etc.
  5. Comcast Cable Modem, made by Motorolla
  6. Random doohickey for my “Whole-Home DVR” with DirecTV
  7. Sun SunFire v240 Server with StorEdge 3300 storage array

Non-plugged in Equipment

  1. Sun Enterprise 3500
  2. Two Cisco 3550 switches
  3. Two PIX 501

Computer storage:

  1. Seagate 750GB external drive (USB)
  2. Iomega 1TB external (eSATA)
  3. Drobo S with 5 2TB drives for 10TB raw (eSATA)

Cisco Lab Equipment:

  1. Four 3560-X switches, with four-gig uplink modules (might still get the 10 at some point), fully licensed with IPServices and running 12.2(53) SE2.
  2. Eight 2801 routers, all running 12.4(22)T5 Advanced Enterprise, and all with at least one Wic-2T smart serial card which provides two smart serial connections.  Four of the 2801 have two Wic-2T cards, and a couple others have a mixture of 1-Wic-DSU-T1 cards, FXO cards, and FXS cards (mostly leftovers and hand-me downs, but there are some interesting possibilities.)
  3. One 2811 running the same IOS as the 2801 routers, used as a backbone router for injecting routes and some other misc. stuff.
  4. One 2621 running something-or-other and acting as another backbone router.
  5. One 3845 running the same Advanced Enterprise as the others.  This has five Wic-2T cards and acts as the frame switch. It also has an HWIC-16A card and does reverse-telnet to everything else (terminal server).  It also houses some random stuff including the wireless controller mentioned above.

All of this is cabled and wired almost identically to the CCBootCamp lab topology.  This is because I have all of their workbooks and wanted to be able to study with my own equipment.  A couple of the details are different, mostly around interface numbers and the specifics of the backbone routers and such.  Also, the switches I have are way overkill but satisfy the lab requirements.  Given the actual topology from just about any mainstream training provider, I can copy it with the equipment I have, and that’s exactly what I wanted to be able to do.  As always, contact me here or on twitter with questions and comments.

Pictures of the lab and sundries are included below.

Incoming search terms for the article:

Share
Tags: ,

Frame Relay Switch Setup

Editor’s Note: Google Chrome seems to dislike my site theme and is hyphenating absolutely everything.  Apologies for that, and I’ll look into it just as soon as I get done with a few items on the “honey-do” list.

If you are studying for the CCIE Routing and Switching exam, one of the technologies that is still heavily prevalent is Frame Relay.  It is expected that you know both the technology itself, and how to configure it, but also how it interacts with and affects other key technologies like OSPF and EIGRP.  Having the ability to study Frame Relay, then, and get plenty of hands-on configuration time becomes as important as with anything on the R&S 4.0 Blueprint.

While many network engineers are already familiar with Frame Relay from a consumer side–in other words, from the perspective of an entity which buys Frame Relay services from a provider–not many of us are familiar with the service provider portion of the equation.  This makes setting up practice labs difficult if you are trying to study using your own equipment.  Fortunately, you can set up your own Frame Relay switch fairly easily, and that is what we’re going to walk through today.

A Frame Relay switch is the DCE device that sits inside a service provider’s network and moves the frames along from point A to point B.  There are many of these devices all working together inside of your provider’s network to move your information along, but fortunately for lab candidates studying at home, you can easily get by with just one.  Even more fortunate is that you can use a fairly low powered router to act as a Frame Relay switch, and not miss anything that you’ll need for purposes of the lab.

A quick note on the lab is in order here.  It used to be a part of the lab blueprint (dont’ ask me which one, or how far back in time) that you had to know how to set up a Frame Relay switch.  Cisco has since taken that requirement away, at least from the R&S lab, and so a lot of that knowledge isn’t communicated in teaching texts any longer.  What you’ll find in the lab itself is an already configured Frame Relay switch that you’ll have no direct access to, but all of the information you need to make your equipment talk to it.

It may seem counterintuitive, but for a home lab the best device to use for a Frame Switch is actually a router.  For instance, I’m using an older Cisco 2621 model for my Frame Switch, and it does everything I need it to do.  Service providers will typically use more specialized gear, but all we’re going for in our studies is a reasonable facsimile.  If you want to spend a lot of money, follow the advice of so many others and spend it on your layer-3 switches.

Another thing we want to briefly discuss is interfaces.  Generally speaking, you can either follow the “run what’cha brung” philosophy of just using what you have access to, or you can buy the interfaces you want.  In my case I had a couple of WIC-T1 cards that I’ve used, and then I bought a handful of WIC-2T serial interface cards.  The key is to have a serial interface for each router you want to connect via the Frame switch.  So I have one T1 interface, and six serial interfaces for a total of seven devices I can connect into the Frame “cloud”.  I find this to me more than adequate, though if you’re trying to duplicate a specific topology you may need more or less.

The configuration of a Frame switch is actually very simple, as you’ll see, though attention to detail does matter.  I’m assuming here, by the way, that you already know how to set up your router for basic access, clock, etc., so I won’t cover that here.  So, the first step in configuring your router to be a Frame switch is to put it into Frame switching mode using the commands:

ip cef
frame-relay switching

 

These commands turn on Cisco Express Forwarding, put the router into a Frame switching mode, and change quite a bit of the default behavior, so don’t expect to use this device as a router in any lab topology you’re working on.  This device will be just a Frame switch and nothing more.

The next step is to configure the individual interfaces you’ll connect your other routers to, and you have a lot of choices here.  I don’t know exactly how the R&S lab devices are set up, so I’m just going to give you the configuration I use.  I’ll post the configuration 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 configuration should be familiar to you already.  We’re setting our interface encapsulation to frame-relay, and then logging on a couple of events.  The logging is completely up to you, and not necessary one way or another.  I just find them helpful.  Next we set the clock rate, and we tell the interface that we are the DCE end of the connection.  Remember, in a Frame Relay network the clocking (DCE end) comes from the line or provider side, so this is what you’ll want.  If I am working with a T1 serial interface, I’ll also need a line for that:

service-module t1 clock source internal

 

This can change depending on the type of card and how you have it configured.

Now, the other options we have here require a little more explanation.  The “no frame-relay inverse-arp” command does just what it says, and you can argue for the Frame switch having this turned on, or off.  In most cases in the lab, you’ll be instructed to not use inverse arp on the DTE devices, so I’ve just turned that functionality off on my Frame switch from the outset.  It’s really your call.

The next two lines beginning with frame-relay route are the ones that always seem to cause confusion.  You can read the first line as “If some traffic comes in from DLCI 220, with a destination of DLCI 120, send it out interface Serial 0/2″.  Substitute DLCI 221 and 320 on the next line, but otherwise read it the same.  So if I now plug in a router to interface Serial 0/1, and assign DLCI 220 and 221 to two different sub-interfaces (for instance, different options are possible) the Frame switch will know what to do with that traffic.

So, if we have a diagram that looks like the following:

Then we have a configuration for interfaces 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 questions or clarifications please drop me a line here or on twitter where I’m known as @SomeClown.

Incoming search terms for the article:

Share

802.1x for Wired Networks (Part 2)

One of the nice things about working with Cisco equipment, as opposed to many other brands, is that you truly do get a smorgasbord of features and capabilities.  On the flip side of that coin, however, the bad thing about working with Cisco equipment is that you can really paint yourself into a corner with features, even when you know what you’re doing.  Many features and capabilities that you have access to on a multilayer switch (or bridge, layer-2 router, forwarder, other nom-de-jour) conflict with one another, are just not nearly as useful as they might seem at first glance, or bring a number of gotchas to the proverbial ball-game, often far outweighing any benefits inherent therein.  Dynamic VLAN assignment with 802.1x is one of those features.

If you’ve read the first part in this series on dot1x, or are generally familiar with the technology, you know that dot1x on a wired network allows a supplicant (software on your PC) to communicate with an intermediary (the switch) in order to facilitate hardware level authentication of assets on the corporate network.  In other words, the switch acts as a traffic-cop and only allows known systems to gain even layer-2 access to the network.  This happens in many cases prior to other types of authentication and authorization and can be part of an overall security strategy on your network.

When you try to do more with wired dot1x is where things get a little more fun.  And by fun I mean gouging your eyes out with dull implements, or randomly beating the nearest co-worker with the weighted end of a console cable.  Doing more in this case referring to assigning computers on your network to specific VLANs based on whatever policies you use to do these things.

For argument’s sake, and because we’ve already established that you’re probably a masochist for doing things this way, let’s just assume that you are using VTP (VLAN Trunking Protocol) to keep your VLANs consistent across all switches in a given campus or building.  Let’s also assume that you have  a couple of VTP Servers, and all other switches are in client mode.  This would also be a good time to mention VTP Passwords, domains, and careful planning, but I think we’ve established that you might be a bit of a renegade.  So we’ll move on.

If you’ve already gotten through the first part of this series, then you already have your switches talking to a backend access and authorization server; most likely this is NPS on Windows 2008 Server or some other RADIUS server tied into your user database.  The main thing you have to do on the RADIUS side that is different for this configuration is to determine what user groups, or computer groups, etc. are going to be assigned to what VLAN.

So your main switch configuration, assuming NPS, could look something like this and would be defined under the Radius Clients section of Network Policy and Access Services:

 

All this does is establish a connection profile which allows your switch (or whatever device) to speak to the NPS server.  For network policies we’ll have two defined for our example:

 

One of these is for the IT group, as you might have guessed.  The other is for a Guest access group that we’ll talk about soon.  These policies, by the way, are very flexible and can be written in a myriad of different ways.  The examples here are just one particular way of implementing this type of control.

If we break open one of our policies to look at it, you’ll see something like so:

 

We actually have a lot more in this section that we’re not showing, including many dialog boxes and configuration tabs.  The summary above, however, is enough to give you a general sense of what’s going on.  While the whole breakdown is beyond the scope of what I’m writing here, a couple of the key things you’ll want to take note of are:

  1. Tunnel-Pvt-Group-ID: This is the VLAN you want to assign to this group.  This had better match what exists in your VTP domain, on the switch or switches in question.
  2. Tunnel-Type: This is pretty self-explanatory, but I’ve seen it overlooked.
  3. Tunnel-Medium-Type: The 802 here refers to, you guessed it, 802.1x

This is all fairly standard server-side NPS or IAS configuration for Windows.  Other systems will, of course different and have their own idiosyncrasies to deal with.  I assume that you or someone you work with is familiar with this on some level, as almost all major enterprise networks these days use a central database like Active Directory to not only control user access to the network generally, but also to authenticate and authorize all manner of connections from wireless dot1x to SSL VPN.

On the Cisco side, things are actually considerably cleaner as you might expect.  Since you should already have dot1x working from our first part in this series, only a few changes are necessary:

  1. Define a guest VLAN (in our example we’re using this but it is far from necessary)
  2. Define a quarantine, or authentication failure VLAN (again, our example, etc.)
  3. Define configuration for individual switch ports, or more likely for ranges.

Steps one and two above shouldn’t need explaining if you’ve come this far: just make the VLANs and be done with it.  For step three, we’re going to use the following configuration:

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, strictly speaking, needed (the timeouts, quiet periods, etc.)  Don’t let those distract you from the core elements.  The dot1x guest-vlan and auth-fail vlan statements in particular are interesting.  What we’re basically doing here are a couple of things:

  1. When the switch port receives an EAPoL from the supplicant (PC) indicating dot1x capability, the credentials are tested.  If they are good, the device is automatically put into the appropriate VLAN as prescribed by our RADIUS server.
  2. If failure occurs during authentication (ie; EAPoL capable, but wrong credentials, etc.) then the device is put into the auth-fail VLAN (404 in this case.)
  3. If the device in question has no dot1x capability or the capability 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 unaffected by the dot1x configuration.  Also, you have options to force a port into a permanent authorized or unauthorized state (using the dot1x port-control force-authorized or force-unauthorized command) if you need this functionality.

So when all put together, what does this configuration get you besides a headache?  Seamless and dynamic control of clients, as well as some pretty good security.  You have the clients you know being put into their assigned VLANs regardless of where in the network they are.  This can be good if you rely heavily on VLAN access control lists (VACLs) for security.  Clients who fail authorization are immediately dumped into what can be set up as a black-hole VLAN and then dealt with as needed.  Everyone else—those we don’t know or are older clients—can be put into a guest VLAN where maybe we just give them access out to the Internet at large and possibly a printer.  This is a handy feature for auditors or customers who may set up in a conference room and need some access, but very limited.  Another use for this might be in conjunction with a Network Access Control (NAC) system.  In this case you could test for appropriate patch levels of clients, appropriate firewall settings, unauthorized software or whatever, then dump the client into a quarantine VLAN for remediation.

In the next part of this series I’ll explore some switch port security features that are arguably more useful than dot1x, but conflict in some way forcing you to make a choice.  We’ll also talk about the things that can break in some way when running dot1x.  Ultimately security policy will be determined by business needs—in my case we have a pretty heavy security burden due to the business we’re in.  You, however, may find the headache of dot1x is too much to deal with when compared with the administrative overhead to manage it.  You may also decide that the things you give up to run it just aren’t worth the cost.  Hopefully, when we’re all done you’ll have enough information to make that choice intelligently.

Incoming search terms for the article:

Share

802.1x for Wired Networks (Part 1)

Most of you are probably familiar with the IEEE 802.1x specification, at least in general terms, but are more than likely used to seeing it applied in the context of wireless networks and services.  In this multi-part series, I’m going to explore the use of 802.1x as it applies to wired networks.  In part I we’ll begin with what 802.1x is and what it isn’t, followed by some basic configuration adhering to Cisco’s current best practices recommendations.  Then, in part II we’ll follow-up with a more complex configuration that you really, really don’t want to use but I put out as an academic example of what can be done if you like the kind of complexity that will guarantee you or your support staff never sleep again.  We’ll also talk about what happens when you mix other security features with 802.1x.

Dot1x, as I’ll be referring to it from now on, is at its most fundamental level simply a method for verifying that a device connected to your network is who it appears to be.  If a company-owned computer connects to the network, we let them have access to certain resources.  If someone connects an unauthorized computer (personal laptop, etc.) to the network, they have no access to anything.  This is the basic idea behind dot1x when we’re talking about wired networks.

Dot1x is not encryption, and doesn’t provide any kind of privacy or anti-replay protection like IPsec.  It isn’t intended for that.  Think of dot1x as login security for your switch ports.  If your switch ports are connected through to wall jacks, with no authentication, then rogue machines have at least limited (layer 1 and 2) access to, at minimum, the VLAN or network that switch port is a part of.  Is that enough to cause damage to your network?  You’ll have to decide for yourself based on your own appetite for risk and internal security policies.

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 cover the two that happen on the Cisco side:

(1)    Configure your switch to act as an authenticator

(2)    Configure individual switch ports to use dot1x

(3)    Configure your Radius Server to provide authentication and authorization to clients

(4)    Turn on dot1x authentication on your clients (Windows, Mac, Linux, etc.)

The first step is fairly straight forward, and that is to tell your switch you want to do dot1x authentication.  In order for this to work you have to have AAA enabled which is going to change your entire login method, so definitely play around with in a lab if you’re not familiar with it already.  So, the commands we want look like this, entered from Global Config 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 authenticate clients to our Radius (Remote Authentication Dial-in User Server) Server, we have to make sure the Radius server has some policies defined.  This is beyond the scope of what I’m going to cover in this post, though if I get enough comments requesting it I can cover that portion in another post.  Basically you’re just telling your Radius server (typically IAS or NPS on some version of Windows Server) that the switch will be contacting it for client authentication, and what that client can and can’t do once authenticated (the authorization piece.)

The next step is to configure your clients to use dot1x authentication, and this is different for each client OS you use.  Windows clients need to have a service turned on which is not on by default, whereas Macintosh has the service turned on but not configured.  For Linux and all manner of mobile devices, there are as many options as there are devices, so I’ll leave that as an exercise for the reader.  As above with the Server section, if I get enough comments I can cover the Windows and Macintosh configuration piece in another post.  Mobile devices and Linux I have limited experience with as pertains to dot1x setup.

The last step in this whole business is to turn on dot1x authentication on a per port or port-range basis.  Keep in mind that you’ll want to test this before turning on carte-blanche as I’ve seen a lot of misconfiguration in the initial setup and the last thing you want is a horde of screaming users looking for your head on a stick.  Therefore, to turn on one port, presumably for testing, we do like so from interface configuration mode:

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

 

That is the basic configuration of dot1x on a Cisco switch.  In part II of this series, I’ll explore some more complex configurations, as well as some less-than-ideal ramifications of combining other security features with dot1x.  As with anything you configure in the realm of security in particular, it is always a trade-off between security and usability and dot1x is no exception.  Test, test, and test some more.

Incoming search terms for the article:

Share

2960-S 1st Impressions

Just noticing some differences in this 2960-S model switch; things I haven’t seen before in this product line. One thing is the console port is now two ports: traditional and a small mini-USB. Also, there is a classic USB plug onboard these now too, presumably for IOS updates and whatnot. These are also stackable, which makes sense given Cisco’s new direction in their SWITCH course training material eschewing Spanning-Tree and trying to push Layer-3 everywhere.

1st boot-up below, more impressions later.

Using driver version 1 for media type 1
Base ethernet MAC Address: a8:b1:d4:64:8f:00
Xmodem file system is available.
The password-recovery mechanism is enabled.
Initializing Flash…
mifs[2]: 0 files, 1 directories
mifs[2]: Total bytes : 1806336
mifs[2]: Bytes used : 1024
mifs[2]: Bytes available : 1805312
mifs[2]: mifs fsck took 1 seconds.
mifs[3]: 0 files, 1 directories
mifs[3]: Total bytes : 3870720
mifs[3]: Bytes used : 1024
mifs[3]: Bytes available : 3869696
mifs[3]: mifs fsck took 0 seconds.
mifs[4]: 5 files, 1 directories
mifs[4]: Total bytes : 258048
mifs[4]: Bytes used : 9216
mifs[4]: Bytes available : 248832
mifs[4]: mifs fsck took 0 seconds.
mifs[5]: 5 files, 1 directories
mifs[5]: Total bytes : 258048
mifs[5]: Bytes used : 9216
mifs[5]: Bytes available : 248832
mifs[5]: mifs fsck took 1 seconds.
mifs[6]: 559 files, 19 directories
mifs[6]: Total bytes : 57931776
mifs[6]: Bytes used : 14971392
mifs[6]: Bytes available : 42960384
mifs[6]: mifs fsck took 14 seconds.
…done Initializing Flash.
done.
Loading “flash:/c2960s-universalk9-mz.122-53.SE2/c2960s-universalk9-mz.122-53.SE2.bin”…@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
File “flash:/c2960s-universalk9-mz.122-53.SE2/c2960s-universalk9-mz.122-53.SE2.bin” uncompressed and installed, entry point: 0×3000
executing…

Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software – Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706

Cisco IOS Software, C2960S Software (C2960S-UNIVERSALK9-M), Version 12.2(53)SE2, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Wed 21-Apr-10 06:08 by prod_rel_team
Image text-base: 0×00003000, data-base: 0x01B00000

Initializing flashfs…
Using driver version 1 for media type 1
mifs[3]: 0 files, 1 directories
mifs[3]: Total bytes : 1806336
mifs[3]: Bytes used : 1024
mifs[3]: Bytes available : 1805312
mifs[3]: mifs fsck took 0 seconds.
mifs[3]: Initialization complete.

mifs[4]: 0 files, 1 directories
mifs[4]: Total bytes : 3870720
mifs[4]: Bytes used : 1024
mifs[4]: Bytes available : 3869696
mifs[4]: mifs fsck took 1 seconds.
mifs[4]: Initialization complete.

mifs[5]: 5 files, 1 directories
mifs[5]: Total bytes : 258048
mifs[5]: Bytes used : 9216
mifs[5]: Bytes available : 248832
mifs[5]: mifs fsck took 0 seconds.
mifs[5]: Initialization complete.

mifs[6]: 5 files, 1 directories
mifs[6]: Total bytes : 258048
mifs[6]: Bytes used : 9216
mifs[6]: Bytes available : 248832
mifs[6]: mifs fsck took 0 seconds.
mifs[6]: Initialization complete.

mifs[7]: 559 files, 19 directories
mifs[7]: Total bytes : 57931776
mifs[7]: Bytes used : 14971392
mifs[7]: Bytes available : 42960384
mifs[7]: mifs fsck took 1 seconds.
mifs[7]: Initialization complete.

…done Initializing flashfs.

POST: MA BIST : Begin
FC 1 MBIST Test Passed.
DP Sg1 MBIST Test Passed.
DP Xg1 MBIST Test Passed.
NI 1 MBIST Test Passed.
FC 0 MBIST Test Passed.
DP Sg0 MBIST Test Passed.
DP Xg0 MBIST Test Passed.
NI 0 MBIST Test Passed.
UPB MBIST Test Passed.
POST: MA BIST : End, Status Passed

POST: TCAM BIST : Begin
POST: TCAM BIST : End, Status Passed

front_end/ (directory)
extracting front_end/fe_type_4 (78476 bytes)
extracting front_end/front_end_ucode_info (43 bytes)
extracting ucode_info (77 bytes)
Waiting for Stack Master Election…
POST: Thermal, Fan Tests : Begin
POST: Thermal, Fan Tests : End, Status Passed

POST: PortASIC Stack Port Loopback Tests : Begin
POST: PortASIC Stack Port Loopback Tests : End, Status Passed

POST: PortASIC Port Loopback Tests : Begin
POST: PortASIC Port Loopback Tests : End, Status Passed

POST: EMAC Loopback Tests : Begin
POST: EMAC Loopback Tests : End, Status Passed

Election Complete
Switch 1 booting as Master
Waiting for Port download…Complete

This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

cisco WS-C2960S-48TS-L (PowerPC) processor (revision A0) with 131072K bytes of memory.
Processor board ID FOC1425W1J7
Last reset from power-on
1 Virtual Ethernet interface
1 FastEthernet interface
52 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : A8:B1:D4:64:8F:00
Motherboard assembly number : 73-11909-05
Power supply part number : 341-0327-01
Motherboard serial number : FOC14251HQ7
Power supply serial number : DCA1413P1BF
Model revision number : A0
Motherboard revision number : A0
Model number : WS-C2960S-48TS-L
Daughterboard assembly number : 73-11933-04
Daughterboard serial number : FOC14232S4V
System serial number : FOC1425W1J7
Top Assembly Part Number : 800-30950-01
Top Assembly Revision Number : A0
Version ID : V01
CLEI Code Number : COMGF00ARA
Daughterboard revision number : A0
Hardware Board Revision Number : 0×01

Switch Ports Model SW Version SW Image
—— —– —– ———- ———-
* 1 52 WS-C2960S-48TS-L 12.2(53)SE2 C2960S-UNIVERSALK9-M

Incoming search terms for the article:

Share

ASA TU

You ever have one of those weeks where everything that can go wrong, does? And even things that can’t go wrong, still do? Last week was that week for me. But more on that later.

I’m finally relaxing with a beer in my home office, Friday afternoon, after said hell-week, when suddenly I notice that my desk phone has mysteriously powered off. Beyond the visual cue of no screen display, and a nagging suspicion that something was still not right in the world, I also heard it when it shut down (The Cisco 7940 models in particular seem to make some noise when turning on and off.) Since this phone is using PoE from a Cisco ASA 5505, I glanced over at the 5505 to see what might be causing all of the unhappiness. Immediately I noticed that something wasn’t right, as the status light was orange for a second, then the whole unit rebooted. At that point the display lights go all green, then amber, then another reboot… ad naseum.

What the @#$!?

Trying to log in via either SSH or ASDM yields no love at all, so I hook up a console cable. There it is: the ASA apparently doesn’t have any OS to boot.

Again with the @#$!?

So, I take the cover off and pull out the *cough* expensive-as-hell *cough* flash card to double-check things on desktop computer. Sure enough, the computer reports that the flash card is not formatted. So I formatted it, reinstalled the OS and license information from–wait for it–the backup I had made recently. At this point I could have used this as another learning experience and re-configured the unit from scratch, just to test myself, but at the time I was trying to get some movie tickets purchased and had just gotten done with a very, very tiring week. Not surprisingly then, I took the easy way out and restored the configuration as well.

After a quick reinstall, the unit came back up and everything is fine.

My main lesson learned here–and I’m wondering if this is something that has happened to other people, or happens frequently with the ASA units–is that the Cisco ASAs seem to occasionally wipe out the installed flash card (cards plural if you have 5510s or bigger.) Either that, or the ridiculously expensive (like $300 or something) Cisco-branded 512mb flash cards are flakey as hell. I don’t tend to go with that last option, however, simply because when flash cards go bad they’re not usually amenable to being re-formatted and working properly again: it’s usually game-over, buy another one.

So, another random problem at least solved in the short-term. I’ll keep everyone posted on whether or not this happens again. I haven’t seen anything indicating that this is a known issue, but admittedly I haven’t really been looking. Auto-magically wiping out the entire boot OS, configuration, licenses, etc. would seem to be a fairly non-useful type of bug to have–even by, say, Microsoft standards… let alone Cisco.

So, has anyone seen this before?

Incoming search terms for the article:

Share