Wednesday, May 27, 2009

Flags Displayed by the show conn detail Command

Connection Slot Flag

Description

U

Up

f

Inside FIN

F

Outside FIN

r

Inside acknowledged FIN

R

Outside acknowledged FIN

s

Awaiting outside SYN

S

Awaiting inside SYN

M

SMTP data

H

HTTP get

T

TCP SIP connection

I

Inbound data

O

Outbound data

q

SQL*Net data

d

Dump

P

Inside back connection

E

Outside back connection

G

Group

p

Replicated (unused)

a

Awaiting outside ACK to SYN

A

Awaiting inside ACK to SYN

B

Initial SYN from outside

R

RPC

H

H.323

T

UDP SIP connection

m

SIP media connection

t

SIP transient connection

D

DNS

Flags Displayed by the show xlate detail Command

 Flags Displayed by the show xlate detail Command

Flag

Description

s

Static translation slot

d

Dump translation slot on next cleaning cycle

r

Portmap translation

n

No randomization of TCP sequence number

o

Outside address translation

i

Inside address translation

D

DNS A RR rewrite

I

Identity translation from nat 0

Base Config: ASA WebVPN

This is becoming a common configuration for me. Here's a base template I use:

ip local pool WebVPNPool 192.168.251.10-192.168.251.100 mask 255.255.255.0

webvpn
enable outside
svc image disk0:/anyconnect-win-2.3.0254-k9.pkg 1
svc image disk0:/anyconnect-macosx-i386-2.3.0254-k9.pkg 2
svc enable
tunnel-group-list enable

group-policy WebVPNPolicy internal
group-policy WebVPNPolicy attributes
dns-server value X.X.X.X
vpn-tunnel-protocol svc 
group-lock value WebVPNAccessProfile
split-tunnel-policy tunnelspecified
split-tunnel-network-list value Split_Tunnel_List
default-domain value business.local
address-pools value WebVPNPool
webvpn
svc ask none default svc
hidden-shares none
file-entry disable
file-browsing disable
url-entry disable

tunnel-group WebVPNAccessProfile type remote-access
tunnel-group WebVPNAccessProfile general-attributes
default-group-policy WebVPNPolicy
tunnel-group WebVPNAccessProfile webvpn-attributes
group-alias WebVPN enable

ASDM error: Unconnected sockets not implemented

Hey everyone, I know it's been a long while since my last post, but I promise to try to make more frequent posts.

One thing I noticed today was that I couldn't launch Cisco's ASDM from my laptop running a clean install of Vista SP1. I noticed the same error on my desktop at work as well, right after login, I'd get this:

ASDM is unable to continue loading. Click OK to exit from ASDM.
Unconnected sockets not implemented.

I was trying to connect to an ASA5505 and an ASA5510, both running 8.0(2) and ASDM 6.0(2). Well after half an hour of research, and not finding a fix, I started troubleshooting on my own. I found the problem to be the Java runtime version I was using. It seems ASDM is incompatible with JRE 6u10. I uninstalled it and installed JRE 6u7 and then ASDM came right up with no errors.
So there you go, if you're running Vista SP1, ASDM will not work with JRE 6u10, try 6u7 instead.
-Rick Estrada

EDIT 2008/11/26@08.14
I had a question about where to download JRE6u7, so here it is:
Go to this page, and click the "Download JRE" link, then select your platform and language, and you should be presented with the online and offline installers.
Also, remember to disable automatic updating of your Java engine by going to "Control Panel" > "Java" icon > "Update" tab > and uncheck "Check for updates automatically". The "Java" icon appears in the control panel only when it is in "classic view", both in XP and Vista.
-Rick Estrada

Base Config: ASA Site-to-Site VPN

It doesn't matter how many times I've done this, I always forget one piece. Here's a template for the future:

Assume local subnet 192.168.15.0/24, remote subnet 192.168.16.0/24. Remote public IP 11.11.11.11.

crypto isakmp enable outside
crypto isakmp policy 10
 authentication pre-share
 encryption aes
 hash sha
 group 1
 lifetime 28800

access-list REMOTE_SITE ex permit ip 192.168.15.0 255.255.255.0 192.168.16.0 255.255.255.0

crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac

crypto map OUTSIDE_MAP 20 match address REMOTE_SITE
crypto map OUTSIDE_MAP 20 set pfs group1
crypto map OUTSIDE_MAP 20 set peer 11.11.11.11 
crypto map OUTSIDE_MAP 20 set transform-set ESP-AES-128-SHA
crypto map OUTSIDE_MAP 20 set security-association lifetime seconds 28800
crypto map OUTSIDE_MAP interface outside

