Start a Conversation

Unsolved

This post is more than 5 years old

13895

January 29th, 2015 10:00

Ask the Expert: SAN (Connectrix), FC Connectivity Recommendations and Best Practices

YOU MAY ALSO BE INTERESTED ON THESE ATE EVENTS...

Ask the Expert: Business Continuity; disaster recovery vs. data availability

Ask the Expert: Redefine Simplicity with VSPEX BLUE, IT that is Agile, Scalable, and Trusted

https://community.emc.com/message/862214

Welcome to this Ask the Expert discussion. This session will address the topic of “SAN (Connectrix), FC Connectivity Recommendations and Best Practices". We will discuss best practice in storage networks FC networks (SAN) with the goal to obtain better performance and optimal configuration. In addition, we will answer questions about administration, planning and SAN configuration.

Meet Your Expert:

profile-image-display.jspa?imageID=12613&size=350

Felipe Guijarro

Sr Field Support Engineer - EMC Spain

Felipe joined EMC in 2005 working as Customer Engineer. Since then he has performed different roles within the company (CE, MLS, S&D) and in 2010 he became part of the EMEA FSS community as Infrastructure connectivity specialist. Some of the products Felipe has experience with are: Connectrix, Cisco, Brocade, CLARiiON, Symmetrix, VPLEX, RecoverPoint, EMC Proven Specialist, Performance vSPEED.


This discussion takes place February 2 - 22. Get ready by bookmarking this page or signing up for e-mail notifications.


Alejandro también esta contestando preguntas en español sobre este tema, si prefieres hacer preguntas en este idioma dale clic a este vínculo: http://bit.ly/1zFiMS0


Share this event on Twitter or LinkedIn:

>> Join me! Ask the Expert: SAN (Connectrix), FC Connectivity Recommendations and Best Practices http://bit.ly/1tzfWuY #EMCATE <<

February 2nd, 2015 06:00

Welcome to our newest ATE session on ECN. We'd like to open this discussion for replies. Let's make of this an opportunity to respectfully engage our experts with your questions, comments or ideas. Have a great experience!

1 Rookie

 • 

20.4K Posts

February 2nd, 2015 08:00

Felipe,

Do you see a lot of customers adopting SmartZoning ?

Thanks

96 Posts

February 3rd, 2015 05:00

Hi dynamox ,

 

First off thanks for your query. The fact is that, although this feature is pretty useful, not many customers use it: mainly customers with a big SAN to manage take the step to introduce Smart Zoning.

 

For those of you who are not familiar with the concept of Smart Zoning, the following link provides a nice description of this feature introduced by Cisco in NX-OS 5.2(6).

 

By using Smart Zoning, the size and manageability of zonesets can be drastically decreased, specially when using clusters that share targets (storage ports) among several Initiators (server HBAs). With Smart Zoning, you can configure a single zone containing all the Initiators and targets in the same cluster (eg ESX farm) and the switch itself prevents the Initiators from seen each other even though they're in the same zone.

 

 

Rgds,

Felipe

1 Rookie

 • 

20.4K Posts

February 3rd, 2015 05:00

I don't have a big SAN (one 9513 core and a few 9148 edges) and i have been using SmartZoning for 2 years now. It is the best thing that has happened to zoning in a long time .  It was very easy to enable SZ on a running VSAN too,  "traditional zones co-exist with SmartZones in the same zoneset just fine.

5 Practitioner

 • 

274.2K Posts

February 4th, 2015 02:00

Hi Felipe,

a customer has upgraded to FOS 7.x, and needs to know if, with the new version, they still need to take care to manually config the parameter fillword to value = 3.

Thanks mate!

Manu

96 Posts

February 4th, 2015 08:00

Good evening Manu,

That's a good one, because there is a little bit of confusion with it. The answer to that question is:

  • 8G Switchs with Condor2/Goldeneye2 ASICs require to have the fillword parameter set manually, no matter what FOS release they're running.
  • 16G switchs (gen5) with Condor3 ASICs automatically set the correct fillword. Only FOS 7 is supported on these switchs.

