IDSM-2 "redundancy" in a single chassis

I understand how IDSM-2 redundancy could work having two 6500's...but what do you do when you are doing inline vlan pairs and the IDSM-2 fails and is no longer there to bridge the vlans together? How can the switch be setup to bridge the vlans in the event that the IDSM-2 fails?
Also, instead of pairing all the vlans that have SVI's on the FWSM, could I just pair the FWSM's VLAN/SVI on the MSFC with another vlan and get the same effect as pairing all the vlans that are on the FWSM? Thanks.

I havn't tried this inside a 6500 chassis, but this works externally:
Set up your in-line sensors as multiple alternate paths connecting the two VLANs together and use spanning tree to assign one sensor path a higher STP cost. Once the primary sensor fails the traffic should re-route to the standby sensor. If you play with the STP settings you can get the switchover time down under a second.

Similar Messages

Pro's and Con's if i run multiple host firmware packages in the single chassis

hi
i would like to know pro's and Con's if i run multiple host firmware packages in the single chassis.
Like if my UCS is running with firmware of 1.4.1m ( having backup of 1.3.1 and 1.1.1j) with 3 blades in one chassis
can i assign service-profiles having three different host firmware versions
Server1 - host firmware 1.1.1j-- win2k8
server2 -host firmware 1.4.1m -- RHEL 5.6 ( OS)
server -host firmware 1.3.1 -(esxi 4.0)
Thanks in advance ,please replay if can i go ahead with this . ASAP

Yes, you can package them together.
Now Cisco has a better way. Cisco UCS Manager provides two main advantages over past firmware provisioning:
• The capability to group multiple firmware components together in one package
• The capability to apply a firmware package to any compatible server in a single operation
Cisco UCS Manager provides an accurate, easier, faster, more flexible, and centralized solution for managing firmware across the entire hardware stack. Service profiles in Cisco UCS Manager abstract the physical hardware from its software properties. Service profiles allow administrators to associate any compatible firmware with any component of the hardware stack. Simply download the firmware versions needed from Cisco and then, within minutes, totally provision firmware on components within the server, fabric interconnect, and fabric extender based on required network, server, and storage policies per application and operating system.
here is the document
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns944/white_paper_c11-588010_ps10279_Products_White_Paper.html

IDSM-2 Redundancy

How redundancy can be achieved with IDSM-2 blades installed in one or more switches. I have looked at the Cisco documents but could not find much on IDSM-2 redundancy features.

Thanks Nadeem.
Is the other IDSM required to be in the same Switch or it can be in other switch. What I am trying to understand is various level of redundancies that can be achieved with IDSM-2. In case if I have Switch A and B at one site for the purpose of redundancy (but traffic may flow from either), how can I achieve redundancy in IDSM2 by installing one in each switch while minimizing the duplicacy.
Is there a Cisco document that discusses various deployment scenarios of IDSM2 in CAT routers.
Thanks.

IDSM in redundant switching environment

I have two 6500 switches/routers trunked to each other serving various devices. The two switches are installed for the purpose of redundancy and same VLANs are configured on both. My question is related to deploying IDSM-2 blades in this environment. Can I just use single blade in one switch and still be able to monitor desired VLANs traffic through VACL or SPAN/VSPAN/RSPAN or do I need two IDSM blades; one in each switch. Has anyone deployed IDS in this environment and what are the benefits of deploying 2 (one is each) versus 1.

