My score:  930/1000.

However, one interesting thing I noticed in the article was the absence of a differentiation between how the VLAN.dat file can be deleted on a Catalyst 6500 series switch and how it is deleted on a 4500 series switch. In my experience the two are not the same.

I have tried to use the delete command on a 4500 series switch without success. The command executes and a access denied error is returned (if my memory serves). The only way to delete the VLAN.dat file on this platform is to erase the cat4000_flash volume. This will clear the file.

So, the full command is:
erase cat4000_flash:

One thing to note is that the erase command was tested on the pre-E-Series 4500 platform. I have not tested it on the E-Series hardware.

We use this command when all the switchports on an Access switch are fully patched to the floor and we need to make room to plug in additional devices. This means pulling out existing patched cables which have not been used in over six weeks.

We used this command successfully on our 4500 series switches. They have since been replaced with 4500-E series switches and we have yet to test on these.

The Cisco Whitepaper can be found here:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml

The idea is to remove the need to perform patching from patchport -to-switchport whenever a new server or device is connected into the rackport. It also removes the requirement for staff to have to physically trace links from patchport-to-switchport.

So, what do I mean? Take a look at our work.

Our access level switches are Cisco 3750 E-series devices, six per switch stack. Our uplinks are 10Gbit GBICs, one at the top and one at the bottom. The above pictures are of our initial testing. I’ll paste up images of our final fitout, which includes Nic1 and Nic2 switches.

The great thing about this system is that the server guys only need to perform a lookup on a laminated table to discover the patchport-to-switchport mapping.

Found in Extras, under Appearance.

The software comes as part of a lab, with over 150 exercises detailed in a PDF. Cisco initially released a CCENT version of the lab, with the CCNA component coming soon.

Check it out. I’m waiting on my copy to arrive, so will post some thoughts.

http://shouldhavegonewithcisco.com/2009/03/13/book-review-ccent-network-simulator/#more-122

For example, lets say you have an ip address of 10.28.18.56/26.

With the above technique, you would subtract 26bits from 32bits, to give you the number of host bits for the last octet, which is 6bits. Then multiply 2 to the power of 6, such that 2x2x2x2x2x2 = 64. This means each subnet contains 64 IP addresses, including the subnet address and the broadcast address.

You can then divide 256 (0 – 255 for the octet) by 64, to give you four subnets. Or, you can calculate 0 – 63 for the first subnet (even though we are using whole chunks, such as 64 and 256, each octet starts from zero and goes to 255), 64 – 127 for the second subnet, 128 – 191 for the third subnet, and 192 – 255 for the fourth subnet.

So, the final subnet numbers (where each subnet STARTS) is:

10.28.18.(0-63);
10.28.18.(64-127);
10.28.18.(128-191);
10.28.18.(192-255).

Now, if you tried to subtract 192 from 255 you would get a chunk of 63, which is incorrect because 192 is included in the fourth subnet. You have to subtract 191 from 255, to get the last chunk of 64.

Remember that each octet is just a simple counter from 0 to 255 (256 or eight bits – 2x2x2x2x2x2x2x2). Each octet does not influence the counting of the neighbouring octets, other than a simple number x number calculation. For example.

Lets take another look at the ip address 10.28.18.56. This is a purely arbitary number, by the way, in that in and of itself it has no inherent meaning – it’s just a number. When you add to this number a subnet mask, lets say 255.255.192.0 (/18) - same ip address with a different subnet mask, you still only have an arbitary number, yet now you can get some idea of how the number might relate to other numbers in the same network. This is really all there is to addressing. The significance comes from how the number fits within the scheme.

The relationships of IP addresses is purely contrived to create patterns, to represent a logical hierarchy for whatever scheme has been designed. There are no advanced formulations involved in IP addressing. Just patterns of arbitary addresses made up from four blocks of bits, each block a limited range of binary, 0 – 7 bits.

If we take 10.28.18.56/18 we can see that if we subtract 18 (network) bits from 32 bits, we get 14 (host) bits, which puts 8 host bits in the fourth octet and 6 host bits in the third octet:

11111111.111111111.11000000.00000000

Firstly, this new subnet mask shifts the subnet/host division from the previous number’s fourth octet to the new number’s third octet. However, like the previous example, this example also has 6 host bits in the divided octet. So, what we do is ignore the octets on either side and focus just on the divided octet.

Then just apply the same calculation as for the previous number. This results in four 64 address chunks in the third octet. So we end up with the following subnets:

10.28.(0-63).0
10.28.(64-127).0
10.28.(128-191).0
10.28.(192-255).0

