According to cisco information on SRDF, flexibility of the Catalyst 6500 allows it to function in this dual role(LAN/WAN), this configuration is only acceptable when the Catalyst 6500 is not aggregating a large amount of mixed traffic for transmission over the WAN. Can anyone explain this in greater detail ??? What is the limitation ??? Are there any design solutions that can offset this limitation ??
Since there has been no response to your post, it appears to be either too complex or too rare an issue for other forum members to assist you, or there is no public information available at this time. If you don't get a suitable response to your post, you may wish to review our resources at the online http://www.cisco.com/go/solutions. You may also contact our product information line at 1-800-553-NETS or a Cisco Systems Engineer at your local Cisco office or reseller. To locate your local Cisco representative, visit http://www.cisco.com/warp/public/687/Directory.shtml
If anyone else in the forum has some advice, please reply to this thread.
First, can you post the URL for this Cisco reference? I think you are talking about Fibre Channel traffic from your EMC storage being encapsulated in IP and mixed with other IP traffic for transmission to a remote site over a single link. Is this correct?
If so, I'm sure it's possible but it sounds a little scary to me. I think wer'e a little bit away from high volume, misson critical storage traffic using the IP protocol (I'm sure SRDF fits into this category for most companies). I'd sleep a lot better if this was FC all the way, but of course that requires another link...
Also, I wonder if EMC will support SRDF over an IP connection. Have you discussed this with them? We're talking about doing SRDF over a DWDM network, and it's interesting that they strongly recommend we provision unprotected links over the DWDM. The reason for this it that DWDM will converge in around 50 msec if we have a fibre cut, and that's a long time to a storage network. SRDF will typically converge around such a failure in 3-4 msec (so I'm told by EMC - I'm not speaking from experience). Anyway, I wonder how this would work if there's an IP network in the middle? Even with a good & tuned IGP, you've be hard pressed to avoid at least a couple of seconds reconvergence time I think, and that's just not acceptable to SRDF.
From my previuos investigation into this matter Cisco is currently woring on implementing SRDF over IP. You really need to understand which mode you would like to run SRDF in. Then I would call the number the fellow from Cisco listed and see if there current support for SRDF over IP meets your requirements.
SRDF directly from a EMC Sym into a Cat6500 would expect the connection to come directly via a Fibre Channel switch, such interface on a Cat6500 does not exist. If the connection is from a ESCON extention unit such as a CNT unit then it would come directly from the channel extention unit via IP to the Cat6500 much as described in http://wwwin.cisco.com/cmc/cc/so/neso/stneso/tech/srdfp_wp.htm The IP and WAN/LAN engineering requirements needed for the SRDF communication would come from EMC qualifications of the solution. From this engineering output the Cat6500 and all the IOS tools would be used to give the SRDF connection the proper QOS and bandwidth needs for this high avalibility TCP/IP path. Your limitation is the transport between locations, latency, distance and bandwidth.
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...