RSPAN is generally the method of choice for these types of configurations.
The packets from both switches can then be monitored by a single IDSM-2 in one switch.
You can also provide some redundancy by placing a second IDSM-2 in the other switch, and have both IDSM-2s monitoring the exact same traffic (each IDSM-2 is monitoring packets from both switches).
You will get duplicate alarms (one from each IDSM-2) when both are running, but it will ensure you do not miss any alarms if one of the switches should happen to go down for maintenance or power loss.
There are other deployment options, but these depend on some specifics that you will need to analyze:
Do you have assymmetric traffic?
Quite often in these types of setups, both the switches are carrying traffic at the same time, and on occasion the client traffic will go through one switch, but the server response traffic will come through the other switch. For the IDSM-2 to properly track these connections it needs to see traffic from both switches. So if assymetric traffic patterns exist, then RSPAN needs to be used so both switches can be monitored by a single IDSM-2.
If assymetric traffic does not exist, then the IDSM-2 does not need to monitor both switches.
You could deploy an IDSM-2 in each switch. Then using either span or VACL Capture the IDSM-2 could monitor just the traffic flowing through the switch where it is located.
What are the traffic rates?
The IDSM-2 has an upper performance limitation of 600Mbps. If you are forced to use RSPAN because of assymteric traffic patterns, then you will only have the ability to monitor 600Mbps and must choose wisely what will be RSPANed to the IDSM-2.
If you do not have assymetric patterns then you can at least use 2 IDSM-2s (one in each switch) and possibly more (see below).
If the traffic being routed by the switch/msfc?
If no traffic is being routed by the switch, and you do not have assymetric traffic patterns then you are in luck. This is the easiest deployment scenario. You can have multiple IDSM-2s in each switch. Each IDSM-2 would be configured to monitor one or more vlans using VACL Capture. The performance limitations are 600 Mbps times the numbers of IDSM-2s you purchase and can fit in the switch.
If traffic is being routed, however. You once again run into a situation where a single IDSM-2 has to monitor all of the vlans in the switch (when using VACL Capture). There is an interaction between the routing features of the switch/msfc which force a single IDSM-2 (per switch if no assymetric traffic patterns) to be used to monitor all of the vlans in that switch.
And you are now limited to the 600 Mbps limitation (or 2*600Mbps if you place one in each switch and there are no assymetric traffic patterns).

IDSM-2 load sharing across two chassis

We are currently putting together a solution that I have come in halfway through just after some assistance in regards to setting up the IDS. We have 2 * 6509 chassis, 2 * IDSM-2 modules.
Scenario 1 - Both IDSM-2 Modules in primary chassis, can load balance traffic to IDS. Primary Chassis failure = no ids.
Scenario 2 - IDSM-2 Module in each chassis, active/standby scenario. Can basically only use one IDSM modules throughput. Chassis failure still have IDS.
At the moment I am leaning towards the first scenario and no IDS if we have a chassis failure. Just wondering if it's possible to load balance in scenario 2.

Hi,
I guess it depends on your topology. If your 6509 switches are used as layer 3 switches using HSRP then even if only one 6509 is used as HSRP active for all VLANs and you have two IDSMs in there, you will miss all the traffic that is going through your HSRP standby chassis. For example, outbound traffic of a VLAN may be seen by HSRP Primary's IDSMs, but return traffic could be comming in both directions (HSRP Primary and Secondary 6509s). If you have one IDSM on each 6509s, then you are already using both of them. Please note that IDSM2's throughput is 600 Mbps.
Thank you.
Edward

Are multiple VXI controllers in a single chassis allowed?

I am currently searching for a VXI controller card that:
1) Accepts two input buses (USB/MXI-2, or USB/IEEE).
-or-
2) Is it possible to have two USB VXI controllers in the same chassis? I believe it is possible to have two IEEE controller cards in the same chassis.
My task is to see if it is possible to have two independent computers talking to the same VXI chassis. Arbitration would be an issue leading me to suspect that question (1) would be the most hopeful. Any information is highly appreciated.
Sincerely,
Bill B.

Bill,
One of the advantages of VXI is the multiple controller option.
Without know more about your application, here's a couple possibilities that may help:
1. If continuous monitoring is primary AND there's a PCI DAQ card that meets your needs, then consider using a VXI-USB controller in Slot 0 for communication to a host and a VXI-872B with an internal PCI slot for monitoring the voltages.
2. If multiple host monitoring is primary AND there's a PCI DAQ card that meets your needs, then consider using a VXI-872B in slot 0. The multiple hosts can use ethernet and client/server software to talk with the 872B.
3. If you need VXI-based DAQ boards, then you could possibly use a VXI-USB controller in slot 0 and use the 872B to monitor the VXI DAQ board. The PC connected to the USB controller could potentially broadcast to others via ethernet.
Hope this helps,
Alex.

Two CSM's in single chassis

hi folks
if we install two CSM's in the same 6500, can we load balance serverfarmA using CSM1 & serverfarmB using CSM2.
would the csm's be in csm mode or rp mode? would we need to configure them identically or use hsrp for failover?
any ideas appreciated since i have 0 experience with content stuff.
thanks,
anurag

