"Yes, it's completely impact-free.*
*Your experience may vary."
That's the impression I get from Cisco and the Nexus platform in general. As a general rule, I always try to secure a maintenance window for work on critical infrastructure as a CYA measure. Even if it works flawlessly 99% of the time, there's still that 1% that it won't, and "But Cisco told ...
As for benefits, first cables get sloppy and when you have sloppy, problems will occur. I have seen infrastructure cabling go bad for a number of reason in a data center. Need more cables? Then someone is messing with the cable plant and something could get damaged. Dealing with nearly 400 cables plugged into a device leads to more accidental disconnects ...
Friend of mine asked this question in Vegas in Cisco Live and Cisco cited lack of customer demand and thermal as main reasons.
CMP is absolutely the right solution and we need it in every vendor switch and router, only proper OOB. Server guys have had this for over decade.
So please start adding this as scoring item in your RFQ, so vendors know there is ...
On a Cisco Nexus switch, the syntax for HSRP is actually "HSRP" instead of "Standby".
In my experience, it makes it easier to troubleshoot as you know immediately which redundancy protocol you're dealing with (HSRP, GLBP, or VRRP).
See this Cisco doc for more information on HSRP on the Nexus 7000 platform.
First, be sure that you have enabled HSRP on the ...
When you apply the ACL to a layer2 trunk, this is called a Port ACL, use the ip port access-group syntax to apply it instead of ip access-group... explicitly...
IS_NEXUS_7010(config)# interface Ethernet2/2
IS_NEXUS_7010(config-if)# description Connected to Exchange Cisco 2960 24
IS_NEXUS_7010(config-if)# switchport mode ...
You can do a show run | egrep interface.Vlan|ip.address. It does grab a bit more info, but should provide similar output to what you see in IOS. I think grep might work as well, but I used egrep and got the correct output.
Keep in mind that a FEX inherently is a method by which to extend the fabric, thus the name. The ability to manage centrally while still having "line cards" distributed throughout the DC is the real reason to use a FEX. Drastically reducing cabling is valuable to anyone, technical or not, and the argument of being able to manage the entire infrastructure at ...
Regarding password complexity for local accounts, you have these options...
Cisco NX-OS: I'm not sure you can configure a local password policy in NX-OS; however, NX-OS rejects weak passwords by default. To disable this feature, use no password strength-checking in the global configuration.
Password length: security password min-length. ...
Dual-homing to a single N7k is a supported topology so I'm guessing you mean dual-homing to two N7ks.
The reason it isn't supported should be posed as a different question: 'Why WOULD you dual home a FEX to two separate N7ks?'
Remember, a FEX should only be thought of as a remote linecard of the upstream Nexus switch i.e. it doesn't perform local ...
If you are just looking for the IP addresses of the Vlan interfaces, a better way may be: show ip int br | grep -i vlan
Note: show ip int br in NXOS only shows layer 3 interfaces. To see status of all interfaces use show int br
for NXOS 4.0(2) and earlier:
show run | grep -i face\ vlan|ip\ address
4.0(3) and up:
show run | grep ignore-case face\ ...
On paper, yes. In reality, don't bet on it. As Mr. Stretch brings up... are you willing to bet your job on it not interrupting the CEO's video conference?
(In my experience, Cisco OIR is always an incalculable gamble. Sometimes it works perfectly. Others is creates noise on the bus that crashes the entire router. Or my fav... corrupts one of the buses ...
1.) Odds are good that if you're in colo space that you'd want to look at the 7010 with front-to-back airflow rather than the 7009 with side-to-side.
2.) One of the obvious points in the ToR vs centralized switching discussion is usually scalability. If your colo footprint is pretty much fixed then it's not much of a concern. If it's slated to grow in ...
Assuming that these ports are just access ports and are not participating in any routing or VLAN trunking which would cause a STP re-convergence or a routing re-convergence. It should be safe to move them.
You should not have to specify the id field.
This command should simply work:
allocate interface Ethernet1/16-24
!now exit, switchto ...
Quote from Colby Beam (Cisco TAC) "FET-10G vs. SFP-10G-SR":
This shouldn't be an issue, as I've seen customers do it all the time and I've done it in the lab. There is some limitation on distance with the FET-10G vs 10-SR. Also the FET can ONLY be used to connect a N2K to either a N5K or N7K
Unless the switch itself is generating packets, there will be nothing in the switch's ARP table. As a layer 2 device, it doesn't need to resolve IP addresses.
A layer 3 switch only needs to resolve a host address if it is directly connected. Otherwise, it forwards the packet to the next hop router (which will be in the ARP table).
We use the 6001 as a small core in a context which sounds fairly similar to yours, a small datacenter where a 7k is overkill.
It's turned out quite well for us in that role, however we do regret not getting the Enterprise LAN license initially, as we eventually required some more advanced routing features (BGP especially) that we did not have and adding the ...
The documentation I have seen says this should work:
show run | inc interface_Vlan|ip_address
Although it does not seem to for me on a 4k blade switch. I had success with
sh run | inc interface.Vlan|ip.address
Price is usually one of the big drivers for a "top of rack" design, and you've said cost is no object.
We've used it for two other reasons though that I hadn't seen listed yet: modularity or ease of deployment.
If you have a standard "rack" design you can build and test an entire rack (or group of racks) together as one module, or buy them ready-built. ...
There isn't much difference (apart from the cost) between running cables directly to the core, or using fabric extenders in between.
If you cable your servers directly to the cores, you'll connect each server with two links, one to each core switch. This way even if one core switch fails, the other keeps the service up.
If you fabric extenders on top of ...
switchport trunk allowed vlan all might be the way forward to get from a restricted 802.1q trunk to an unrestricted one ("unrestriced" as in: all VLANs allowed), without having to worry about some vlans being removed temporarily.
In my experience the 7K OIR function is 'hitless' with respect to the other linecards. However, keep in mind that in a configuration where M1 and F1 cards are mixed, the M1's handle all of the L3 functions, so removing the M1 will impact traffic on the others, hence the recommendation to have two in the system in such a config. Also, if the system is carved ...
Maybe I read it wrong, you allow users and internal servers in same security zone, all you need is users and internal servers in different layer 2 domain? Don't create vrf and routing between vrf just for that purpose. There must be simpler way to do it, for example different layer3 Vlans + ACL.
On 7K you give 1 vlan 100 for users and 1 vlan 200 for ...
You can send as much netflow traffic to a host as you like. Without some software listening on the host you wont collect any data.
There are several options to choose from, my Debian box here comes with nfdump, pmacct, ntopng ant probably several others. There are many more options from a free and open source to very expensive commercial software. Where ...
C(config)# vrf context management
C(config-vrf)# ip route 0.0.0.0/0 10.1.0.1
The issue appears to be that you've configured the default route in the Management VRF but you're pinging from outside of the Management VRF. Therefore, you're pings are failing.
If you want to set up a default route for VLANs100 & 200, you'll need to configure the default ...
Extending Ron's answer, here is an advice how to trace the user:
Find out the user's MAC address. There are multiple ways to do that, but possibly you have an IP Address Management (IPAM) system or you can find it out using the IP address. On the switch or router being the layer 3 gateway of the user's VLAN, try to ping the end PC. It does not matter if it ...
The best tip I can give for anything involving ISSU on 7K's is to read- and re-read- the release notes. There are very specific versions that are supported as origin/destination and there are also some features that are going to work better with ISSU than others. The other caveat to consider is that in some instances there may be requirements for firmware ...
I think, it can be done by this:
event manager applet protectmefromdoingstupid
description "goes here"
event cli match "switchport trunk allowed vlan [0-9]+.*"
action 1.0 put "There was no 'add' in that statement! If you know what you are doing, run 'terminal event-manager bypass' and 'no terminal event-manager bypass', when you are done."
I found the issue. The interfaces of the 7K we were upgrading didn't have the 'no ip redirects' command on. This caused a drop in BFD between the neighboring router we were testing from and also dropped our EIGRP neighborship. This list has similar information: https://lists.gt.net/cisco/nsp/141379
Cisco's SNMP Object Navigator is a great resource to answer most of these questions.
Entering your OID gives the following, so indeed 2 = OK :