nat (inside) 0 access-list REMOTE_SITE

tunnel-group 11.11.11.11 type ipsec-l2l
tunnel-group 11.11.11.11 ipsec-attributes
 pre-shared-key ***

Vendors on flow control

Hewlett-Packard says...

Flow Control was originally invented to prevent packet drops by switches that were running at less than media-speed. At that time the method of control was usually back-pressure. This was not a standardized method, but was effective in preventing any data loss. It also could substantially lower overall throughput through the segments being flow controlled. And core switches and routers did not use it.

Now there is a standardized means of flow control in IEEE 802.3x. It doesn't change the debate, however, as to whether it should be implemented in a core switch. It is actually more detrimental to flow control in the core than helpful. Flow control in the core can cause congestion in sections of the network that otherwise would not be congested. So how do you decide which segments to hold off when one of the segments gets congested? Even a network manager familiar with the traffic patterns of his/her network would, in many cases, be hard pressed to answer this question due to the dynamic nature of network traffic. And if particular links are constantly in a congested state, there is most likely a problem with the current implementation of the network.

The best way to handle any potential congestion in the backbone can much better be answered through CoS/QoS controls that many core switches, such as the HP ProCurve Routing Switch 9304M, have implemented. Prioritizing packets through multiple queues (the 9304M has 4 queues) provides far more sophisticated traffic control (such as targeting specific application packet types) than an all-or-nothing, or even a throttled form of flow control. CoS/QoS can provide policy-based traffic shaping and guarantee that the proper traffic gets through in cases of temporarily limited bandwidth. This sophistication is becoming more important as different emphasis is placed on differing types of traffic.

The one area where flow control can add value is in an edge switch, such as the HP ProCurve Switch 4000M. At this point in the network, the singular clients can be held off without potentially affecting large areas of the network. Flow control can be useful, for example, if the uplink is being swamped by individual clients. Even here, though, CoS/QoS will become more important over time. The 4000M supports tagging and can convert IP/TOS priorities to 802.1Q priorities and can set these parameters for multiple switches at a time through TopTools, our network management application that ships with each managed product. HP will continue to develop these capabilities over time, making 802.3x largely irrelevant in the future.

  

Cisco says...

The IEEE 802.3x Task Force defined Ethernet flow control, aka "Pause Frames", in 1997 as an optional clause of the specification for full duplex Ethernet. The IEEE 802.3 Ethernet standard does not require implementation of Ethernet flow control to be completely standards compliant.

The problem Ethernet flow control is intended to solve is input buffer congestion on oversubscribed full duplex links which cannot handle wire-rate input. The Cisco products tested, the Catalyst 2948G and Catalyst 8510 are both non-blocking, shared-memory devices, and therefore would never issue Pause frames since:

(1) They can sustain wirespeed throughput on all ports, so none of the links can become oversubscribed from input traffic, which is the problem Ethernet flow control is intended to solve.

(2) There are no "input buffers" to become congested. The test used tries to force a port to send Pause frames by putting it into a head-of-line blocking configuration. By definition, there is no "head-of-line blocking" in these products. This is one of the fundamental advantages of shared memory architectures.

Ethernet flow control is not intended to solve the problem of steady-state overloaded networks or links. Unfortunately, perhaps the only feasible way any network-based test can "force" a device under test to issue a Pause frame is to put it into exactly this situation. The port being tested is usually put it into a "head-of-line blocking" situation to simulate congestion. Typically this is achieved by oversubscribing a separate output port to which the port under test needs to send traffic. It can be argued that what the test primarily demonstrates is that the device under test is subject to head-of-line blocking. This test doesn't apply to non-blocking shared memory devices which are, by definition, not subject to head-of-line blocking.

If an output port is oversubscribed, having separate input ports issue Pause frames, and potentially cause blocking on other network devices by backward propagation of Pause frames, is not an appropriate long-term solution. For this reason, it can be argued that Pause Frames should not be used in a network core where they could potentially cause the delay of traffic unrelated to the oversubscription of a link. The right solution is to redesign the network with additional capacity, reduce the load, or provide appropriate end-to-end Quality of Service to ensure critical traffic can get through.

Ethernet flow control is also not intended to provide end-to-end flow control. End-to-end mechanisms, typically at the Transport Layer are intended to address such issues. The most common example is TCP Windows, which provide end-to-end flow control between source and destination for individual L3/L4 flows.

