Best Practice on trunking VSAN 1

Hello all
I'd appreciate feedback on wether this is looked upon as good practice or not.
For all the Cisco SAN implementations I have done to date, I have always trunked VSAN1 (but obviously NOT used it for customer data). I do this for a couple of reasons.
1. It is a good test for an ISL, you can initially trunk VSAN1 to be 100% all is OK, before affecting customer VSAN's
2. Fabric manager is not "erroring" by reporting segmented VSAN's
What do the rest of you do? Is there a Cisco best practice on this?
Thanks
Steven

Steven,
CFS stands for Cisco Fabric Services. It can be used to distribute configuration information between MDS switches to keep the configuration consistent. It can be used for various things like NTP settings, Syslog config, call home config etc.
You can find more information in the MDS documentation on CCO. See here for example:
http://www.cisco.com/en/US/docs/switches/datacenter/mds9000/sw/5_0/configuration/guides/sysmgnt/nxos/cfs.html
CFS uses VSAN 1.
As for best practices, there is a document also on CCO:
http://www.cisco.com/en/US/prod/collateral/ps4159/ps6409/ps5990/white_paper_C11-515630.html
This talks a bit about VSAN 1. I can tell you that I have installed lots of MDS SANs during the past 9 years and it is one of the things I’d do from experience. Use VSAN 1 for management purposes like CFS and put your real production traffic in other VSANs.
Ralf

Similar Messages

Best Practice to Integrate CER with RedSky E911 Anywhere via SIP Trunk

We are trying to integrate CER 9 with RedSky for V911 using a SIP trunk and need assistance with best practice and configuration. There is very little documentation regarding "best practice" for routing these calls to RedSky. This trunk will be handling the majority of our geographically dispersed company's 911 calls.
My question is: should we use an IPsec tunnel for this? The only reference I found was this: http://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/virtual-office/deployment_guide_c07-636876.htmlm which recommends an IPsec tunnel for the SIP trunk to Intrado. I would think there are issues with an unsecure SIP trunk for 911 calls. Looking for advice or specifics on how to configure this. Does the SIP trunk require a CUBE or is a CUBE only required for the IPsec tunnel?
Any insight is appreciated.
Thank you.

you can use Session Trace in RTMT to check who is disconnecting the call and why.

IVR (Inter-VSAN Routing) - Best practices questions

