Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

LocalDirector 430 and synguard behavior

Hi

I recently had to diagnose a problem with an LD. A percentage of people trying to connect to a website being loadbalanced by a LD430 could not connect to it. I finally tracked it down to synguard being active on the virtual ip. shutting down synguard resolved this issue, but, I could not find a good explaination of:

1. How does synguard actually operates

2. Why a certain number of users could not connect at all, while others could.

The users are running 2000, xp, and in one case server 2003.

The site from my laptop was always available, but operated slowly.

I have attached a trace from linux that shows the first syn packet either being dropped or delayed by more than 3 seconds.

[root@linus root]# tcpdump src or dst virtual-web-site-ip

tcpdump: listening on eth0

// nc -z virtual-web-site-ip 80

12:54:37.273385 client-computer.52567 > virtual-web-site-ip.http: S 3386988436:3386988436(0) win 5840 <mss 1460,sackOK,timestamp 272875253 0,nop,wscale 0> (DF)

12:54:40.270071 client-computer.52567 > virtual-web-site-ip.http: S 3386988436:3386988436(0) win 5840 <mss 1460,sackOK,timestamp 272875553 0,nop,wscale 0> (DF)

12:54:40.321252 virtual-web-site-ip.http > client-computer.52567: S 2282228414:2282228414(0) ack 3386988437 win 1460 <mss 1380,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

12:54:40.321368 client-computer.52567 > virtual-web-site-ip.http: . ack 1 win 5840 <nop,nop,timestamp 272875558 0> (DF)

12:54:40.321758 client-computer.52567 > virtual-web-site-ip.http: F 1:1(0) ack 1 win 5840 <nop,nop,timestamp 272875558 0> (DF)

12:54:40.375928 virtual-web-site-ip.http > client-computer.52567: . ack 2 win 65535 <nop,nop,timestamp 3371252 272875558> (DF)

12:54:40.376420 virtual-web-site-ip.http > client-computer.52567: F 1:1(0) ack 2 win 65535 <nop,nop,timestamp 3371252 272875558> (DF)

12:54:40.376473 client-computer.52567 > virtual-web-site-ip.http: . ack 2 win 5840 <nop,nop,timestamp 272875563 3371252> (DF)

This show that site response imediately after the second syn packet is dispached. Any idea if it is responding to the first syn packet or to the second?

// nc -z virtual-web-site-ip 80

12:54:41.253532 client-computer.52568 > virtual-web-site-ip.http: S 3391553104:3391553104(0) win 5840 <mss 1460,sackOK,timestamp 272875651 0,nop,wscale 0> (DF)

12:54:44.250048 client-computer.52568 > virtual-web-site-ip.http: S 3391553104:3391553104(0) win 5840 <mss 1460,sackOK,timestamp 272875951 0,nop,wscale 0> (DF)

12:54:50.250065 client-computer.52568 > virtual-web-site-ip.http: S 3391553104:3391553104(0) win 5840 <mss 1460,sackOK,timestamp 272876551 0,nop,wscale 0> (DF)

12:54:50.301123 virtual-web-site-ip.http > client-computer.52568: S 3928048759:3928048759(0) ack 3391553105 win 1460 <mss 1380,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

12:54:50.301237 client-computer.52568 > virtual-web-site-ip.http: . ack 1 win 5840 <nop,nop,timestamp 272876556 0> (DF)

12:54:50.301576 client-computer.52568 > virtual-web-site-ip.http: F 1:1(0) ack 1 win 5840 <nop,nop,timestamp 272876556 0> (DF)

12:54:50.355793 virtual-web-site-ip.http > client-computer.52568: . ack 2 win 65535 <nop,nop,timestamp 3371352 272876556> (DF)

12:54:50.356533 virtual-web-site-ip.http > client-computer.52568: F 1:1(0) ack 2 win 65535 <nop,nop,timestamp 3371352 272876556> (DF)

12:54:50.356586 client-computer.52568 > virtual-web-site-ip.http: . ack 2 win 5840 <nop,nop,timestamp 272876561 3371352> (DF)

// nc -z virtual-web-site-ip 80

12:55:03.122746 client-computer.52570 > virtual-web-site-ip.http: S 3417053345:3417053345(0) win 5840 <mss 1460,sackOK,timestamp 272877838 0,nop,wscale 0> (DF)

12:55:06.120068 client-computer.52570 > virtual-web-site-ip.http: S 3417053345:3417053345(0) win 5840 <mss 1460,sackOK,timestamp 272878138 0,nop,wscale 0> (DF)

12:55:06.172225 virtual-web-site-ip.http > client-computer.52570: S 3836803694:3836803694(0) ack 3417053346 win 1460 <mss 1380,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

12:55:06.172340 client-computer.52570 > virtual-web-site-ip.http: . ack 1 win 5840 <nop,nop,timestamp 272878143 0> (DF)

12:55:06.172702 client-computer.52570 > virtual-web-site-ip.http: F 1:1(0) ack 1 win 5840 <nop,nop,timestamp 272878143 0> (DF)

12:55:06.225677 virtual-web-site-ip.http > client-computer.52570: . ack 2 win 65535 <nop,nop,timestamp 9991266 272878143> (DF)

12:55:06.226166 virtual-web-site-ip.http > client-computer.52570: F 1:1(0) ack 2 win 65535 <nop,nop,timestamp 9991266 272878143> (DF)

12:55:06.226216 client-computer.52570 > virtual-web-site-ip.http: . ack 2 win 5840 <nop,nop,timestamp 272878148 9991266> (DF)

// nc -z virtual-web-site-ip 80

12:55:07.060043 client-computer.52571 > virtual-web-site-ip.http: S 3418784654:3418784654(0) win 5840 <mss 1460,sackOK,timestamp 272878231 0,nop,wscale 0> (DF)

12:55:10.060048 client-computer.52571 > virtual-web-site-ip.http: S 3418784654:3418784654(0) win 5840 <mss 1460,sackOK,timestamp 272878532 0,nop,wscale 0> (DF)

12:55:10.112525 virtual-web-site-ip.http > client-computer.52571: S 1137372680:1137372680(0) ack 3418784655 win 1460 <mss 1380,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

12:55:10.112607 client-computer.52571 > virtual-web-site-ip.http: . ack 1 win 5840 <nop,nop,timestamp 272878537 0> (DF)

12:55:10.112939 client-computer.52571 > virtual-web-site-ip.http: F 1:1(0) ack 1 win 5840 <nop,nop,timestamp 272878537 0> (DF)

12:55:10.167952 virtual-web-site-ip.http > client-computer.52571: . ack 2 win 65535 <nop,nop,timestamp 780420 272878537> (DF)

12:55:10.168686 virtual-web-site-ip.http > client-computer.52571: F 1:1(0) ack 2 win 65535 <nop,nop,timestamp 780420 272878537> (DF)

12:55:10.168754 client-computer.52571 > virtual-web-site-ip.http: . ack 2 win 5840 <nop,nop,timestamp 272878542 780420> (DF)

2 REPLIES
Silver

Re: LocalDirector 430 and synguard behavior

The synguard command provides limited protection against SYN attacks on the virtual IP address. Once the number of unanswered SYNs set with the synguard command is reached, LocalDirector starts to protect the real network and servers from a SYN attack. A syslog message is sent when LocalDirector enters synguard mode. When synguard is on telnet does not work. For a more secure mode of operating Local Director, enable synguard protection.

New Member

Re: LocalDirector 430 and synguard behavior

What is the precise mechanism?

130
Views
0
Helpful
2
Replies
CreatePlease to create content