there is no more rp mode. Everything must be csm mode nowadays.
If you put 2 CSM in the same chassis, they can workd independently and therefore be both acitve, or you can have the same config on both and work in active/standby.
With version 4.2.x and the corresponding ios version, there is a command to sync the config between active and standby so you don't have to configure everything twice. The command is 'hw-module ContentSwitching X standby config-sync'.
Regarding the serverfarm the question is not really important. You first have to decide if you want to be active/standby or active/active.
Be aware that if you go for active/active you have no backup [you can't be active and standby at the same time] and you will have to split your traffic between the 2 CSM by configuring different vservers on each.
Gilles.

Wism2 redundancy in two C6513 chassis - Lost heartbeat with the Supervisor

I get a lot of messages in the trap log "Lost heartbeat with the Supervisor"
The controller seems to be up and running. Failover works perfectly.
Why do I get these messages?
Rgds Snorre

HI Snorre,
I get a lot of messages in the trap log "Lost heartbeat with the Supervisor"The controller seems to be up and running. Failover works perfectly.Why do I get these messages?
There are several possible reasons that this error message is generated. From the WiSM's perspective, the most common reason is an incorrect configuration of the service port on the Supervisor Engine.
In the case of a WiSM, the service port is used solely for communication between the Supervisor and the WiSM.
Complete these steps in order to get rid of this error message:
1. Create a new VLAN for the WiSM service ports on the Supervisor Engine that does not exist anywhere on the network.
2. Create a DHCP scope setup on your Supervisor to assign IP addresses to the service ports of the controllers.
Note: It is recommended that you create a DHCP scope for the service port of the Catalyst WiSM. Alternatively, you can also session (session slot X process 1 or 2 ) or console directly into the WiSM and set the static IP addresses with the configure interface address service-port command.
3. Assign the WiSM service ports to this newly created VLAN with the command wism service-vlan new VLAN ID on the Supervisor Engine.
This VLAN is used for the Supervisor Engine to communicate with the service port of the WiSM. Refer to Configure Communication Between the Supervisor and Cisco WiSM for more information on how to configure the procedure mentioned here.
Cisco bug ID CSCsg59144 is also associated with this error message.
Other possible reasons might be with the backplane connection of the module to the chassis This can be verified by first moving the WiSM to another slot and see if it continues. Sometimes, this might be an issue with the module itself. But these are rare circumstances.
Example:
Configure Communication Between the Supervisor 720 and Cisco WiSM
After the Cisco WiSM controller is installed in a slot and detected by the Supervisor, these configurations are made on the Supervisor Engine to communicate with WiSM.
1. Create a DHCP scope for the Service-Port of the Catalyst WiSM.
ip dhcp excluded-address 192.168.10.1 192.168.10.2
ip dhcp pool wism-service-port
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
Alternatively, you can also session (session slot X proc 1 or 2 ) or console directly into WiSM and set static IP addresses (config Interface Address Service-Port).
Make sure that the service port IP address is not a routable IP address in your network because it is only used for communication between the Sup 720 and the WiSM.
Note: VLSM is supported on all ports, which includes the Service port.
2. Create the WiSM Service Port Gateway and assign the IP address.
Create a VLAN in the Supervisor 720. This VLAN is local to the chassis and is used for communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit Interface on the Supervisor and a service port in the Cisco WiSM.
    interface Vlan192
    Description WiSM Service Port Gateway
    ip address 192.168.10.1 255.255.255.0
Note: There should already be a network management VLAN interface to reach the Cat6k.
3. Assign the WiSM Service Ports to a VLAN.
Configure this command to use VLAN 192 to communicate with the service-port.
    wism service-vlan 192
Hope it helps.
Reagrds

Single or dual 4500e for redundancy

I apologize if this has been asked before, but I haven't been able to find a solid answer when searching.
We're deploying a new datacenter and will have 20 racks of servers, mostly 1u. Given our bandwidth needs which are reasonably modest we're planning on using dual 2960s switches at the top of the racks and aggregating on a single or dual 4500e using 10gig links. The 4500e(s) will also have a bunch of 1gb devices such as firewalls, routers, and load balancers connected to them. Pretty typical network core. Given the need for 40 10gb links to racks and then another 20-or-so 1gb, the 4500e chassis seems to fit the bill.
My question is, do we go with a single 4507e with full redundancy (dual 10gb cards, one link to each from each rack, dual 1gb card, and dual supervisors) or a pair of either 4506e switches each with their own cards. With a virtual chassis the 4506e is appealing, but I'm not up to speed on any limitations that might impose. With IISU and the like does having two physical chassis vs everything in a single actually buy us anything if they're going to be in the same physical proximity anyway? A big reason to go with the single chassis is space - 11 rack units vs 20.
If we do go with a single chasis, other than Cisco's HA docs on the 4500e, is there any documentation or case studies that I could use to sell the idea to management? A number of people, especiailly those in favor of a ton of cheap netgear switches, argue that a single chassis is a single point of failure and we should never do it.
Thanks!

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
As you've described, the problem with any single chassis, the chassis itself can become a single point of failure even when loaded with redundant components. Independent chassis (e.g. VSS, StackWise) provide chassis redundancy although it does raise a question on software redundancy, i.e. multiple chassis are running some form of tightly coupled chassis OS vs. standalone chassis. Standalone chassis should be, in theory, the most redundant but they too create issues such as load sharing and asymmetrical path issues (e.g. unicast flooding). If you understand and trust a multi-chassis OS, I personally think it's often the "better" redundancy option.
I don't know if VSS on the 4500s support it, but 6500 VSS supports quad supervisiors, so if you lose a single sup on those you don't lose one of your VSS chassis pair.
Regarding your later post on using a 4500-X VSS pair, yes that might be an idea core for high density 10g. For twenty 10g ports each, you would need either the 16 port with the optional 8 port module or the 32 port model.
Depending on your remote rack setups, you might also consider 3750-Xs, stacked, in lieu of multiple (individual cabinet) ToR 2960S pairs. StackWisePlus is a much better stacking technology then FlexStack. Yes, the 3750-Xs are more expensive, but you might need less if you can bring multiple racks to the same 3750-X stack. (Depending on how many downstream stacks you actually need, you might also reduce your need for 10g ports on the core.) Depending on your feature needs, you might even be able to use the LAN Base models which in the later IOSs also support StackPower.
10g is nice, but it's also expensive. When working with switches within 100m, don't overlook the possibilities of gig copper Etherchannels. For example compare total cost of 8xgig (copper) build-in ports vs. single 10g (fiber) especially if special module is required.

Configuring 6513 Redundancy

i have two 6513 switches. each has 2 supervisor engines ( with msfc), a fwsm, idsm, nam, and 2 gigabit ethernet modules. One of them has been fully configured with redundancy btw the sup engines (using the high availability option) and the msfcs (using hsrp). How do i configure the second one such that the 2 switches will both be on the network and provide full redundancy btw them

Hi K.Adepetu,
Yo have redundancy between the 2 sups in single chassis there are many ways but 2 have redundancy between 2 completely different chassis has only one way which is HSRP.
So better idea will be to have SRM (Single Router Node) redundancy between the 2 sups in same chassis in this case one 1 sup will be active and if something happen to the active sup the 2nd sup will take over.
And configure HSRp between the sups in 2 different chassis so that if both the sup in same chassi go down the sup in second chassis will come up.
I will give you to link to have a look at it closer
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_7_2/confg_gd/redund.htm#wp1058202
This link wil lguide you how to configure 2 different chassi with 2 sup each for full redundancy.
HTH
Ankur

IDSM-2 Performance

IDSM-2 gives 500Mbps in IPS mode and 600Mbpgs in IDS mode. Bundling 4 IDSM-2 in single chassis gives 2Gbps performance with Sup 32. But the FWSM provides 5Gbps throughput and the Sup 720 supports 40Gbps switching. What is the disconnect here? How do you design your IDSM-2s to support 5Gbps throughput when you have a single FWSM supporting 5Gbps?

If you exceed the monitoring capability of the sensor, then packets that can not be monitored will be dropped by the sensor.
NOTE: 500Mbps is not an absolute performance number for the sensor. It is a performance level that the sensor has been testeed to be able to handle for specific types of traffic used in the performance test. It is unknown exactly how much traffic the sensor will be able to handle for your network. The IDSM-2 will likely handle AROUND 500 Mbps is many and even most customer networks. However, networks do vary and in some networks it may handle quite a bit less traffic, and in other networks might handle even more.
So the question isn't what will happen if you send more than 500 Mbps, but rather what will happen if you send more of your traffic than what the sensor is able to monitor. And the answer is that any traffic that can not be monitored because of performance limitations will be dropped by the sensor.
The only time packets are forwarded without inspection is if sensorApp has stopped monitoring ALL packets (either a reconfiguration or upgrade is taking place, or the sensorApp process has crashed) AND the auot software bypass functionality has kicked in. In which case ALL packets would be forwarded without analysis.

IDSM Traffic Exclusion

Is it possible to exclude traffic which be default goes to IDSM. I have following scenario:
LAN-->IDSM->FWSM-->Server VLAN
IDSM and FWSM are in one single chassis and all the traffic coming from LAN is captured and forwarded to IDSM before it hits FWSM. I need to exclude some traffic that should not get captured and gets forwarded to IDSM but should hit FWSM directly.
Following configuration exist currently:
vlan access-map idsm-map 10
match ip address idsm-acl
action forward captured
access-list ext idsm-acl
10 permit ip any any
I was thinking of doing following for exclusion:
vlan access-map idsm-map 10
match ip address idsm-acl
action forward captured
vlan access-map idsm-map 20
match ip address idsm-acl-1
action forward
access-list ext idsm-acl
1 deny any host 10.1.1.1
10 permit ip any any
access-list ext idsm-acl-1
10 permit ip any host 10.1.1.1
Will later configuration stop any traffic for destination 10.1.1.1 bypass IDSM or is there any other way aroud to achieve this on IDSM itself.
Later
Omair

Hi Omair,
Not sure, I understand. I did discuss the second map statement:
The traffic to 10.1.1.1 will not match this clause and so it won't be captured but will match the next clause and be forwarded. Of course, your second access-list could have been "10 permit ip any any" and it would work since all that should make it to this clause is traffic to 10.1.1.1. Assuming everything else is correct in your configuration, it should work.
I am referring to each vlan map statement as "clause". So, you did this right...the single host traffic won't match the first clause (vlan map) and will proceed to the next clause (vlan map statement). I don't see a problem with your configuration except, the missing "ip" in the access-list.
Does that make sense?
Regards,
RA

Reposting: Chassis Management Module (CMM) Fails to Switch Over

This post was originally posted on IBM’s developerWorks public forum (https://www.ibm.com/developerworks/community/forums/html/topic?id=f9164eb4-1a74-42b3-8348-28dfa24caf... The following is a summary of the post issue and the response.
Issue:
I'm facing an issue regarding the PureFlex Chassis Management Module (CMM) failover scenario such that I have two CMM’s installed in a single chassis connected to two ports of a switch.
When accessing the CMM through the IP address, the CMM is accessible.
However, when the switch port connected to the active CMM is shutdown or disconnected, the CMM is not failing over to Standby and there is no ping response to CMM.
What is causing this behavior and how do I resolve it?
Solution/Response:
None
Attachments:
CMM Image.png ‏411 KB

Ah, ok. I was in the assumption the PCI connect had something to do with the video connection. But it seems like Apple wanted to reinvented PCIe...
I'm out of my territory here so feel free to ignore the following.
These are the things I notice in your Xorg.0.log:
[ 19.474] (==) modesetting(G0): Depth 24, (==) framebuffer bpp 32
[ 19.474] (==) modesetting(G0): RGB weight 888
[ 19.474] (==) modesetting(G0): Default visual is TrueColor
[ 19.474] (II) modesetting(G0): ShadowFB: preferred YES, enabled YES
[ 19.500] (II) modesetting(G0): Output VGA-1-0 has no monitor section
[ 19.526] (II) modesetting(G0): EDID for output VGA-1-0
[ 19.526] (II) modesetting(G0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[ 19.526] (==) modesetting(G0): DPI set to (96, 96)
What the hell is modesetting doing there?
And have you tried the nvidia blob? It could be that this is not well supported by nouveau. Maybe check up with their IRC / mailing list.

IDSM-2 inline between multible VLAN

Hi,
I have a coreswitch 6509 which is include IDSM-2 actully the core switch handle the traffice between the usres VLANs and the server Vlan (vlan 11)
The users Vlan are (Vlan 2 , 3, 4, 5, 6 and 7). I need to configure the core switch and IDSM to be inline between the Users VLANs and the Server farm Vlan to inspect the traffic comming from the useres.
as my understanding I can use the ISDM inline mode between multible Vlan but unfortunattly my test to drop the ICMP request to server is faild.
Kindly advice if that available or it should be only in promisecouse mode.
also if there any sample of succesfully configuration.
my configuration is as below:
Core-SW-RYD#sh run | in intr
intrusion-detection module 9 data-port 1 trunk allowed-vlan 2-7,11
intrusion-detection module 9 data-port 2 trunk allowed-vlan 2-7,11
intrusion-detection module 9 data-port 1 autostate include
intrusion-detection module 9 data-port 2 autostate include
intrusion-detection module 9 data-port 1 portfast 1
intrusion-detection module 9 data-port 2 portfast 1
VLAN Name                             Status    Ports
1    default                          active    Gi9/2, Gi9/3, Gi9/4, Gi9/5, Gi9/6
2    Food-D-VLAN                      active
3    Comm-D-VLAN                      active
4    Emar-D-VLAN                      active
5    Finance-D-VLAN                   active
6    Glucose-D-VLAN                   active
7    IT-D-VLAN                        active    Gi1/3
11   servers-Vlan                     active    Gi1/2, Gi1/4, Gi1/5, Gi1/6, Gi1/7, Gi1/8, Gi1/9, Gi1/10, Gi1/12, Gi1/13
                                                Gi1/14, Gi1/15, Gi1/16, Gi1/17, Gi1/18, Gi1/19, Gi1/20, Gi1/21, Gi1/22
                                                Gi1/23, Gi1/24, Gi1/25, Gi1/26, Gi1/27, Gi1/28, Gi1/29, Gi1/31, Gi1/32
                                                Gi1/33, Gi1/34, Gi1/35, Gi1/36, Gi1/37, Gi1/38, Gi1/39, Gi1/41, Gi1/42
                                                Gi1/43, Gi1/44, Gi1/45, Gi1/46, Gi1/47, Gi1/48, Gi2/10, Gi2/11, Gi2/12
                                                Gi2/13, Gi2/15, Gi2/16, Gi2/18, Gi2/19, Gi2/20, Gi2/21, Gi2/22, Gi2/23
                                                Gi2/24, Gi3/1, Gi3/2, Gi3/3, Gi3/4, Gi3/5, Gi3/6, Gi3/7, Gi3/8, Gi3/9, Gi3/10
                                                Gi3/11, Gi3/12, Gi3/13, Gi3/14, Gi3/15, Gi3/16, Gi3/17, Gi3/18, Gi3/19
                                                Gi3/20, Gi3/21, Gi3/22, Gi3/23, Gi3/24
your support will be highly appreciated.
Best Regards,
Magdy

Hi Mohamed.
with inline mode, you can only bridge vlans in pairs uniquely!. so you can only bridge vlan 11 to another single vlan. and remember since they are bridged, that means the 2 vlans need to have the same ip subnet.
but looking at your requirements, i'm guess the different vlans are on different ip subnet ranges.
In that case, you'll need to do promiscuous mode.
However in promiscuous mode, you can only do acl blocking. and first packet will pass successfully but will trigger the sensor to configure the router to create an acl, and further packets will be dropped.
However if you redesign a bit you can use promiscuous mode. for example create a new layer 2 vlan (let's say 14), move the servers to this vlan.
You only need to trunk vlan11 and vlan14 to the idsm module, then create a single vlan-pair on the IPS which bridges vlan11 and vlan 14. then configure the signature to drop packets inline. SInce now for the clients who need to contact the servers need to pass traffic to vlan11, and the idsm is in the middle between vlan 11 and 14, then it should drop pings to the servers.
Regards,
Fadi.

NX-OS Nexus 7018 License-id for Chassis or Supervisor

Hello,
For a single chassis supervisor, if we have license for VDC for 7018 Chassis, and we want to change the single supervisor with a spare one, can we install the backed-up license from the supervisor to the new supervisor. This is important because if the license is chassis based, we may be able to use the same license file for the spare supervisor, or if it is supervisor based we may need to contact TAC for a license rehosting procedure.
Also, if a grace period starts for a demo purpose, and after 120 Day grace period, is it possible to repeat the demo or poc with restarting the grace period, or a license needs to be bought?
Thanks in Advance,
Best Regards,
On the NX-OS Licensing guide it mentions about the serial number of the device (but we could not be sure if the device means chassis or supervisor)
Obtaining the License Key File
You can obtain new or updated license key files.
Procedure
Step 1
Obtain the serial number for your device by entering the show license host-id command. The host ID is also referred to as the device serial number.switch# show license host-idLicense hostid: VDH=FOX064317SQ
Tip
Use the entire ID that appears after the equal sign (=). In this example, the host ID is FOX064317SQ.

License is based on chassis serial number seen under show inventory. If you look at the License file name it is named with chassis serial number. If you replace the supervisor you do not need to transfer license by calling TAC but you can copy the license file to new supervisor bootflash and run install license command from bootflash to install license into new supervisor.

IDSM-2 "redundancy" in a single chassis

Similar Messages

Maybe you are looking for