Hi there,
We have a situation where we will have multiple customers hosted on a 9513 and sharing a single storage array.
We want to keep the logically seperated in their own VSANs, but of course the storage array will need to be zoned to all the customers hosts.
Now IVR should be the thing to use, but I'm getting resistance from the local team (screams of "Nooooo!!! They're EVILLLLL!!!") ... so I want to find out if there are some best practices around IVR use ?
Should they be used only for light duty stuff ? (though at present we use them with tape backup, which isn't exactly "light")
Do they impact performance to a measurable degree ?
Are they stable ?
What can go wrong with them ? And does it happen often ?
Thanks!

IVR does not impact application I/O performance because all the vsan rewrite and fcid rewrite actions are done in hardware asics. The IVR process on supervisor is responsible for managing the configuration and ensuring the rewrite tables are programmed in the linecards. The process is stable.
Most of the issues I have seen are in environments with multiple IVR enabled MDS switches ISL'd together or an MDS IVR enabled switch connected to a McData/Brocade in an interop mode.
Like any feature there have been bugs and it pays to check the SAN-OS release notes when planning installs. For example, a config change on one switch does not get properly pushed to another IVR switch or a forwarding table for an ISL interface does not get correctly programmed. There have also been a fair share of user misconfigurations which could have been avoided if Cisco Fabric Services (CFS) was enabled for IVR. This is done with the 'ivr distribute' command. Without this it is very difficult in large topologies of multiple IVR switches to ensure they have a consistent IVR config. In other cases there have been problems from a mix of IVR enabled switches running different releases of SAN-OS, e.g. mixing 3.0 with 3.2.
Best practice is to have dual physical fabrics, upgrade one fabric at a time ensuring all IVR switches in a fabric run same SAN-OS release.
A single IVR switch is much easier to implement. The MDS Configuration Guide has a list of best practices for IVR and one of those is to use the NAT option. Personally I would avoid NAT option where you can as NAT makes any troubleshooting harder trying to figure out the domain ID translations. You would also minimize risk of hitting some NAT related bugs, but you could also avoid most of these by checking the workarounds documented in the Release Notes. And with NAT you need to also configure persistent virtual domains and fcids to cater for AIX and HP-UX systems that cannot handle the FCID of the target changing whenever the exported virtual domain ID changes. To give NAT credit, each vsan is represented by a single virtual domain. In regular non-NAT mode, each switch in a vsan is represented by a virtual domain, meaning you eat up more virtual domain IDs. So in large topologies with many domain IDs there are scalability advantages to using NAT and the IVR updates between switches are more efficient with fewer virtual domain IDs to advertize. Of course, NAT must be used if merging physical fabrics with same domain ID and you cannot afford the downtime to change one of the switch domain IDs.
However if it is just a single IVR switch I would avoid NAT. To do this all your domain IDs should be statically defined and there must be no overlapping domain IDs between IVR'd vsans. If it is a brand new install you can easily achieve this by specifying unique allowed domain ID ranges per vsan.
For example, each customer can have their own vsan with say 10 domain IDs and the storage can be in vsan 2. You will only use one domain ID per vsan on day 1. Allowing 10 domain ids per vsan means you can add up to 9 other switches per vsan should you need to in the future. There is a maximum 239 domains per vsan so you could have up to 23 customers on your 9513 working with a range of 10 domain IDs per vsan.
fcdomain domain 2 static vsan 2
fcdomain domain 10 static vsan 10
fcdomain domain 20 static vsan 20
fcdomain domain 30 static vsan 30
..and so on..
fcdomain domain 230 static vsan 230
fcdomain allowed 01-09 vsan 2
fcdomain allowed 10-19 vsan 10
fcdomain allowed 20-29 vsan 20
fcdomain allowed 30-39 vsan 30
..and so on..
fcdomain allowed 230-239 vsan 230
With or without IVR you should still run dual fabrics (e.g. 95xx in each fabric) and host based multipathing for redundancy.
And don't forget IVR will require an Enterprise license. I have even seen a large outage because the customer forgot to install the license before the 120 day grace period expired.

Best practice for presenting different storage vendors arrays..?

Hi, can't seem to find a specific answer in writing on this.
Typical FlexPod already deployed, with different vsans on different n5ks.
Uplinks from UCS / NetApp are FCoE.
So I now want to present some normal FC (not FCoE, nexsan) storage to the same blades on the UCS system via the n5ks.
My main questions are can I use same vsans / vHBAs as for NetApp storage, or should you be creating different vsans and vHBAs for different storage vendors?
If multiple vsan is recommended, is Trunking multiple vsans over FCoE from UCS to FC fine, I'm sure it is but just want some experience on it.
Thanks!

Thanks guys for the input, interesting to see there is a difference of opinion on this topic. Makes me feel happier that I'm not being too stupid and someones posted back a link to a best practice guide on the subject that I've blatantly missed! (still time for that no doubt!)
Like I've said, I haven't found anything specific in writing on this, but keeping vendors on seperate vsans / hbas feels like the best way to do it anyway with only a little extra config in the grand scheme of things.

Best practice for integrating a 3 point metro-e in to our network.

Hello,
We have just started to integrate a new 3 point metro-e wan connection to our main school office. We are moving from point to point T-1?s to 10 MB metro-e. At the main office we have a 50 MB going out to 3 other sites at 10 MB each. For two of the remote sites we have purchase new routers ? which should be straight up configurations. We are having an issue connecting the main office with the 3rd site.
At the main office we have a Catalyst 4006 and at the 3rd site we are trying to connect to a catalyst 4503.
I have attached configurations from both the main office and 3rd remote site as well as a basic diagram of how everything physically connects. These configurations are not working ? we feel that it is a gateway type problem ? but have reached no great solutions. We have tried posting to a different forum ? but so far unable to find the a solution that helps.
The problem I am having is on the remote side. I can reach the remote catalyst from the main site, but I cannot reach the devices on the other side of the remote catalyst however the remote catalyst can see devices on it's side as well as devices at the main site.
We have also tried trunking the ports on both sides and using encapsulation dot10q ? but when we do this the 3rd site is able to pick up a DHCP address from the main office ? and we do not feel that is correct. But it works ? is this not causing a large broad cast domain?
If you have any questions or need further configuration data please let me know.
The previous connection was a T1 connection through a 2620 but this is not compatible with metro-e so we are trying to connect directly through the catalysts.
The other two connection points will be connecting through cisco routers that are compatible with metro-e so i don't think I'll have problems with those sites.
Any and all help is greatly welcome ? as this is our 1st metro e project and want to make sure we are following best practices for this type of integration.
Thank you in advance for your help.
Jeff

Jeff, form your config it seems you main site and remote site are not adjacent in eigrp.
Try adding a network statement for the 171.0 link and form a neighbourship between main and remote site for the L3 routing to work.
Upon this you should be able to reach the remote site hosts.
HTH-Cheers,
Swaroop

Networking "best practice" for setting up a farm

Hi all.
We would like to set an OracleVM farm, and I have a question about "best practice" for
configuring the network. Some background:
- The hardware I have is comprised of machines with 4 gig-eth NICs each.
- The storage will be coming primarily from a backend NAS appliance (Netapp, FWIW).
- We have already allocated a separate VLAN for management.
- We would like to have HA capable VMs using OCFS2 (on top of NFS.)
I'm trying to decide between 2 possible configurations. The first would keep physical separation
between the mgt/storage networks and the DomU networks. The second would just trunk
everything together across all 4 NICs, something like:
Config 1:
- eth0 - management/cluster-interconnect
- eth1 - storage
- eth2/eth3 => bond0 - 8021q trunked, bonded interfaces for DomUs
Config 2:
- eth0/1/2/3 => bond0
Do people have experience or recommendation about the best configuration?
I'm attracted to the first option (perhaps naively) because CI/storage would benefit
from dedicated bandwidth and this configuration might also be more secure.
Regards,
Robert.

user1070509 wrote:
Option #4 (802.3ad) looks promising, but I don't know if this can be made to work across
separate switches.It can, if your switches support cross-switch trunking. Essentially, 802.3ad (also known as LACP or EtherChannel on Cisco devices) requires your switch to be properly configured to allow trunking across the interfaces used for the bond. I know that the high-end Cisco and Juniper switches do support LACP across multiple switches. In the Cisco world, this is called MEC (Multichassis EtherChannel).
If you're using low-end commodity-grade gear, you'll probably need to use active/passive bonds if you want to span switches. Alternatively, you could use one of the balance algorithms for some bandwitch increase. You'd have to run your own testing to determine which algorithm is best suited for your workload.
The Linux Foundation's Net:Bonding article has some great information on bonding in general, particularly on the various bonding methods for high availability:
http://www.linuxfoundation.org/en/Net:Bonding

ASA 5505 Best Practice Guidance Requested

I am hoping to tap into the vast wealth of knowledge on this board in order to gain some "best practice" guidance to assist me with the overall setup using the ASA 5505 for a small business client. I'm fairly new to the ASA 5505 so any help would be most appreciated!
My current client configuration is as follows:
a) business internet service (cable) with a fixed IP address
b) a Netgear N600 Wireless Dual Band router (currently setup as gateway and used for internet/WiFi access)
c) a Cisco SG-500-28 switch
d) one server running Windows Small Business Server 2011 Standard (primary Domain Controller)
     (This server is currently the DNS and DHCP server)
