Archive

Archive for May, 2009

Sun SPARC Ultra 25 Boot Fails at Probing I/O buses

May 27th, 2009 3 comments

So I have burned *way* too many hours on and off over the last couple weeks trying to get an Ultra 25 Sparc box I inherited working.  This box came to me with the video card not in the machine and some comment about it not working.

After putting the video card back in the box, when I booted the box it would not give any video output to the monitor.  I hooked into the serial console (9600-8-N-1 of course) and it appeared to be hanging with the last output being: Probing I/O buses

reset reason: 0000.0000.0000.0004
@(#)OBP 4.25.9 2007/08/23 14:17 Sun Ultra 25 Workstation
Clearing TLBs
Power-On Reset
Membase: 0000.0000.0000.0000
MemSize: 0000.0000.0004.0000
Init CPU arrays Done
Init E$ tags Done
Setup TLB (small-footprint mode) Done
MMUs ON
Init Fire JBUS Control Register… 
Find dropin, Copying Done, Size 0000.0000.0000.7260
PC = 0000.07ff.f000.6178
PC = 0000.0000.0000.6228
Find dropin, Copying Done, Size 0000.0000.0001.1440
Diagnostic console initialized
Configuring system memory & CPU(s)

CPU 0 Memory Configuration: Valid
CPU 0 Bank 0 1024 MB Bank 1 <empty> Bank 2 1024 MB Bank 3 <empty>

reset reason: 0000.0000.0000.0005
@(#)OBP 4.25.9 2007/08/23 14:17 Sun Ultra 25 Workstation
Clearing TLBs
Loading Configuration

Membase: 0000.0002.0000.0000
MemSize: 0000.0000.4000.0000
Init CPU arrays Done
Init E$ tags Done
Setup TLB Done
MMUs ON
Init Fire JBUS Control Register… 
Block Scrubbing Done
Find dropin, Copying Done, Size 0000.0000.0000.7260
PC = 0000.07ff.f000.6178
PC = 0000.0000.0000.6228
Find dropin, (copied), Decompressing Done, Size 0000.0000.0006.4530
Diagnostic console initialized
System Reset: CPU Reset (SPOR)
Probing system devices
jbus at 0,0 SUNW,UltraSPARC-IIIi (1336 MHz @ 8:1, 1 MB) memory-controller
jbus at 1,0 Nothing there
jbus at 1c,0 Nothing there
jbus at 1d,0 Nothing there
jbus at 1e,0 pci
jbus at 1f,0 pci
Loading Support Packages: kbd-translator obp-tftp SUNW,i2c-ram-device SUNW,fru-device SUNW,asr
Loading onboard drivers: ebus i2c i2c i2c ppm
/ebus@1f,464000: flashprom rtc serial serial env-monitor i2c power
/ebus@1f,464000/i2c@3,80: gpio temperature temperature temperature front-io-fru-prom sas-backplane-fru-prom dimm-spd psu-fru-prom hardware-monitor
/i2c@1f,520000: dimm-spd dimm-spd dimm-spd dimm-spd
/i2c@1f,530000: motherboard-fru-prom gpio clock-generator
/i2c@1f,462020: nvram idprom
Probing memory
CPU 0 Bank 0 base          0 size 1024 MB
CPU 0 Bank 2 base  200000000 size 1024 MB
Probing I/O buses

Based on the fact that it stopped working at “Probing I/O buses” and there was the possibility of an issue with the video card, I tried removing the card and booting headless.  In this configuration the system came up fine, with access from the serial port.

I eventually discovered that the issue was an impacted pin in the external dongle that splits the high density dual-dvi port in to two separate DVI ports.  The important note here for anybody searching for this issue is that when you have a video card in the machine, the last thing you will see on the serial console is Probing I/O buses since once it finds the video card, all future output is redirected to the video console.  So if you don’t get any output on the screen make sure to double check your video dongle, cables, and monitor!

Also, another unexpected behavior I ran into while troubleshooting- If I left the USB keyboard hooked to the machine while booting, it will assign that as the input device, and it won’t accept input on the serial console, even though that is where all output is going!  It is very odd typing on a keyboard and having your output go to a serial console…

-Eric

Categories: Sun Tags:

Host/System and Device/Router Naming Standards

May 21st, 2009 No comments

At each organization I am exposed to, it is interesting to see the various naming schemes that have been employed over time.  I most often find a hodgepodge of different naming standards that have been poorly followed.  Well thought out naming standards will make a huge difference in the ease of maintaining your environment.

So how should you come up with a device naming standard?  I won’t profess to give you a one-size-fits-all solution, but instead I will outline a number of the pitfalls to device naming that I have run into in order to help you devise your own convention.

Uses for a name

In IT, device names serve three primary roles:

  • They are a unique identifier used to define a device (note that a MAC address or serial number could be used as a unique ID, though it provides no other information about the device and is difficult for humans to work with).
  • When entered into DNS they provide an easy way to connect to a given device by typing in it’s name from scratch, or device names may be selected from a list in a program such as a SSH program.
  • When you see a device name in a log, or on a document it’s name should be obvious what the device in question is and convey to you critical information about the device.

Naming goals

  • Names should be as short as possible, easy to type and read, but with enough information to be unique and descriptive.
  • Make things as intuative as possible.  If you have an IT contractor working in your environment it should be pretty obvious to them what various servers do based soley on the machine names.
  • Your naming system should be flexible enough to allow for growth.

Naming structure

  • Generally you should start the name with the most significant identifier, and work your way through to the least significant identifier.   This makes sorting useful.
  • Think about how long should each field in the name be.  It needs to be long enough to hold unique entries for as many items of that type as will likely be utilized using the characterset defined for that field (i.e. if you have a two digit alpha field for site code, you can have a max of 676 sites, though if you want them to be intuative you probably don’t want to use the XZ designator) – a numeric only field has less options, 0-9 only yields 10 possibilities per digit.
  • Within a name you might choose to include delimiters between fields in order to seperate them, or just for stylistic reasons.  This makes names longer to type (and sometimes to long to fit in documentation, etc…), but they are often worthwhile from a readability standpoint.  PRF5A is a lot harder to read than PR-F5-A.  Most special characters are banned from device names, though dash “-” seems pretty well supported.
  • You can only have one variable length field in a name, unless you are using delimeters, or adjacent fields are obviously seperate since some are alpha only, and others are numeric only.
  • Note that not everything needs to have names of the same length – It is ok to name one server PDXFILE1 and another PDXSAN1.
  • Not everything needs to follow exactly the same nomenclature – routers and network hardware can follow one standard, while servers may follow another.  THIS IS OK!  As long as they don’t conflict…

Know your organization

  • Think about how your company will grow.  Might you ever have more than one VMWare server?
  • Unless there is no way your business will ever have more than one site (what if you were acquired) I highly recommend your names start with a site code (more on this below).
  • Not everybody has the same needs!  You don’t have to force the same scheme on every organziation!  A small manufacturering company has different needs from a global multinational.  You can get away with much simpler names in a small company than in a huge multinational corporation.

Who is your audience?

  • Names should be descriptive to your audience,  Who is your audience?  Users?  IT staff?
  • In an optimal world, machine names should not be seen by users.  In end-user facing situations I recommend using CNAME’s wherever possible to alias “service names” to “server names”. (i.e. webmail.bitplumber.net could be CNAME’d to pdxmail1.bitplumber.net.  Note that this often falls down in Windows since in Outlook for instance it insists on showing the user the *real* servername…  The same goes for file server names.
  • Internet facing services should never have users seeing the machine names.  They are likely connecting to a firwall and or load balancer first anyway so this is easy to hide.

High-level recommendations

  • Don’t name things non-sensical names, this is not 1990 (yeah, I know I broke this rule when naming plunger.bitplumber.net)
  • Avoid putting un-necessary junk in server names – I don’t really care what the model number of server is (in most cases), or even if it is a VMWare guest server or a physical server (this matters less and less as time goes on).
  • Don’t put a version number of software in the name as you will likely upgrade it! (I have seen servers named Win2k that are running Windows 2003 Server)
  • If the server might end up running multiple applications don’t put the name of one piece of software in the name, call it an application server or something…  (I have seen a server named backupexec that was running netbackup…)
  • In a software development shop (or even a non-software shop), you will likely have multiple copies of similar environments for testing purposes.  PRODUCTION, QA, DEVELOPMENT, STAGING , etc…  This is a good thing to include in the name as you typically have similar server names in each and you don’t want to inadvertantly make a change in Production when you intended to make it in QA.
  • Usually it makes sense to name services with a number on the end as you might have multiple servers performing the same function, or even if you only have a single server in that function you might move to another physical server later which you designate with a different number on the end.
    Many environments put two numbers on the end of servers, but how often do you really have more than 9 servers of the same type at one site?  It may be ok for some servers to have a single digit number on the end, while others have two digits.

Site codes

In most organizations I recommend the use of site codes as even single-site companies often end up with remote sales offices, disaster recovery datacenters, etc…

The goal with site codes is to choose a identifier that people both from the site in question, and others far away can easily identify as being related to a given location.  I have often struggled with this as there is no standard, and lots of potential for confusion and overlap.

You must decide how long you want your site codes to be.  I know Intel used to use two digit codes.  Many organizations choose three digit codes which conveniently enough corresponds with airport codes.

There are  a couple issues with airport codes however:

  • Some airport codes are not obvious which city they are in
  • You often times will have multiple sites within the serving area of a single airport

Note that not all site names have to be the same length (depending on your name structure).  At the last company I worked for I gave the large headquarters site in each region a three digit code, and then the smaller satellite sites got five character codes that began with the three digit region in which they were located.  i.e. PDX was the headquarters site and PDXPC was the Pacific Center satellite site.

A few other notes

Two situations to consider: Naming a device after a department, but that department moves elsewhere physically, but the device stays…  Or, naming a device after a building, but the company moves to another facility along with the device, and keeps the name.  Sometimes you must make a decision as to what a device will stay sticky with, the company/department, or the physical facility.

What is the timespan that your naming scheme must be good for?  I doubt a single site company is going to become a multinational overnight…  Your average IT device lasts 3-7 years so your naming scheme can easily change at replacement time to handle growth.

You might need to consider naming of devices with multiple network interfaces, each with different IP’s.

  • Windows is dumb and by default wants to register every interface with the same thing in DNS.  This can lead to issues if all networks are not directly reachable by all hosts accessing the device.
  • Solaris is interesting in that it wants each interface named differently.  In this case I recommend making the main server name map to the “primary” interface (i.e. probably the one you set the default gateway on) and then use <hostname>-xx for additional interfaces where -xx is something like -bk for backups, etc…
  • Routers should have different forward and reverse names for each interface, plus forward and reverse names for a loopback IP.  (i.e. fa0-0.plunger.bitplumber.net and fa0-1.plunger.bitplumber.net and just plain plunger.bitplumber.net for the loopback IP)

In one environment I have worked in we name all of our iLO, ilom’s, DRAC’s, etc…  <hostname>-SC (sc = service controller).  This makes it easy to go login to one in an emergency.  Just don’t accidentally cross the DNS entries or else you might power cycle the wrong box!

You must be careful not use special characters in device names.  Note that different devices and directory systems may have different “special characters”.  Think about Windows names, Unix names, router names, DNS names, WINS names, etc…  Each different type of name has different restrictions on what characters and symbols are allowed, and what the minimum and maximum lengths are.  Some names could be case sensitive, but most are not.

I personally find uppercase names easier to read in documentation and on screen, but that is in many cases a matter of personal preference, and in others may be enforced by the system in/on which the name is set (i.e. DNS).

IP addressing in relation to names

This is a topic worthy of another complete blog post, but I will point out just a couple of key recommendations here.

Since private ip address space is “free” and “plentiful” I generally build my subnets with plenty of IP space so that I can space machines widely and align their last number with their server number.  Most often I will use /23 subnets for servers and clients which gives me 512 IP’s (minus a few for network, broadcast, and default gateway).  As an example, you could have a server called PDXESX1 with an IP of 10.111.2.21 and another called PDXESX2 with IP 10.111.2.22, PDXESX3 as 10.111.2.23, etc…

On a somewhat unrelated note, in my oppinion the default gateway should always be the lowest usable IP in the range because it is intuative for anyone that follows after you.  Along these same lines, I am a fan of always making my DNS servers .11 and .12 in a given subnet (or .11 in one subnet and .11 in another subnbet).

Is this the right time to change?

Is change really needed?  Or is it simply change for change sakes?

The natural tendency for each new “owner” of a network is to want to do things their way with a naming standard that makes sense to them.  Don’t keep changing your naming schemes!  Even if the existing one is not perfect, it may be better overall just to leave it as is!

You generally don’t want to avoid changing a machines name after it has been set – the name gets referenced all over the place, and unless your process to change it is perfect, it will get missed somewhere and cause confusion down the road…  Think about all of the places you might have to change the name:

  • On the machine itself (hostname, hosts files, application configurations…)
  • In your ip address spreadsheets
  • In your inventory system
  • In DNS entries (including CNAME’s that reference the host name)
  • On the labels stuck to the machine physically
  • Your labels in the network switch (and supporting documentation)
  • Labels on the cables attached to the server – network, power, etc…
  • In your monitoring software
  • On your kvm switch
  • In description fields on your remote power cycle device (PDU’s) 
  • On your network diagrams and documentation

Final thoughts

While this may be a bit overwhelming, it is crucial to consider all of these aspects ahead of time in order to avoid needing to change your standard down the road.  I hope this has given you an overview of many of the pitfalls of naming I have run into during my career such that you can avoid the same mistakes!

As always, if you have any additional comments, feel free to post them here, or shoot me an email and I may include them in a future post.

-Eric

Categories: Uncategorized Tags:

Cisco ASA 5510 8.2 AnyConnect License Price ASA-AC-E-5510

May 13th, 2009 5 comments

As a follow-up to a previous post, I am happy to report that Cisco has finally posted the bits to the ASA 8.2 code online for download.  I have been looking forward to this, as this release includes a new license model for the AnyConnect VPN client called “Cisco AnyConnect Essentials”.

While I still can’t find any written reference (on the Cisco price list or elsewhere) for how much the AnyConnect VPN client is going to cost, I have confirmed that the previous rumor of it being “next to free” is indeed true.  Cisco is only charging $150 for the AnyConnect VPN Essentials license on a 5510 which will give you up to 250 simultaneous users!  (that is about as close-too-free as Cisco gets)

This is the answer you are looking for to deal with 64 bit client support!  A coworker of mine even told me today that the AnyConnect client works in his Windows 7 Beta 2 machine (which surprised me, I suspect under-the-hood the Windows 7 networking stack is very similar to Windows Vista).

The part number you need for an ASA 5510 is ASA-AC-E-5510=.  If you need the part numbers for other models check out the release announcement.

There is some reference in the release notes to possibly needing more ram in the ASA 5510 platforms (I am not yet sure if this will impact me, I am not doing a ton of stuff on my ASA 5510 but yet I run near 80% RAM utilization on version 8.0.4).  It is worth noting that there is annoying footnote that says the 256 -> 512 meg of RAM upgrade won’t be available till June…

Also, I have been told that the Botnet detection feature will be $460 a year.  This is part number ASA5510-BOT-1YR= for the ASA 5510.

I will write up another post once I install the 8.2 code somewhere.

-Eric

UPDATE: 5/18/09

I am getting conflicting information from my VAR than I got directly from Cisco.  They say MSRP is $350 right now and it won’t be available till late this month or early June.  CDW has it posted for $232.99 without any special pricing discounts you may have with them.  Availability says to call…

UPDATE: 5/29/09

The CDW site now shows that the ASA-AC-E-5510 part is $101.99.  It still says availability is “call”…

And for those of you looking for the part numbers you need to purchase the AnyConnect Essentials for your model of ASA, here they are:

  • AnyConnect Essentials VPN License – ASA 5505 (25 Prs) – ASA-AC-E-5505=
  • AnyConnect Essentials VPN License – ASA 5510 (250 Prs) – ASA-AC-E-5510=
  • AnyConnect Essentials VPN License – ASA 5520 (750 Prs) – ASA-AC-E-5520=
  • AnyConnect Essentials VPN License – ASA 5540 (2500 Prs) – ASA-AC-E-5540=
  • AnyConnect Essentials VPN License – ASA 5550 (5000 Prs) – ASA-AC-E-5550=
  • AnyConnect Essentials VPN License – ASA 5580 (10K Prs) – ASA-AC-E-5580=
Categories: Cisco, Network Tags: