ACE switching-mode command
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2014 04:32 AM
Hy guys.
Can anybody explain what exactly the "switching-mode" command does?
Thanks!
- Labels:
-
Application Networking
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2014 05:38 AM
HI David,
Please go to the below link and visit section "configuring switch mode"
Switching mode basically is used when you have traffic passing through ACE which doesn't match any existing policy, nat, ACL etc. ACE will not apply normalization and treats those connections as "stateless". By default, ACE will apply normalization and will not allow stateless connection like let's say a SYN-ACK received on ACE whose SYN was never seen. You can read in detail in above link.
Let me know if you have any questions.
Regards,
Kanwal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2014 03:06 AM
Hi Kanwal.
Sorry for my explanation. Let me explain you what my problem is.
I have my ACE deployed in Bridge Mode and in the server VLAN I have servers that are not balanced and are accessed directly (without a VIP).
The problem is that when a client access this servers, we don't see any return packet from de server. If we move the server from server vlan to client vlan, it works fine.
I think the problem is normalization in ACE due to lack of switch-mode command.
Can be?
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2014 09:07 AM
Hi David,
A quick test would be to disable "Normalization" and check if it works fine. Plus ACE will not SYN-ACK or ACK etc if it didn't see the correspoding SYN. So if the client came to the ACE and went to the server and server replies directly and client gets that packet, i don't think it should be problem but problem will be when client replies with "Normalization" enabled since ACE never saw server side connection and client reply will not make sense to ACE and it will drop it.
So if client sends SYN
server sends SYN-ACK--->ACE never saw that.
Client sends ACK---->ACE will drop it since it has no idea why this ACK is coming.
Regards,
Kanwal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2014 09:28 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2014 03:05 PM
Hi David,
I was just giving a general example of how normalization can affect the flows.
Regards,
Kanwal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-13-2014 09:09 AM
Hi David,
First confirm that the gateway is set correctly on the servers. It must be the MSFC IP. Secondly, take captures to see where whether ACE is getting the response and forwarding it to MSFC or not.
If it is an ACE module then you will have to take capture the switch backplane Tengig interface of the switch. If it is an ACE appliance then take sniffer capture on the switch interfaces connected to the Appliance. Make sure that both server and client vlan traffic is captured in the same file so complete flow can be viewed.
Here is the procedure to take sniffer on tengig interface:
The ACE's tengig port is always <ace-slot>/1.
Let's say your ACE is in slot 3. It's backplane interface would then be
Te3/1. You then use the monitor command to configure the source (SPAN)
port to this interface.
monitor session 1 source interface TenGigabitEthernet 3/1 both
monitor session 1 destination interface GigabitEthernet x/y
monitor session 1 filter vlan 510 - 511 , 640 , 652 - 656 <----
Line is optional and will capture only specified VLANs
Configure the destination (SPAN) port as a trunk port so that the VLAN
IDs will be preserved:
interface Gix/y
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
Be sure that the network analyzer connected to the destination port can
monitor VLAN tags (a trunked port). Here is a link on how to configure
NICs using some of the Intel chipsets to pass the VLAN tagging info:
http://support.intel.com/support/network/sb/CS-005897.htm
Wireshark has posted this info, as well as how to configure NICs with
the Broadcom chipset:
http://wiki.wireshark.org/CaptureSetup/VLAN#head-e0dc0f9fe0cc6b1b1866d78
da7b97ead34dca1d8
With IOS Release 12.2(18)SXD and later releases, when a destination port
is a trunk, you can use the list of VLANs allowed on the trunk to
filter the traffic transmitted from the destination port. This should
not be necessary if you configured the optional 'filter' line in the
monitor session configuration.
interface Gix/y
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 102, 103
switchport mode trunk
switchport nonegotiate
Thanks,
Hasham