e) one server running Windows Server 2008 R2 (secondary Domain Controller)
f) approximately eight Windows 7 clients (connected via SG-500-28 switch)
g) approximately six printers connected via internal network (connected via SG-500-28 switch)
All the servers, clients, and printers are connected to the SG-500-28 switch.
The ISP provides the cable modem for the internet service.
The physical cable for internet is connected to the cable modem.
From the cable modem, a CAT 6 ethernet cable is connected to the internet (WAN) port of the Netgear N600 router.
A Cat 6 ethernet cable is connected from Port 1 of the local ethernet (LAN) port on the N600 router to the SG-500-28 switch.
cable modem -> WAN router port
LAN router port -> SG-500-28
The ASA 5505 will be setup with an "LAN" (inside) interface and a "WAN" (outside) interface. Port e0/0 on the ASA 5505 will be used for the outside interface and the remaining ports will be used for the inside interface.
So my basic question is, given the information above of our setup, where should the ASA 5505 be "inserted" to maximize its performance? Also, based on the answer to the previous question, can you provide some insight as to how the ethernet cables should be connected to achieve this?
Another concern I have is what device will be used as the default gateway. Currently, the Netgear N600 is set as the default gateway on both Windows servers. In your recommended best practice solution, does the ASA 5505 become the default gateway or does the router remain the default gateway?
And my final area of concern is with DHCP. As I stated earlier, I am running DHCP on Windows Small Business Server 2011 Standard. Most of the examples I have studied for the ASA 5505 utilize its DHCP functionality. I also have done some research on the "dhcprelay server" command. So I'm not quite sure which is the best way to go. First off, does the "dhcprelay server" even work with SBS 2011? And secondly, if it does work, is the best practice to use the "dhcprelay" command or to let the ASA 5505 perform the DHCP server role?
All input/guidance/suggestions with these issues would be greatly appreciated! I want to implement the ASA 5505 firewall solution following "best practices" recommendations in order to maximize its functionality and minimize the time to implement.
FYI, the information (from the "show version" command) for the ASA 5505 is shown below:
Cisco Adaptive Security Appliance Software Version 8.4(7)
Device Manager Version 7.1(5)100
Compiled on Fri 30-Aug-13 19:48 by builders
System image file is "disk0:/asa847-k8.bin"
Config file at boot was "startup-config"
ciscoasa up 2 days 9 hours
Hardware:   ASA5505, 512 MB RAM, CPU Geode 500 MHz
Internal ATA Compact Flash, 128MB
BIOS Flash M50FW016 @ 0xfff00000, 2048KB
Encryption hardware device : Cisco ASA-5505 on-board accelerator (revision 0x0)
                             Boot microcode   : CN1000-MC-BOOT-2.00
                             SSL/IKE microcode: CNLite-MC-SSLm-PLUS-2.03
                             IPSec microcode : CNlite-MC-IPSECm-MAIN-2.06
                             Number of accelerators: 1