The fillword is a FC primitive [in plain language, pre-defined frames] used to keep the link synchronized. It became renowned when Brocade introduced the family of switchs that supported 8G. When working at 8G, the FC standard states that the fillword to use is ARB (whilst previously it was IDLE). With 8G Brocade products, this fillword has to be manually configured and when Brocade released the new set of 16G switchs, the fillword is automatically configured, so in a few years time, we will forget about this parameter and live happily oblivious again.

When it comes to EMC products, the recommendation is to configure the fillword with a value of 3 when working at 8G.

Rgds,

Felipe

16 Posts

February 4th, 2015 13:00

Hello Felipe

What is the main benefits of using ISL trunking?

How does exactly load balance work with and without trunking license?

Also you mentioned smart zoning before. Is there any smart zoning analog in brocade san switches?

96 Posts

February 6th, 2015 02:00

Hello Alex.T ,

 

According to Brocade documentation The trunking feature optimizes the use of bandwidth by allowing a group of inter-switch links (ISLs) to merge into a single logical link....

 

In practice, the main benefit of trunking is that, it appears a single logical ISL, and this simplifies the routing tables inside the fabric, and most important, when there is a failure/activation of one of the ISLs, no new calculations need to be performed, and thus the traffic disruption is minimal. In the same situation, without trunking, there is a disruption until the routes are re-calculated.

 

When it comes to load balancing (and the use of bandwith) between switchs, it depends on the Routing policy configured on the switch. There are mainly 2 routing policies:

  • Exchange-based Routing: The choice of routing path is based on the Source ID (SID), Destination ID (DID), and Fibre Channel originator exchange ID (OXID),
  • Port-based Routing: The choice of routing path is based only on the incoming port and the destination domain.

 

Initially, when only port-based routing was available, if you had ,e.g 3 ISLs, you could have one of them heavily used whilst the other two were not used at all. In that case, trunking was very beneficial as it overtook that potential congestion situation by creating a 3-isl trunk. But since exchange-based routing was released, this situation disappeared and traffic is evenly balanced among all the ISLs. So, as far as load balance is concerned, trunking does not offer a big improvement.

 

If you meant the difference in load balancing withing the ISLs that form a trunk, with and without trunking licences, here there is indeed a significant difference:

  • when trunking is disabled, the traffic will be balanced among the ISLs depending on the routing policy used, normally exchange-base routing, and the load will be evenly distributed among them.
  • when trunking is enabled, the traffic inside the trunk won't be evenly distributed among the members: The trunk applies its own load balance algorithm and will start filling up one ISL and when it reaches certain threshold, traffic will be routed via another one, and so on if there are more than two ISLs.

 

Hope it answers your query.

 

rgds,

Felipe

52 Posts

February 7th, 2015 17:00

Why do we need more buffer credits on ISL ports compared to normal Host/Storage Ports ?

96 Posts

February 8th, 2015 02:00

Hi there koppuru 

 

 

