KICLet: Cisco UCS Socket Connect Error

I recently observed some strange behavior with Cisco UCS Manager. When I visited the web page that allows me to download the .jnlp file that launches UCSM, it came up just fine. But when I clicked on “Launch UCS Manager” to actually launch this applet, the splash screen showed briefly, but disappeared after a few seconds, never to be seen again. Eventually, you might also see some java error messages that say something like

KICLet: Cisco UCS Socket Connect Error

I recently observed some strange behavior with Cisco UCS Manager. When I visited the web page that allows me to download the .jnlp file that launches UCSM, it came up just fine. But when I clicked on “Launch UCS Manager” to actually launch this applet, the splash screen showed briefly, but disappeared after a few seconds, never to be seen again. Eventually, you might also see some java error messages that say something like

Cisco UCS Firmware Upgrade Explorations

I’m currently working with a relatively large Cisco UCS installation. Initially, the system was installed and brought up to relatively recent levels of firmware, but a mismatch in the way that the firmware packages were set up in various sub-organizations on some of the UCS systems caused some of the blades to retain the old version of firmware on the M81KR adapters and the CIMC controllers. Due to the scope of the installation, I wanted to ensure that the blades were able to continue operating while I made my changes.

Fabric stats: OP script for Mx platform

My previous post has presented an hidden command for analysing in real time fabric statistics. I've developed a small op script, for the MX platform, that provides in one command the PFE/Fabric IN/OUT statistics for all the Fabric Planes (0 to 5) for...

Fabric stats: OP script for Mx platform

My previous post has presented an hidden command for analysing in real time fabric statistics. I've developed a small op script, for the MX platform, that provides in one command the PFE/Fabric IN/OUT statistics for all the Fabric Planes (0 to 5) for...

Five Functional Facts about FabricPath

FabricPath is Cisco's proprietary, TRILL-based technology for encapsulating Ethernet frames across a routed network. Its goal is to combine the best aspects of a Layer 2 network with the best aspects of a Layer 3 network.

  • Layer 2 plug and play characteristics
  • Layer 2 adjacency between devices
  • Layer 3 routing and path selection
  • Layer 3 scalability
  • Layer 3 fast convergence
  • Layer 3 Time To Live field to drop looping packets
  • Layer 3 failure domain isolation

An article on FabricPath could go into a lot of detail and be many pages long but I'm going to concentrate on five facts that I found particularly interesting as I've learned more about FabricPath.

How does Openflow, SDN help Virtualization/Cloud (Part 2 of 3)

Using Openflow – state of the ART

In my last article I discussed the components of Openflow and building blocks of a Software Defined Network. In this part, let me discuss some of the things people are doing to make it all work. One of the pieces that needs to be discussed beforehand is the various ways in which a packet can be matched against a flow and what kind of actions can be taken.

Flow Classification and the split between Hardware and Software

A flow is a simple mechanism to identify a group of packets on the wire. So a packets coming from a particular machine can be identified by the machines MAC or IP addresses which appears as source MAC in L2 header or source IP in L3 header. By putting a flow rule around either of those fields and just counting the packets going through the switch that hit that rule, we can determine the number of packets being sent by the machine. Its useful information. To make it more useful, one could add another flow to measure the packets going to our target machine. Adding a destination MAC or destination IP rule based on the machines Continue reading

BRAS on Juniper MX

One of the latest features on the Juniper MX-series devices is the BRAS functionality. The first functionality (automatically configuring interfaces) has been available since a long time, but most BRAS features have been introduced last year in JUNOS 11.x releases. With JUNOS 11.4 (also a Long-Term-Support release) the features matured as all major components are now available and (fingers crossed) stable.

This functionality can be named in different ways. BRAS or Broadband Remote Access Server is the most common name. Other names are Broadband Network Gateway (BNG) or Broadband Service Router (BSR).

This functionality is used in Internet Service Provider environments usually where DSL or Cable is used as the last mile access.

The following drawing demonstrates how the end-to-end path looks and where a BRAS/BSR is placed.

