SSL Certificate Export in NetCache

KEY CONCEPT:
SSL Certificates do not work on its own. It requires the corresponding Key (i.e., the Key used to create the CSR in the first place) to be validated.

The NetCache appliance does not have an SSL Key and Certificate export capability. This is a very important consideration with possible financial impact: any User Certificate (paid for by you to any public Certificate Authority or CA) created from a Certificate Signing Request (CSR) from this NetCache appliance can be used for this device only.

Since this device cannot export out the Key, the new User Certificate cannot be used in any other devices in the network. If there are multiple devices in the network requiring a particular certificate, you could possibly be paying more; one for the SSL cert fo this NetCache appliance and at least one more SSL cert for the other devices.

WORKAROUND:
There is actually no other workaround or fix for this except to NOT use the NetCache appliance to generate the Certificate Signing Request (CSR). Use other network devices, if any, such as F5 BIG-IP, Cisco ASA, and others. Note that although the NetCache appliance cannot export out, it can import in SSL Keys and Certificates.

PERMANENT FIX:
Check with the NetCache website for the latest releases to verify if and when this product limitation is addressed.

Case Study: D51 BIGIPv9 cannot be accessed via Web User Interface

Device:
Hardware: BIG-IP 5100 (D51)
Software: BIG-IP 9.2.3 Build 34.3

Problem / Symptoms:
- Device access via the GUI results in a page containing only "Configuration Utility is restarting";
- Device access via SSH and console works as expected.

Error Messages Encountered:
- GUI: Only message is "Configuration Utility is restarting" and that's it;
- SSH/Console: repeatedly gets the message "tomcat4 can't start because /var is at 100%"

Root Cause:
Most UNIX (Linux)-based network devices use Tomcat as the webserver, which then enables any web-based service (in this case, the Management GUI) on the device.

In this case, an existing bug in the current OS version causes the system to create jar_cache files which accumulates in the /var/cache/tomcat4/temp directory, which may eventually lead to the Java Virtual Machine (JVM) halting unexpectedly.

As in this case, the 100% of the /var partition has been used up.

Workaround:
1. Login (via SSH or console) into the device. As soon as you login, you should see the tomcat4 failing to startup messages such as the following:

Jun 19 11:04:40 x81glx04 LOGIN: tomcat4 can't start because /var is at 100%.
Jun 19 11:04:50 x81glx04 LOGIN: tomcat4 can't start because /var is at 100%.
Jun 19 11:05:00 x81glx04 LOGIN: tomcat4 can't start because /var is at 100%.

2. Verify the available drive space using df:

[root@MyBigIP:Standby] config # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda5 373652 294142 60217 84% /
/dev/hda7 57481 7688 46825 15% /config
/dev/hda8 47900 47456 0 100% /var
none 190508 5828 184680 4% /shared/rrd.1.0
none 190508 40 190468 1% /dev/shm
none 190508 1356 189152 1% /var/tmpfs
[root@MyBigIP:Standby] config #

You can check the actual space used up by the /var/cache/tomcat4/temp directory using the du command:

[root@MyBigIP:Standby] config # cd /var/cache/tomcat4
[root@MyBigIP:Standby] tomcat4 # du -h
204K ./temp
1.0K ./work/Standalone/localhost/tmui
2.0K ./work/Standalone/localhost
3.0K ./work/Standalone
4.0K ./work
209K .

3. Stop the tomcat4 daemon: bigstart stop tomcat4

4. Delete out the files in /var/cache/tomcat4/temp directory. Alternatively, using any SFTP application such as WinSCP, copy out the jar_cache files, in case your vendor wants to take a look at them.

5. Restart the tomcat4 daemon: bigstart start tomcat4

6. Verify the disk space available using df:

[root@MyBigIP:Standby] cache # df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda5 373652 295704 58655 84% /
/dev/hda7 57481 7711 46802 15% /config
/dev/hda8 47900 24600 20827 55% /var
none 190508 5828 184680 4% /shared/rrd.1.0
none 190508 40 190468 1% /dev/shm
none 190508 1356 189152 1% /var/tmpfs
[root@MyBigIP:Standby] cache #