Thanks for posting this question. I consider that there are 3 main reasons to have a larger number of buffer-to-buffer credits (BBC) on an ISL:

  • The first one is due to the distance, the longer the ISL is the more BBC it requires to keep the link full with frames.
  • The second one is that, internally, the ISL is logically divided into Virtual Channels (this only applies to Brocade switchs, Cisco switchs don't use this feature) and a certain amount of BBC is assigned to each Virtual Channel, increasing the number of required BBC to successfully work.
  • Additionally,we have to bear in mind that 99.99% of the frames that go through an ISL are going to a different destination other than the ISL itself, so the ISL has to keep the received frame until it can send it to the next step in the frame journey to its destination. By assigning more BBC we can improve the behavior and performance of the ISL.

 

 

Best regards,

Felipe

1 Rookie

 • 

20.4K Posts

February 8th, 2015 09:00

Felipe,

to piggy back on koppuru questions, is there a formula how to calculate B2B credits. Anything specific for DWDM versus FCIP ?

Thanks

96 Posts

February 10th, 2015 03:00

Hi again dynamox 

 

I'm glad you asked it because the B2B credits (or BBC) is a matter I see many issues with.

 

In order to calculate the amount of required BBCs, Brocade uses the following formula:

 

Number of BBCs = (Distance(in Km) * LinkSpeed / 2) + 6

 

That '6' at the end of the formula, are 6 BBC reserved for Class-F traffic.

 

But we have to be careful since this formula calculates the number of buffer-to-buffer credits based on a full frame size (2148 KB), it doesn't take into account the average size of the frames going through the ISL. Historically, due to this fact, I have seen many issues when configuring extended ISLs, since by default many (Brocade) customers configure their extended ISLs with LD mode, and LD mode uses the above formula.

 

LD mode is one of the available config modes for extended ISLs in Brocade, it is very used since it automatically estimates the link length and calculate the required BBCs based on that distance. But, as I said before, it performs its calculations considering that the average size of the frames is 2 KB (2148 KB actually). In practice, the average frame size is always smaller than 2 KB, and thus more buffers that the calculated with that formula (and applied by LD mode) are required.

 

In order to take the average size into consideration for the calculation, we have to add the following to the formula:

 

Number of BBCs = [(Distance(in Km) * LinkSpeed / 2) * ( / )] + 6

 

Based on the above formula, I performed the below table:

 

LINK SPEED

TAMAÑO MEDIO DE TRAMA

DISTANCE

BB CREDITS REQUIRED (-6)

1G

2 KB

100 Km

50

2G

2 KB

100 Km

100

4G

2 KB

100 Km

200

8G

2 KB

100 Km

400

1G

2 KB

200 Km

100

2G

2 KB

200 Km

200

4G

2 KB

200 Km

400

8G

2 KB

200 Km

800

1G

1 KB

100 Km

100

2G

1 KB

100 Km

200

4G

1 KB

100 Km

400

8G

1 KB

100 Km

800

1G

1 KB

200 Km

200

2G

1 KB

200 Km

400

4G

1 KB

200 Km

800

8G

1 KB

200 Km

1600

 

Checking this table, we get the following info:

  • The number of required BBCs doubles when doubling the speed (this is because the higher the speed is, the shorter the frames are, and more frames fit into the ISL).
  • The number of required BBCs doubles when the distance doubles.
  • The number of required BBCs doubles when the average frame size decreases by 50% (the smaller the frame, the more fit in the ISL)

 

By using this table we can easily calculate the number of required BB Credits.

 

With FOS 6 and below, the only way to configure the BBC in Brocade was by indicating the desired distance at the setup of the extended ISL (in LS mode) and this led to some confusion. Fortunately for us, with FOS 7 Brocade included a BBC calculator in which you introduce the link length, speed and average size and it automatically calculates the required BBC for you.

 

DS6510b-1:FID128:root> portbuffercalc 0 -distance 100 -speed 4 -framesize 2048

206 buffers required for 100km at 4G and framesize of 2048bytes

 

DS6510b-1:FID128:root> portbuffercalc 0 -distance 100 -speed 4 -framesize 1024

406 buffers required for 100km at 4G and framesize of 1024bytes

 

It is also easier to calculate the average frame size, since command portbuffershow shows the average frame size and the average buffer usage:

 

User    Port    Lx    Max/Resv  Avg Buffer Usage & FrameSize    Buffer Needed    Link    Remaining

Port    Type    Mode    Buffers        Tx        Rx              Usage  Buffers  Distance  Buffers

----    ----    ----    -------  ----------------------------    ------ -------  --------- ---------

  0      E      LS      206      29(1172)      35(1396)        206    206      100km

 

Additionally, the command used to configure BBC on Brocade (portcfglongdistance) has been improved and now we can introduce the average frame size as well. So, when it comes to Brocade switchs, FOS 7 has make a big breakthrough with Extended ISLs.

 

On the other hand, Cisco is clearer on this situation and by default, it provides the ISL with a whole bunch (the number depends on the ASIC/blade model) of BBCs (or B2B credits if you prefer), so usually configuring an extended ISL on a Cisco switch is pretty easy and straightforward. But in case you need to modify the amount of B2B, the table and formula is also valid.

 

 

Kind regards,

Felipe

8 Posts

February 11th, 2015 13:00

Felipe, hay alguna diferencia en performance cuando se usa una zona "single initiator - multiple targets" vs. "single initiator - single target"?

Gracias

1 Rookie

 • 

20.4K Posts

February 11th, 2015 19:00

it is common courtesy to post in English if you see everyone else contribute in English.

1 Rookie

 • 

20.4K Posts

February 11th, 2015 19:00

please post in English

No Events found!

Top