The CPE (DSL/Cable modem) is connected to the Multi-Service Access Node (MSAN), this MSAN is either a DSLAM in case of DSL networks or a CMTS in case of Cable networks. The DSLAM and CMTS devices convert the signal to Ethernet (or any other transport) and forward it to the rest of the network. This connection is then terminated on a BRAS device before it enters the rest of the Continue reading

Vital Gadgets for a Datacenter Network Engineer

I would like to share some tips regarding gadgets that I believe every Datacenter Network Engineer should have with them. There are several, but I want to bring up my top two.ß Travel Router I am often in situations where it is either difficult or impossible to manage Nexus switches and/or UCS remotely. Pick your reasons - sometimes the management network doesn’t exist (yet) or there are heavy security measures in place that restrict wired management, whatever.

Vital Gadgets for a Datacenter Network Engineer

I would like to share some tips regarding gadgets that I believe every Datacenter Network Engineer should have with them. There are several, but I want to bring up my top two.ß Travel Router I am often in situations where it is either difficult or impossible to manage Nexus switches and/or UCS remotely. Pick your reasons - sometimes the management network doesn’t exist (yet) or there are heavy security measures in place that restrict wired management, whatever.

Fabric Stats

Small tips for analyse the fabric stats. I mean packets stats (IN/OUT/Drops) between each PFE and the Fabric. Usually fabric stats can be observe by using the following cli command. Remember, that there are only 2 streams at fabric level: High and Low...

Fabric Stats

Small tips for analyse the fabric stats. I mean packets stats (IN/OUT/Drops) between each PFE and the Fabric. Usually fabric stats can be observe by using the following cli command. Remember, that there are only 2 streams at fabric level: High and Low...

We don’t understand hashes

At least I don't, nor do I understand math. It only this week dawned to me, that we consistently choose wrong hash for password hashing.

When I started using Linux DES was the standard way to hash your passwd, then it was MD5, now at least Ubuntu is using SHA. And I can bet that in 2 years time SHA-3 (will be selected this year) will be used widely for protecting passwords.

But what were design goals for MD5 and SHA? Design goals are obviously avoidance of collisions and more importantly algorithmic cheapness in terms of computational requirements and ability to implement it cheaply and easily in hardware requiring no branching. So MD5 and SHA are _by design_ simple to brute-force in hardware, even the new SHA-3. You don't want your 'git commit' or 'sha3sum /dev/cdrom' to take days, you want it to be very very fast and very very unlikely to represent any other data.

It should be quite obvious that those requirements are orthogonal to the requirements of password hash. Avoidance of collisions is not critical to password hash and absolutely opposite requirement of computational expensiveness exists for password hash, it needs to be very expensive and it Continue reading

Silver bullet for home QoS

Rationale

I mentioned in one of the posts about how prioritizing small packets upstream is almost the proverbial silver bullet when it comes to QoS at home. I'm sure any ADSL user who uses interactive applications, such as SSH have noticed how laggy the SSH gets when you upload something from home, say your holiday pictures with scp to your web server. Also download is quite slow during upload. VoIP and online gaming will suffer too. Canonical solution is to use DSCP markings at sender end or DSCP mark based on IP address or port.

But I feel that is unnecessarily complex for typical home use scenario, since all of the important/interactive stuff are using small packets and the bandwidth hogging applications are all essentially doing MTU size packets. I've chosen <200B as small packet, which is arbitrary decision I did about decade ago when setting this up first time, I'm sure it could just as well be like 1300B. So without further rambling, I'll give IOS (ISR) and JunOS (SRX) examples how to roll this on your CPE.

IOS example

class-map match-any SMALL-PACKETS match packet length max 200 ! policy-map WAN-OUT class SMALL-PACKETS priority percent 75 class class-default fair-queue random-detect ! interface ATM0.100 point-to-point pvc 0/100 vbr-nrt 2000 2000 tx-ring-limit 3 service-policy output WAN-OUT ! !

JunOS example

[email protected]> show configuration interfaces vlan unit 0 family inet filter input FROM_LAN; [email protected]> show configuration firewall family inet filter FROM_LAN term small_packets { from { packet-length 0-200; } then { Continue reading