An example of where Ethernet flow control might be used appropriately is at the edge of a network where Gigabit Ethernet attached servers are operating at less than wirespeed, and the link only needs to be paused for a short time, typically measured in microseconds. The use of Pause frames to manage this situation may be appropriate under such circumstances.

Unfortunately, Ethernet flow control is commonly misunderstood. It is not intended to address lack of network capacity, or end-to-end network issues. Properly used, Ethernet flow control can be a useful tool to address short term overloads on a single link.

 

Foundry says...

The interoperability test highlighted both aspects of flow control mechanics; responding to (throttling) and transmitting flow control frames. Only a few test ports were actually used in this portion of the test. All Foundry Networks products are 802.3x compliant and implement flow control but will only generate flow control messages when total system resources rather than an individual buffer for a given port are almost depleted. This protects the rest of the device (and the network) from a problem that could be caused by a single port. Due to the BigIron's switched shared memory architecture, consuming the system resources requires more test equipment than was actually available for this particular phase of the Interoperability Test. Had there been enough traffic generation ports to consume the system resources, the BigIron would have generated flow control messages.

 

 

Tuesday, May 26, 2009

Enabling CDP on Vswitch

Enabling CDP on ESX for a vSwitch.

There is no GUI for enabling or disabling CDP for a vSwitch (yet), so it’s off to the CLI.

esxcfg-vswitch --set-cdp both vSwitch0

Replace the italicized parts of that command with the appropriate information for your environment. That sets CDP to both listen (receive CDP transmissions) and announce (send CDP transmissions). I recommend using both, although I have not currently found a way to explore the CDP information that ESX is gathering by listening to announcements.


Enabling CDP on ESXi for a vSwitch.

 Of course, since we are using ESXi there is no Service Console, so this time we’ll have to rely upon the next-generation equivalent of VIMA.

The command from next-gen VIMA looks like this:

vicfg-vswitch --server vcenter.domain.com -h esxi.domain.com -B bothvSwitch0

Unless you’ve set some environment variables, you’ll be prompted for username and password. I substituted the “-h” for “-−vihost” and “-B” for “-−set-cdp”. Again, you’ll need to replace the italicized portions with the appropriate information for your environment. I did find that using IP addresses didn’t seem to work well; I had to use fully-qualified domain names instead. 

Thursday, May 21, 2009

ESX Commands

vmware-cmd  -l =To get a list of all VMs and there paths

 

vmware-cmd //server.vmx getstate = Check the VM state

 

vmware-cmd //server.vmx stop soft = Proper stop type

 

vmware-cmd //server.vmx stop hard = To forcibly stop

 

vmware-cmd //server.vmx start = To power on VM

 

Vmware-cmd –s register/vmfs/volumnes/esx:storage1//.vmx  == To register the VMs



Entering ‘vmware-cmd‘ will provide the following output:

Usage: 

/usr/bin/vmware-cmd

/usr/bin/vmware-cmd -s


Options:

Connection Options:

-H specifies an alternative host (if set, -U and -P must also be set)

-O specifies an alternative port

-U specifies a user

-P specifies a password


General Options:

-h More detailed help.

-q Quiet. Minimal output

-v Verbose.


Server Operations:

/usr/bin/vmware-cmd -l

/usr/bin/vmware-cmd -s register

/usr/bin/vmware-cmd -s unregister

/usr/bin/vmware-cmd -s getresource

/usr/bin/vmware-cmd -s setresource


VM Operations:

/usr/bin/vmware-cmd getconnectedusers

/usr/bin/vmware-cmd getstate

/usr/bin/vmware-cmd start

/usr/bin/vmware-cmd stop

/usr/bin/vmware-cmd reset

/usr/bin/vmware-cmd suspend

/usr/bin/vmware-cmd setconfig

/usr/bin/vmware-cmd getconfig

/usr/bin/vmware-cmd setguestinfo

/usr/bin/vmware-cmd getguestinfo

/usr/bin/vmware-cmd getproductinfo

/usr/bin/vmware-cmd connectdevice

/usr/bin/vmware-cmd disconnectdevice

/usr/bin/vmware-cmd getconfigfile

/usr/bin/vmware-cmd getheartbeat

/usr/bin/vmware-cmd gettoolslastactive

/usr/bin/vmware-cmd getresource

/usr/bin/vmware-cmd setresource

/usr/bin/vmware-cmd hassnapshot

/usr/bin/vmware-cmd createsnapshot

/usr/bin/vmware-cmd revertsnapshot

/usr/bin/vmware-cmd removesnapshots

/usr/bin/vmware-cmd answer