Re: CSM Fault Tolerance and IGMP Snooping

glenn.newman · ‎02-28-2005

For "connection redundancy" the redundancy guide says to turn off IGMP snooping.

Is there any way around this?

I need to have multicasting everywhere and I don't want to multicast all streams to every port on this switch.

Gilles Dufour · ‎03-01-2005

if you are using native ios you can do this

- in native IOS, IGMP snooping can be disabled on a per-vlan basis.

This requires the creation of the corresponding L3 interface (int vlan X), from where you can disable igmp snooping. No need to bring that interface up (leave it "shutdown") and no need to assign an IP addressto the vlan.

This is only required on the FT vlan.

Regards,

Gilles.

glenn.newman · ‎03-01-2005

Thanks, I will give that a try.

I am running Native 12.2(17d) with Sup 720s. The CSM is at 4.2.1.

I have not been able to get the load balancer to work through the VIP. I get connection refused. I am starting a TAC case on this. I removed all FT commands and I am trying to get this to work in the simplest possible config. Here is the config:

module ContentSwitchingModule 2

vlan 246 client

ip address 10.10.249.5 255.255.255.240

route 0.0.0.0 0.0.0.0 gateway 10.10.249.3

!

vlan 247 server

ip address 10.10.249.19 255.255.255.240

alias 10.10.249.17 255.255.255.240

!

serverfarm SOFT1

nat server

no nat client

failaction purge

real 10.10.249.20

inservice

real 10.10.249.21

inservice

!

vserver SOFTRICITY

virtual 10.10.249.6 any

serverfarm SOFT1

persistent rebalance

inservice

!

glenn.newman · ‎03-01-2005

The command "no ip igmp snooping" worked on the vlan interface.

Perhaps you can see if I am doing something wrong. I am testing this with two 3550s with web enabled acting as the servers plugged into a 48 port module with ports in the server vlan. I can ping them and they can ping the csm vlan IP.

Here is the whole config with some show commands at the bottom.

Gilles Dufour · ‎03-02-2005

I don't see anything wrong in your config.

Can you capture a 'sho mod csm X real' and a 'sho mod csm X vserver' and a 'sho mod csm X vserver name detail'

Also check on the gateway if you can ping the vip and if you have an arp entry associated with the VIP.

Make sure the servers have a default route pointing to the alias of the CSM.

Regards,

Gilles.

glenn.newman · ‎03-02-2005

Most of the show statements are at the end of the attached file in an earlier post. The vservers details are at the end of this post.

I have an ARP entry for the VIP - 0001.64f9.1a64, but it does not respond to pings. I tried both the alias and the server vlan IP as the default gateway of the servers.

I took a trace and found that the VIP sends a TCP reset immediately after a request. I have tried versions 4.2.1 and 4.1.4 with the same result. I wonder if this could be a problem with the Sup720 with 12.2.17d IOS. I also tried the CSM in slots 2 and 3.

720Test2#sh mod csm 3 vserver detail

SOFTRICITY, type = SLB, state = OPERATIONAL, v_index = 10

virtual = 10.10.249.6/32:0 bidir, any, service = NONE, advertise = FALSE

idle = 3600, replicate csrp = none, vlan = ALL, pending = 30, layer 4

max parse len = 2000, persist rebalance = TRUE

ssl sticky offset = 0, length = 32

conns = 0, total conns = 1

Default policy:

server farm = SOFT1, backup =

sticky: timer = 0, subnet = 0.0.0.0, group id = 0

Policy Tot matches Client pkts Server pkts

---------------------------------------------------

(default) 1 1 0

glenn.newman · ‎03-02-2005

Most of the show statements are at the end of the attached file in an earlier post. The vservers details are at the end of this post.

I have an ARP entry for the VIP - 0001.64f9.1a64, but it does not respond to pings. I tried both the alias and the server vlan IP as the default gateway of the servers.

I took a trace and found that the VIP sends a TCP reset immediately after a request. I have tried versions 4.2.1 and 4.1.4 with the same result. I wonder if this could be a problem with the Sup720 with 12.2.17d IOS. I also tried the CSM in slots 2 and 3.

