Tuesday, November 11, 2014

Fibre Channel switching demystified at a basic level

Fiber Channel has been compared to Ethernet and for good reasons. Both are OSI L2 protocols, and both use globaly unique physical addresses, but not in the same way! While MAC addresses are always present in ethernet traffic, FC WWNs are quite a bit different.  They never appear in the FC headers.

Let's understand the underlying FC switching fabric first to put things in perspective. When multiple FC switches are connected together using E_ports, they form a switch fabric. The domain ID is unique to each switch in the fabric and there lies the first problem with scalability: only 239 are available. The lowest [PS_priority+WWWN] becomes the PS (principal switch). The PS selection process occurs when the E_ports are first connected, and the BF (the mundane sounding "build fabric") frames are exchanged. If two switches contain the same domain ID then the link between the two is "isolated". The domain id can be chosen at random, unless it is administratively set. This is required to generate the initial discovery traffic such as BF, EFP, SW_ACC frames. If you are really curious, the S_id and D_id (FCIDs) in these frames are always to set to 0xFFFFFD which is the fabric controller address.

So, given the 239 domain IDs in any given fabric, how to we break through the limit to scale up? Enter NPV or N-port virtualization. An NPV enabled switch does not take up a domain ID, but instead, relays the FLOGIs comming received on F_ports (from N_ports on hosts) up to the core switch via NP_ports. In other words, ports on the NPV edge switch that connect to the F_ports on the core are always set to type "NPV". NPV mode and Fabric mode are mutually exclusive, and a reboot is necessary when selecting either mode.

What is NPIV? N_port id virtualization is a feature that allows F_ports to accept multiple FLOGI requests from the same N_port and assign FCIDs accordingly.  Ask: are NPIV and NPV mutually exclusive on a any given device? Hint: NPIV is a server feature, while NPV is a switch feature, typically. Whether it is NPV enabled switch or a NPIV enabled host, the F_port essentially behaves the same and accepts multiple FLOGIs. So, an NPV enabled switch looks exactly like an NPIV enabled host to a F_port. Phew! Enough already, right?

So, how does FLOGI work? What is the initial FCID in the frame that comes out of an N_port going toward the F_port? Ans: 0x000000 - this is the initial value of the FCID, and this frame is sent to 0xFFFFFE which represents the FLOGI server. The payload contains the WWNN and service parameters. The FLOGI servers assigns the FCID (N_port ID) and BB_Credit.

Next, the host can use its newly acquired N-port ID to continue with the PLOGI process where it sends its WWPN to FCID map. The destination FCID is that of the FCNS: 0xFFFFFC. The FCNS now registers this information it its database and exposes this to other devices according to zoning that has been configured.

Try the command: "show fcns database" if you SAN uses a Cisco switch.

Monday, September 8, 2014

Troubleshooting CRC and input errors with Nexus 5000 in transit path

When you encounter CRC (input) errors on an upstream switch interface, and you have a Nexus 5000 in the transit path (downstream), MTU Stomping by the latter is likely a factor.

On a Nexus 5000 switch, when a frame is received on a 10 Gb/s interface, it is considered to be in the cut-through path.  If there is no "network qos" type policy with jumbo frame support, and the hosts connected this switch generate jumbo frames, we will encounter the following situation:

There are logical and physical causes for the Nexus 5000 to drop a frame. There are also situations when a frame cannot be dropped because of the cut-through nature of the switch architecture. If a drop is necessary, but the frame is being switched in a cut-through path, then the only option is to stomp the Ethernet frame check sequence (FCS). Stomping a frame involves setting the FCS to a known value that does not pass a CRC check. This causes subsequent CRC checks to fail later in the path for this frame. A downstream store-and-forward device, or a host, will be able to drop this frame.

"show queueing interface ethernet x/y" will reveal the hardware MTU.  This setting is enforced by the application of a "network qos" type policy-map under "system qos" section of running configuration.

Monday, April 21, 2014

IP subnetting unraveled

Consider the following address in CIDR notation: /13