So, 10.28.18.56/18 fits into the 10.28.0.0 subnet. The 10.28.0.0 subnet has 64 x 256 (16,384) ip addresses available. Each of the other three networks also has 64 x 256 addresses.

We can look at the host portion of each of the four subnets in this way: 0.0.64.256. Each dotpoint between each octet can be seen as a simple multiplier. If the third octet was made of 64 networks, each network would consist of four ip addresses, giving 4 x 256 (1,024) hosts for each of the 64 networks. The first two octets cannot be changed and so stay as 10.28.

In fact, here is an excellent video which details this exactly (although it goes into things in a bit more detail, in that it also looks at determining the number of subnets from the network bits – rather than by calculating the host bits first and then dividing the octet to determine how many times the chunk of hosts will fit – I find it is just easier to work out the number of hosts go from there in your head):
http://www.cisco.com/web/learning/le31/le46/cln/clp/fastlane/Subnet_Calculator/index2.htm

It’s dead simple. But, it does require an understanding of binary numbering.

Writing out the chunks of 4, 8 and 16 (2,3 and 4 bit positions) over and over, with each one along side one another, really helps you to pick out where a subnet begins when looking at an IP Address. It is also a good idea to write them out by hand, as this seems to imprint it in memory a little better.

0      0    0
4
8      8
12
16    16   16
20
24    24
28
32    32   32
36
40    40
44
48    48   48
52
56    56
60
64    64   64
68
72    72
76
80    80   80
84
88    88
92
96    96   96
100
104  104
108
112  112  112
116
120  120
124
128  128  128
132
136  136
140
144  144  144
148
152  152
156
160  160  160
164
168  168
172
176  176  176
180
184  184
188
192  192  192
196
200  200
204
208  208  208
212
216  216
220
224  224  224
228
232  232
236
240  240  240
244
248  248
252
256  256  256

In an enterprise network, where technology is required to simplify the requirement for people and process, the Cisco ATA product does, in fact, do the opposite. Their ATA requires excessive setup, both in its configuration and physical deployment, and requires far too much work whenever an attached end-device is relocated.

Cisco’s solution, for “legacy” devices such as Faxes, is itself a legacy device. It is bulky, relatively heavy, forces two end- devices be connected instead of one, and (and, this is a big one) does not utilise POE and must use a separate power supply adapter and localised power cable.

 The ATA must be placed in the communications room, due to the fact that they aggregate two devices into a single ethernet port, which means they cannot be deployed inline with the end device out on the floor. Power outlets must be available in the Comms room for the external power adapters to plug into. The ATAs cannot be secured in a rack and are designed to sit on a desktop, so they take all available surfaces and clutter the Comms room with their bulky enclosures and cumbersome external power bricks and excessive lengths of cable. They require additional patch cables to cross-connect from the RJ-12 ports on the ATA to the RJ-45 ports in the patch panel (which then goes out to the device on the floor).

Because they must reside in the communications room, they are disassociated from the devices they are servicing. This means desktop staff cannot relocate the ATA unit when they relocate the end device (remember, the second end device connected to the ATA will likely not be required to be relocated). So, they must be mindful of this and go through a convoluted process, requiring staff to unpatch the “cross-connecting” patch in the Comms room (so that it is clear to staff in the future that the port is unused and available), reconfigure the old port if the end-device must take the phone number with it, and then ensure there is an ATA available in the Comms room at the new location for the relocated end device.

Why not just have a simple inline ATA that draws power from the POE switch and can be relocated with the end device?

If you use an alternative to Cisco’s ATA solution that uses POE and can be used inline per device, please post your experiences or contact me directly. In the mean time, I will post any findings.

Why use a clumsy launcher, which then opens a browser window, which then opens another two browser windows? You then get asked for basic credentials (which you have to cancel), then SSH credentials. And, often it just doesn’t accept the credentials and simply presents the dialog again.

The whole program smacks of hacks and a dodgey design approach. I don’t configure line passwords, and I don’t want to use SDM to preconfigure a virgin device. Just let me connect to any device, in any state and use any password I want. I don’t need its auto-magical non-sense. Sigh.

And if I don’t have HTTP server enabled (who in their right mind does this, really?) then use HTTPS like the good option says.

The other thing, SDM says it will use the default browser, yet even though I have Chrome as my default, it still insists on using IE7.

And, what about Cisco’s Network Assistant? Looks like it is a better piece of kit (I haven’t had a chance to check it out fully, yet) even though it appears it is for switch configuration only.

I think Cisco could learn a thing or two about configuration application design, usability and integration from Microsoft (which is saying a lot, because Microsoft aren’t exactly usability experts).

CLI FTW, I think.