Permanent Fix:
BIG-IP version upgrade.

References:
SOL7361: The BIG-IP system can create an excessive number of jar_cache files, filling up the /var directory (requires F5 login)

Trunking vs Etherchannel

Your Ad Here

Noticed several colleagues of mine are still confused with "trunking" and "etherchannel". These two -- some would argue grammatically similar -- have very different functions and implications.

Trunking refers to (multiple) VLANs that are going through an interface. That is, for example, if you say that "a Cat6500 with GigabitEthernet1/1 trunks VLANs 1, 50, and 100", it means that these VLANs (and only these VLANs) are permitted to go through Gi1/1. The implication is that this forms a basic security feature, by permitting only specific VLANs; other traffic belonging to other VLANs will be permitted on this trunk interface.

Etherchannel -- aka channel-group, port-channel, or port group -- on the otherhand, refers to multiple (physical) interfaces bundled together into a single (logical) interface. That is, for example, if you say that "Cat6500 Port-channel100 includes GigabitEthernet2/1-4", these means that Gi2/1 to Gi2/4 are configured together as a single logical interface. The implication is that the bandwidth of these interfaces are combined and shared -- hence, in this example, Port-channel has a total bandwidth of 4Gbps (1Gbps per interface x 4 interfaces ).

So to state the basic difference between the two:

Trunking "bundles" VLANs together that are permitted on any single interface.
Etherchannel "bundles" (physical) interfaces together into a single logical interface.


Question: Can you combine an interface to have both trunking and etherchannel?

Answer: This is question is a little vague. In a way, yes. Here's a typical scenario actually being used in many companies:

Topology:
DeviceA. GigabitEthernet1/1 <=====> DeviceB.GigabitEthernet1/1
DeviceA. GigabitEthernet1/2 <=====> DeviceB.GigabitEthernet1/2

Requirement:
Permit only VLANs 100 and 200 through the link between DeviceA and DeviceB. Also, increase the link bandwidth between these two devices to 2Gbps. To summarize:

DeviceA.GigabitEthernet1/1 - trunking for vlans 100 and 200, share bandwidth with Gi1/2;
DeviceA.GigabitEthernet1/2 - trunking for vlans 100 and 200, share bandwidth with Gi1/1;

DeviceB.GigabitEthernet1/1 - trunking for vlans 100 and 200, share bandwidth with Gi1/2; DeviceB.GigabitEthernet1/2 - trunking for vlans 100 and 200, share bandwidth with Gi1/1;

To achieve this, we arbitrarily assign a channel group number IDs. For this example, we select 300 for DeviceA, so we have Port-Channel300 which will group Gi1/1 and Gi1/2. The basic configuration for DeviceA, then, would look like the following:

interface GigabitEthernet1/1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
channel-group 300 mode desirable
!
interface GigabitEthernet1/2
switchport switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
channel-group 300 mode desirable
!
interface Port-Channel300
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
!

The device on the remote end, DeviceB, should be configured similarly as well.

Similarly, we select Port-Channel500 for DeviceB.

interface GigabitEthernet1/1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
channel-group 500 mode desirable
!
interface GigabitEthernet1/2
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
channel-group 500 mode desirable
!
interface Port-Channel500
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100,200
!

With that, you're done!

Here are some points you should take note of:

Important Note #1: The channel-group ID only has local significance. In this example, DeviceA assigns Port-channel300 while DeviceB uses Port-channel500.

Important Note #2: The VLANs trunked on the port-channel interface and the member interfaces should match. If there is a mismatch, the status of the interfaces will be down.

Important Note #3: The actual syntax would vary, depending on the IOS image currently being used. Here's a general hint: IOS 12.0 uses the "port group" interface command, while IOS 12.1 onwards uses the "channel-group" interface command.