720Test2#sh mod csm 3 vserver detail

SOFTRICITY, type = SLB, state = OPERATIONAL, v_index = 10

virtual = 10.10.249.6/32:0 bidir, any, service = NONE, advertise = FALSE

idle = 3600, replicate csrp = none, vlan = ALL, pending = 30, layer 4

max parse len = 2000, persist rebalance = TRUE

ssl sticky offset = 0, length = 32

conns = 0, total conns = 1

Default policy:

server farm = SOFT1, backup =

sticky: timer = 0, subnet = 0.0.0.0, group id = 0

Policy Tot matches Client pkts Server pkts

---------------------------------------------------

(default) 1 1 0

Gilles Dufour · ‎03-03-2005

Looks like a server issue.

Are you sure the CSM is the default gateway for the servers ?

The 'sho mod csm x vser name detail' shows zero packet received from the server.

The 'sho mod csm x stats' shows 5 connections created and 5 connections failure - again this would indicate a server issue since a failure is counted when the server does not respond or when the server sends a RESET.

So, I would sniff on the server to see what going on and where the traffic is forwarded.

Regards,

Gilles.

glenn.newman · ‎03-03-2005

The server is in the client vlan so default gateways should not play into this. The network trace attached shows that the server is making the request and that the VIP is doing a TCP reset.

glenn.newman · ‎03-03-2005

Sorry, I meant to say I the client is in the client vlan in a port on the 6509.

Gilles Dufour · ‎03-04-2005

that's your problem.

The gateway does matter, wherever you place the server.

The reason is that the CSM MUST see the response from the server.

If the client and server are in the same vlan, the response from the server will go directly to the client bypassing the CSM.

THe CSM MUST see the response to reverse nat the server ip address to the VIP address.

If you want the server to be in the same vlan as the client, you need to configure 'client nat'.

Configure a natpool with 1 free ip address and under the serverfarm use 'nat cllient '

Regards,

Gilles.

glenn.newman · ‎03-04-2005

I agree the server's gateway matters. I am saying the clients gateway should not matter if the client is in the same vlan and the same subnet as the VIP. Is this incorrect?

Also the gateway for the client vlan in the CSM config is the vlan interface IP of the 6500.

The servers and the clients are in different vlans. The servers can ping their default gateway. The client can ping the IP of the vlan interface and the IP of the CSM client vlan. I cannot ping the VIP from the 6500 or the client that is in the same subnet. At one point I could ping the VIP from the 6500 and a client. I don't know what has changed to prevent that.

Gilles Dufour · ‎03-06-2005

if your vip is layer3, the icmp request is loabalanced and the server has to respond.

If you have L4 or L5 rule, the CSM will repsond to the ping.

So, once again, it looks the resposne from the server is not coming back to the CSM.

When talking about the gateway, I'm talking about the server. The server gateway must be the CSM.

Try the natpool solution if you don't have access to the server.

Gilles.

glenn.newman · ‎03-07-2005

Thanks for the expalanation of ping with the L3 or higher rules. I was switching between using specific ports to service or the whole IP range.

My traces show that the client gets an immediate TCP reset to a telnet or http request and the CSM never makes a request to the servers. I started a TAC case and they pointed out that the servers VLAN and alias is sending a gratuitous ARP every 10s or so. Attached are traces from the client and server VLANs during a request.

I started TAC case 600994677 on this. So far a week has gone by and we haven't made much progress.

Gilles Dufour · ‎03-08-2005

Glenn,

it appears that your client is in the same vlan as the CSM.

The CSM has a strange security function.

It does not allow connection from client if the client mac-address is not known at the time of the connection.

Moreover, the CSM will not send arp request for clients.

So, you should configure a vlan between the CSM and the MSFC and have all your client going to the CSM via the MSFC.

This guarantees that the MSFC knows the source mac [MSFC - learned via the 'gateway' command'].

So, could you try to do this modification and let us if it works.

Thanks,

Gilles.