0: Int: Internal-Data0/0    : address is a493.4c99.8c0b, irq 11
1: Ext: Ethernet0/0         : address is a493.4c99.8c03, irq 255
2: Ext: Ethernet0/1         : address is a493.4c99.8c04, irq 255
3: Ext: Ethernet0/2         : address is a493.4c99.8c05, irq 255
4: Ext: Ethernet0/3         : address is a493.4c99.8c06, irq 255
5: Ext: Ethernet0/4         : address is a493.4c99.8c07, irq 255
6: Ext: Ethernet0/5         : address is a493.4c99.8c08, irq 255
7: Ext: Ethernet0/6         : address is a493.4c99.8c09, irq 255
8: Ext: Ethernet0/7         : address is a493.4c99.8c0a, irq 255
9: Int: Internal-Data0/1    : address is 0000.0003.0002, irq 255
10: Int: Not used            : irq 255
11: Int: Not used            : irq 255
Licensed features for this platform:
Maximum Physical Interfaces       : 8              perpetual
VLANs                             : 3              DMZ Restricted
Dual ISPs                         : Disabled       perpetual
VLAN Trunk Ports                  : 0              perpetual
Inside Hosts                      : 10             perpetual
Failover                          : Disabled       perpetual
VPN-DES                           : Enabled        perpetual
VPN-3DES-AES                      : Enabled        perpetual
AnyConnect Premium Peers          : 2              perpetual
AnyConnect Essentials             : Disabled       perpetual
Other VPN Peers                   : 10             perpetual
Total VPN Peers                   : 12             perpetual
Shared License                    : Disabled       perpetual
AnyConnect for Mobile             : Disabled       perpetual
AnyConnect for Cisco VPN Phone    : Disabled       perpetual
Advanced Endpoint Assessment      : Disabled       perpetual
UC Phone Proxy Sessions           : 2              perpetual
Total UC Proxy Sessions           : 2              perpetual
Botnet Traffic Filter             : Disabled       perpetual
Intercompany Media Engine         : Disabled       perpetual
This platform has a Base license.