1) What is the network address?

2) What is the broadcast address?

First, determine the subnet mask in dotted decimal notation:

Next, calculate: IP_Address AND Mask.  This reveals the network address as (NET_address)

Then, determine the wildcard mask (WC_mask) by inverting 1's and 0's in the subnet mask:

Finally, calculate: NET_address OR WC_mask, and this reveals the broadcast address:

Now, practice this method on /28 and if you are feeling adventurous, try /22

Monday, April 15, 2013

Wireless AP 1142 - Convert to controller based or standalone mode

If you are faced with the task of installing 1100 series APs into a controller environment but somehow "standalone" APs were procured, don't panic! Here is the fix:

1. Note the AP's IP address by "show cdp neigh detail"
2. http:// to the address to manage (Cisco/Cisco... case sensitive ID and pass!)
3. Go to the software tab and update to the correct image

If your controller is a hop or two or more away, don't forget to adjust DHCP option 43 and option 60 values!

Cisco 2600 AP - Convert to Stand-Alone mode

Follow these simple steps:

1. Download the stand-alone image from Cisco.com (.tar)
2. Rename the file to ...tar.default
3. Make sure you have a console connection to the 2600 AP - this will you verify the name of the file the AP expects to boot from using TFTP.
4. Change your IP address to /8
5. Run a TFTP  server on your laptop or PC
6. Plug the AP and your PC into two ports a switch that are in the same VLAN (no layer3 SVI necessary, I recommend creating a temporary VLAN such as 99 for example)
7. Make sure that the AP is connected to a PoE port if you don't have a power brick, BUT before you do that, press the MODE button and hold it down as the AP boots!!
8. Watch the console messages for the correct filename - ...tar.default should match exactly.
9. AP's LED will go blue and then after 15 seconds will go RED - you can let go of the MODE button now!
10. AP LED will blink green and it will intialize in stand-alone mode, and obtain a DHCP address.
11. You can manage it using http://

Friday, January 4, 2013

Cisco ASA: "LAND" attack - track false positves

A LAND attack is characterized by an IP packet whose source and destination IP addresses are the same. HOwever, sometimes on the ASA platform, it is possible to see false postives.

Consider the following example:

Jan 05 2012 16:21:36: %ASA-2-106017: Deny IP due to Land Attack from to

Jan 05 2012 16:21:37: %ASA-2-106017: Deny IP due to Land Attack from to

What is really happening?

Upon closer examination, you notice that you have static tranlation setup:

static (inside, outside)

Now let's capture traffic b/w the private address and translated IP, and lo and behold, the mystery is solved! The server inside is trying to access "itself via its public IP address" (perhaps via a script that is running).

3 packets captured

1: 16:20:37.032469 > S 1304500266:1304500266(0) win 5840

2: 16:21:36.938168 > S 4035860468:4035860468(0) win 5840

3: 16:21:37.173559 > S 4123968769:4123968769(0) win 5840

3 packets shown   Notice how the time-stamps match!

Tuesday, December 4, 2012

Load balancing across two ISPs with ASA

Ah! You are the security engineer at a medium sized bank, and perhaps you want to expand your Internet access to include a 2nd ISP. You are already paying $$ for the 10Mbps and now you are going to cough up even more $$$ for the new 25 Mbps service. Your websites and email servers are well set, and they are using static translations on the first ISP public address. How can you bring the 2nd ISP online, load-balance traffic across both links but preserve what you have built thus far?

You configure a select set of static routes (with SLA tracking if necessary) and this forces some outbound traffic off to the new link:

route outside-new x.x.x.x

Just select a few more of your favorite Internet targets.  You can enable the SLA tracking feature to add an element of dynamism!

and so on...

But, you notice that connections for the outside are not completing. You setup "logging console notifications" and observe uRPF drops! Now that's easy to explain: traffic to your static translations will come in via the old circuit but new more specific routes break uRPF on the ASA. The solutions is to check and disable "ip verify reverse-path" and Voila! you are back in business!