CSM not working with UDP (DNS)

[rob.bettinson]

Hi,

I have a CSM configured to load balance a pair of servers hosting a Web Applicaiton and DNS.

The Web App work sfine but the CSM seems to be ignoring the DNS requests, can anyone see a mistake here? I've attached the exerpt from the config and the output showing that it is not matching the rule...

This should just work, so I hope it's a simple mistake I haven't spotted!

Thanks,

Rob

[Gilles Dufour]

as you said, this should work.

If the vserver does not show any hit or incoming packet, it means the traffic is not making it to the CSM.

Capture a sniffer trace of the CSM portchannel to verify that.

Gilles.

[rob.bettinson]

Hi Gilles,

I have performed a trace and the results would seem to confirm the CSM is not behaving properly.

We used a 'monitor seesion 1 source vlan x' to capture the traffic on the client vlan of the CSM.

The IP range used for virtual services is 10.x.34.0/24. There is a static route from the MSFC to the primary CSM address.

One affect of this is that any packet sent to an IP in the 10.x.34.0/24 range which is not processed by a CSM virtual rule is forwarded by the CSM through the default route, which is back into the MSFC. This causes the packet to bounce between the MSFC and CSM until the TTL expires.

This is exactly what I see in the trace for UDP packets.

The first packet appears with a source MAC of the MSFC (00:17:0f range) and a destination of the CSM primary (00:13:c3 range).

The same packet then appears with a source of the CSM from a different MAC range (00:01:64) and a destination of the HSRP on the MSFC which is default gateway for the CSM.

This pairing of packets continues until the TTL expires...

So, the CSM must have processed the packet but decided it does not match a vserver... where do I go next?

Rob

[Gilles Dufour]

why do you have this vserver forwarding back to the msfc ???

This does not seem to be useful.

suspend it.

Then do a 'clear mod csm X conn' and try again.

Gilles.

[rob.bettinson]

No, the vserver does not forward the unknown traffic, it's just the routing table of the CSM.

The CSM has a gateway of the MSFC through which it communicates with the rest of the platform through the client vlan.

The expected behaviour (as works for the TCP/80 traffic) is for incoming packet 10.x.34.9:80 to be matched to the vserver and server nat the packet to the selected real IP, then output the packet on the server vlan.

For DNS we see the packet coming in for 10.x.34.9:53 and because the CSM isn't matching the vserver for some reason it acting as a router and forwarding the packet to the next hop, which happens to be the default gateway.

It is something I should cover with an acl or blackhole the unused IP, but I don't believe it is the problem here...

This configuration is working for TCP but not UDP, I don't understand why it is any different for the CSM?

[Gilles Dufour]

the csm does not route traffic coming from client by default.

Only a vserver with predictor forward can force the csm to route the traffic.

Please attach your full running config and I'll tell you what is wrong.

Gilles.

[rob.bettinson]

Hi there!

Thanks for looking at the config, which as you say should have worked, *phew* :)

I raised a case and discovered it is a know bug:

BUG# CSCek45794

With the variable ROUTE_UNKNOWN_FLOW_PKTS set to 2, the CSM drops all UDP traffic that is directed to virtual servers.

So it's fixed in 4.2(4) and we were running 4.2(3a), gutted!

Have upgraded and all looks fine.

Thanks for all you help,

Rob