Hey Jon,
Again, many thanks for the info!
I guess I left that minor detail out concerning the Guest network. I have a second Netgear router that I am using for Guest netowrk access. It is plugged in to one of the LAN network ports on the first Netgear router.
The second Netgear (Guest) router is setup on a different subnet and I am letting the router hand out IP addresses using DHCP.
Basic setup is the 192.168.1.x is the internal network and 192.168.11.x is the Guest network. As far as the SBS 2011 server, it knows nothing about the Guest network in terms of the DHCP addresses it hands out.
Your assumption about the Guest network is correct, I only want to allow guest access to the internet and no access to anything internal. I like your idea of using the restricted DMZ feature of the ASA for the Guest network. (I don't know how to do it, but I like it!) Perhaps you could share more of your knowledge on this?
One final thing, the (internal) Netgear router setup does provide the option for a separate Guest network, however it all hinges on the router being the DHCP server. This is what led me to the second (Guest) Netgear router because I wanted the (internal) Netgear router NOT to use DHCP. Instead I wanted SBS 2011 to be the DHCP server. That's what led to the idea of a second (Guest) router with DHCP enabled.
The other factor in all this is SBS 2011. Not sure what experience you've had with the Small Business Server OS's but they tend to get a little wonky if some of the server roles are disabled. For instance, this is a small busines with a total of about 20 devices including servers, workstations and printers. Early on I thought, "nah, I don't need this IPv6 stuff," so I found an article on how to disable it and did so. The server performance almost immediately took a nose dive. Rebooting the server went from a 5 minute process to a 20 minute process. And this was after I followed the steps of an MSDN article on disabling IPv6 on SBS 2011! Well, long story short, I enabled IPv6 again and the two preceeding issues cleared right up. So, since SBS 2011 by "default" wants DHCP setup I want to try my best to accomodate it. So, again, your opinion/experiece related to this is a tremendous help!
Thanks!

Best Practice setting up NICs for Hyper V 2008 r2

I am looking at some suggestions for best practice for setting up a hyper V 2008 r2 at a remote location with 5 nics, one for managment vlan and other 4 on the data vlan. This server will host 2 virtual machines, one is a DC and the other
is a member local DHCP server. The server is setup now with one nic on the management Vlan and the other nic's set to get there ip from the local dhcp server on on the host. We have the virtual networks setup in Hyper V to
point to each of the nics using the "external connection". The virtual servers 'DHCP and AD" have there own ip set within them. Issues we are seeing, when the site looses external connections for a while they cannot get ip
addresses from the local dhcp server anymore.
1. NIC on management Vlan -- IP Static -- Physical host
2. NIC on the Data network Vlan -- DHCP linked as a connection "external" in Hyper V -- virtual server DHCP
3. NIC on the Data network Vlan -- DHCP linked as a connection "external" in Hyper V -- Virtual server domain controller
4. NIC on the Data network Vlan -- DHCP linked as a connection "external" in Hyper V -- extra
5. NIC on the Data network Vlan -- DHCP linked as a connection "external" in Hyper V -- extra
Thanks in advance

Looks like you may be over complicating things here. More and more of the recommendations from Microsoft at this point would be to create a Logical Switch and then layer on Logical Networks for your management layers, but here is what I would do for
you simple remote office.
Management NIC: Looks good (Teaming would be better, but only if you had 2 different switching to protect against link failures at the switch level. Doesn't seem relevant in this case however.
NIC for Data Network VLAN: I would use one NIC in your case if you can have the ability to Trunk multiple VLANs at the switch level to the NIC. That way you are setting the VLAN on the VMs NIC that you want to access and your
Virtual Switch configuration is very simple. On this virtual switch however, I would uncheck IPv4 and IPv6. There is no need to give this NIC an address as you are just passing traffic through them from the VMs that are marked with VLAN tags. Again,
if you have multiple physical switches in the building teaming could be an option, but probably adds more complexity than is necessary for a small office.
Even if you keep your Virtual Switches linked to separate NICs unchecking IPv4 and IPv6 makes sense.
Disable all the other NICs
Beyond that, check your routing. Can you ping between all hosts when there is not interruption? What DHCP server are they getting there addresses on normally? Where are your name resolution servers (DNS, WINS)?
No silver bullet here, but maybe a step in the right direction.
Rob McShinsky (VirtuallyAware.com)
VirtuallyAware - Experiences in a Virtual World (Microsoft MVP - Virtual Machine)

Best Practice - WAP connecting switchport configuration.

Is there a best practice for deploying the WAP's in a WAP/WLC infrastructure? Should the connecting switchport be an Access port or a Trunk port? I've seen this implemented in both fashions and wasn't sure if one was a better choice than the order. What is the difference?
My other question is regarding applying additional switchport configurations. Is there anything wrong with applying either spanning-tree portfast, spanning-tree bpdguard, or switchport port-security.

Hi Ken,
Access port all the time, everywhere, UNLESS the AP is configured for HREAP/FLEX then trunk. Or if you deploy a AP in monitor mode then TRUNK.
QOS -- if its access port trust dscp. If you truck trust cos.
No you are fine. Portfast is highly recommended.
"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
‎"I'm in a serious relationship with my Wi-Fi. You could say we have a connection."

SINGLE 9513 with A&B 9216 best practice....

We have a couple 9216's (A&B side - VSAN numbers identical) and have reached our port count limit. We purchased one 9513 with two 48 port FC modules and one X9304-18k4 line rate card (18FC/4IP). The goal is to make the single 9513 our principle switch ISL'ed to the 9216's.
Is having one 9513 a good decision? Our thoughts were that it has so much redundancy built in and the performance is far beyond what we need we could just use one. I have never had anything but an A&B side of the fabric so wrapping my head around this and trying to keep it within best practice is proving difficult.
The 9216A&B VSANS numbers are identical. When we ISL the zones will merge thereby collapsing the A&B sides together. I really don't want to do that (would essentially become a meshed fabric right). I am thinking that I need to rename the VSAN's on the B side to not match A. Maybe make the even numbered VSAN the A side and the odd numbered VSAN the B side. That way I can keep the ISL's independent from each other and prevent the zones from collapsing into each other.
Also keep in mind that we may (eventually) purchase another 9513 and just move one of the FC48 modules over to separate the A&B side again at a later date. I want to keep this as flexible as possible in case that does happen.
Thoughts - comments - suggestions all welcome! Just please be nice. I am learning....

I think you are right on. The single 9513 can not have duplicate VSANs for the A and B 9216s. The odd/even idea makes the most sense. This way you can leverage the 9513 redundancy. You can match the same VSANs that exist in the A fabric, and only permit those VSANs across the ISLs to the A 9216. You will have to renumber the VSANs on the B 9216 and then match them on the 9513 and again, only permit those VSANs on the ISLs to the B 9216.
Things to keep in mind if you re-number the VSANs on the B 9216. If you match the domain numbers used on the corresponding A 9216 VSANs, and make them static, even if someone cross connects a cable the VSANs will not merge since there is domain confict. If you change the domain from the current one in use, hosts like AIX and HP-UX will get a new FCID. You may have to rescan the host to resolve the lun bindings.
If you have AIX and HP-UX, you may want to ensure that the target devices they use, get the same FCID after the VSAN renumber to avoid having to perform the rescan. (this may prevent matching the same domains used on the A 9216).
Hope this helps,
Mike

Best practice about dial-peer creating when using analog lines

Hi,
I am trying to find out what is the best practice when creating dial-peer for analog lines on CME, should I use trunk group or create separate dial-peer for each FXO ports? If I use trunk group, is there any advantage ( lesser dial-peer) or disadvantage?
Thanks!

The advantage of trunk groups is that a single dial peer can point to for instance PSTN, rather then multiple dialpeers, with varying preference, each pointing to a separate FXO. Funtionally I can't see much difference. So I guess it also comes down to personal preference.
=============================
Please remember to rate useful posts, by clicking on the stars below.
=============================

Best Practice VLAN

Hi All,
I have got
1 of Cisco 3560 (EMI) as Core Switch
1 of Cisco 3560 (SMI) as Server Switch
10 of Cisco CE500 as workgroup switches
4 of different brands workgroup switches
20 Servers
300 Users
10 different departments
My intensions are to create VLANs on 3560 Core Switch as Server, Finance, Marketing etc
and connect the the server and workgroup switches to the appropriate ports for their Defined VLANs on 3560Core switch.
I dont think i need to run VTP Server on core switch as i am going to have all VLANS within that switch?
Or Can anyone suggest what should be the best practice in this situation.
thanks
Muhammad

I dont think i need to run VTP Server on core switch as i am going to have all VLANS within that switch?
>> then you need to make the VTP a tranparent mode as you cannot create a vlan on a VTP client. I think maybe what you meant is you will have all user in a particular switch be in the same vlan, for example,
3560 1/1---vlan 5---CE500---users in vlan 5
In this case you do not need trunking .
Or Can anyone suggest what should be the best practice in this situation.
>> If your planned set-up is identical to above then this is an acceptable set-up and actually quite good for it's simplicity.
Please rate helpful posts.

Template(best practice) for Switch ports

Hi,
Looking for best practice advice on switchport config for client facing ports.
We recently had an incident where an access port turned into a trunk(trunk mode desirable), which we obviously do not want to happen again!
For Access Ports(First two should stop DTP I'm hoping?):
switchport mode access
switchport nonegotiate
storm-control broadcast level 20.00
storm-control action trap
no cdp enable
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree guard root
switchport port-security maximum 10
switchport port-security
switchport port-security aging time 10
And for trunk ports to clients:
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan xxx,xxx
switchport nonegotiate
storm-control broadcast level 20.00
storm-control action trap
no cdp enable
spanning-tree bpdufilter enable
spanning-tree guard root
Thanks in advance.

Look here: http://www.cisco.com/en/US/docs/solutions/Enterprise/Branch/E_B_SDC1.html#wp68930
That's Cisco's branch design doc from Design Zone.
For those that want a fast answer:
For VoIP phones and PC:
interface GigabitEthernet1/0/6 - interface GigabitEthernet1/0/23
description phone with PC connected to phone
switchport access vlan 102
switchport mode access
switchport voice vlan 101
switchport port-security maximum 2
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
ip arp inspection limit rate 100
load-interval 30
srr-queue bandwidth share 1 70 25 5
srr-queue bandwidth shape 3 0 0 0
priority-queue out
mls qos trust device cisco-phone
spanning-tree portfast
spanning-tree bpduguard enable
ip verify source
ip dhcp snooping limit rate 100
For data only:
interface GigabitEthernet1/0/24- interface GigabitEthernet1/0/28
description DATA only ports
switchport access vlan 102
switchport mode access
switchport port-security maximum 3
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
ip arp inspection limit rate 100
load-interval 30
srr-queue bandwidth share 1 70 25 5
srr-queue bandwidth shape 3 0 0 0
priority-queue out
spanning-tree portfast
spanning-tree bpduguard enable
ip verify source
ip dhcp snooping limit rate 100
That's Cisco's recommendation.
And just my opinion is that I'd much rather shut a port down that receives a BPDU than just filter it. Reason being that you can't trust users not to do something stupid, like hook two switch ports to the same switch they're using at their desk in an effort to "make the network faster". For two, if someone malicious plugs in a switch into your environment, shut the port down. . .that makes it hard for them to do anything malicious.

Root guard best practices? Where to put it?

Hey all,
We recently implemented root guard on our two core devices, on both ports that point to our distribution layer. This broke the link from our secondary router to the distribution layer, which remains in a BKN state due to the root BPDU that passes through our distribution layer and into the router. After doing this, we are now unable to pass traffic inbound from our secondary router.
I'm wondering what would be considered a best practice with root guard -- should we leave it where it is, or push it down to the distribution layer where the interfaces connect to our access switches? Topology attached here.
I will note that we are only allowing what vlans we need across each link, and currently we are not allowing all vlans across the trunk between R1 and R2.

Hello Patrick-
You should have root guard enabled on:
- Core ports that are connecting to the distribution switches
- Distribution ports that are connecting to the access switches
Similar to this diagram (I was going to draw one but a quick google search got me one :) )
http://www.rogerperkin.co.uk/ccie/wp-content/uploads/2013/03/spanning-tree-root-guard.jpg
Also, what is the reason for not allowing all VLANs on the link between the core switches? Ideally, you would not want to block on that link. This can also (depending on actual setup) cause some traffic to be send to a blackhole if certain links are to die off. If the diagram that you attached is accurate then you would probably want to:
- Connect each distribution switch to each core (create triangle type connections not squares)
- Remove the link between distribution switches (optional but IMO preferred)
- Allow all VLANs on the link between the two core switches
- Let STP blocking happen on the link that is between the distribution and core switches while the link between the two cores remain in unblocking state
Thank you for rating helpful posts!

Query: Best practice SAN switch (network) access control rules?

Dear SAN experts,
Are there generic SAN (MDS) switch access control rules that should always be applied within the SAN environment?
I have a specific interest in network-based access control rules/CLI-commands with respect to traffic flowing through the switch rather than switch management traffic (controls for traffic flowing to the switch).
Presumably one would want to provide SAN switch demarcation between initiators and targets using VSAN, Zoning (and LUN Zoning for fine grained access control and defense in depth with storage device LUN masking), IP ACL, Read-Only Zone (or LUN).
In a LAN environment controlled by a (gateway) firewall, there are (best practice) generic firewall access control rules that should be instantiated regardless of enterprise network IP range, TCP services, topology etc.
For example, the blocking of malformed TCP flags or the blocking of inbound and outbound IP ranges outlined in RFC 3330 (and RFC 1918).
These firewall access control rules can be deployed regardless of the IP range or TCP service traffic used within the enterprise. Of course there are firewall access control rules that should also be implemented as best practice that require specific IP addresses and ports that suit the network in which they are deployed. For example, rate limiting as a DoS preventative, may require knowledge of server IP and port number of the hosted service that is being DoS protected.
So my question is, are there generic best practice SAN switch (network) access control rules that should also be instantiated?
regards,
Will.

Hi William,
That's a pretty wide net you're casting there, but i'll do my best to give you some insight in the matter.
Speaking pure fibre channel, your only real way of controlling which nodes can access which other nodes is Zones.
for zones there are a few best practices:
* Default Zone: Don't use it. unless you're running Ficon.
* Single Initiator zones: One host, many storage targets. Don't put 2 initiators in one zone or they'll try logging into each other which at best will give you a performance hit, at worst will bring down your systems.
* Don't mix zoning types: You can zone on wwn, on port, and Cisco NX-OS will give you a plethora of other options, like on device alias or LUN Zoning. Don't use different types of these in one zone.
* Device alias zoning is definately recommended with Enhanced Zoning and Enhanced DA enabled, since it will make replacing hba's a heck of a lot less painful in your fabric.
* LUN zoning is being deprecated, so avoid. You can achieve the same effect on any modern array by doing lun masking.
* Read-Only exists, but again any modern array should be able to make a lun read-only.
* QoS on Zoning: Isn't really an ACL method, more of a congestion control.
VSANs are a way to separate your physical fabric into several logical fabrics. There's one huge distinction here with VLANs, that is that as a rule of thumb, you should put things that you want to talk to each other in the same VSANs. There's no such concept as a broadcast domain the way it exists in Ethernet in FC, so VSANs don't serve as isolation for that. Routing on Fibre Channel (IVR or Inter-VSAN Routing) is possible, but quickly becomes a pain if you use it a lot/structurally. Keep IVR for exceptions, use VSANs for logical units of hosts and storage that belong to each other. A good example would be to put each of 2 remote datacenters in their own VSAN, create a third VSAN for the ports on the array that provide replication between DC and use IVR to make management hosts have inband access to all arrays.
When using IVR, maintain a manual and minimal topology. IVR tends to become very complex very fast and auto topology isn't helping this.
Traditional IP acls (permit this proto to that dest on such a port and deny other combinations) are very rare on management interfaces, since they're usually connected to already separated segments. Same goes for Fibre Channel over IP links (that connect to ethernet interfaces in your storage switch).
They are quite logical to use and work just the same on an MDS as on a traditional Ethernetswitch when you want to use IP over FC (not to be confused with FC over IP). But then you'll logically use your switch as an L2/L3 device.
I'm personally not an IP guy, but here's a quite good guide to setting up IP services in a FC fabric:
http://www.cisco.com/en/US/partner/docs/switches/datacenter/mds9000/sw/4_1/configuration/guides/cli_4_1/ipsvc.html
To protect your san from devices that are 'slow-draining' and can cause congestion, I highly recommend enabling slow-drain policy monitors, as described in this document:
http://www.cisco.com/en/US/partner/docs/switches/datacenter/mds9000/sw/5_0/configuration/guides/int/nxos/intf.html#wp1743661
That's a very brief summary of the most important access-control-related Best Practices that come to mind. If any of this isn't clear to you or you require more detail, let me know. HTH!

Best Practice on trunking VSAN 1

Similar Messages

Maybe you are looking for