Find the answer to your Linux question:
Results 1 to 2 of 2
Hi all, I've posted about this problem on the SuSe distro list a few days ago, but I get no answer. Does somebody knows what is the problem and has ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2007
    Posts
    6

    ipvs working bad on OpenSuSE 10.2


    Hi all,

    I've posted about this problem on the SuSe distro list a few days ago, but I get no answer. Does somebody knows what is the problem and has fixed it?

    Thanks

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

    I'm trying to make balanced web connections with ipvs implemented on OpenSuSE 10.2.

    After I've made all configurations the redirection is working, the client paquets can reach the real web servers (W2K3Ent) and the answers are sent by the servers back to the Linux, but the packets are not routed to the external network and are all lost. So, what's wrong?

    Thanks and Best Regards

    jruz

    PS. info attached below

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

    The interfaces on the Linux Director are configured as follow:

    linux-fw:/var/log # ifconfig -a
    eth0 Link encap:Ethernet HWaddr 00:0C:29:82:841
    inet addr:10.10.10.254 Bcast:10.10.10.255 Mask:255.255.255.0
    inet6 addr: fe80::20c:29ff:fe82:84d1/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:98107 errors:0 dropped:0 overruns:0 frame:0
    TX packets:901 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:9375163 (8.9 Mb) TX bytes:326042 (318.4 Kb)
    Interrupt:177 Base address:0x1400

    eth1 Link encap:Ethernet HWaddr 00:0C:29:82:84B
    inet addr:10.10.20.254 Bcast:10.10.20.255 Mask:255.255.255.0
    inet6 addr: fe80::20c:29ff:fe82:84db/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:965 errors:0 dropped:0 overruns:0 frame:0
    TX packets:147 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:145049 (141.6 Kb) TX bytes:11452 (11.1 Kb)
    Interrupt:185 Base address:0x1480

    eth1:0 Link encap:Ethernet HWaddr 00:0C:29:82:84B
    inet addr:10.10.20.1 Bcast:10.10.20.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    Interrupt:185 Base address:0x1480

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:152 errors:0 dropped:0 overruns:0 frame:0
    TX packets:152 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:14136 (13.8 Kb) TX bytes:14136 (13.8 Kb)

    sit0 Link encap:IPv6-in-IPv4
    NOARP MTU:1480 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

    The routing table is:

    linux-fw:~ # netstat -r
    Kernel IP routing table
    Destination Gateway Genmask Flags MSS Window irtt Iface
    10.10.20.1 * 255.255.255.255 UH 0 0 0 eth1
    10.10.20.0 * 255.255.255.0 U 0 0 0 eth1
    10.10.10.0 * 255.255.255.0 U 0 0 0 eth0
    link-local * 255.255.0.0 U 0 0 0 eth0
    loopback * 255.0.0.0 U 0 0 0 lo
    default 10.10.10.250 0.0.0.0 UG 0 0 0 eth0

    Several outputs of the ipvsadm -l command when I try to open a web page:

    linux-fw:~/scripts # ipvsadm -l
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port Forward Weight ActiveConn InActConn
    TCP 10.10.20.1:http rr
    -> 10.10.20.11:http Route 1 0 0
    -> 10.10.20.10:http Route 1 0 0
    TCP 10.10.20.1:8098 rr
    -> 10.10.20.11:8098 Route 1 0 0
    -> 10.10.20.10:8098 Route 1 0 0
    TCP 10.10.20.1:8099 rr
    -> 10.10.20.11:8099 Route 1 0 0
    -> 10.10.20.10:8099 Route 1 0 0
    linux-fw:~/scripts # ipvsadm -l
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port Forward Weight ActiveConn InActConn
    TCP 10.10.20.1:http rr
    -> 10.10.20.11:http Route 1 0 0
    -> 10.10.20.10:http Route 1 0 0
    TCP 10.10.20.1:8098 rr
    -> 10.10.20.11:8098 Route 1 0 0
    -> 10.10.20.10:8098 Route 1 0 0
    TCP 10.10.20.1:8099 rr
    -> 10.10.20.11:8099 Route 1 0 0
    -> 10.10.20.10:8099 Route 1 0 0
    linux-fw:~/scripts # ipvsadm -l
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port Forward Weight ActiveConn InActConn
    TCP 10.10.20.1:http rr
    -> 10.10.20.11:http Route 1 0 1
    -> 10.10.20.10:http Route 1 0 0
    TCP 10.10.20.1:8098 rr
    -> 10.10.20.11:8098 Route 1 0 0
    -> 10.10.20.10:8098 Route 1 0 0
    TCP 10.10.20.1:8099 rr
    -> 10.10.20.11:8099 Route 1 0 0
    -> 10.10.20.10:8099 Route 1 0 0
    linux-fw:~/scripts # ipvsadm -l
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port Forward Weight ActiveConn InActConn
    TCP 10.10.20.1:http rr
    -> 10.10.20.11:http Route 1 0 1
    -> 10.10.20.10:http Route 1 0 0
    TCP 10.10.20.1:8098 rr
    -> 10.10.20.11:8098 Route 1 0 0
    -> 10.10.20.10:8098 Route 1 0 0
    TCP 10.10.20.1:8099 rr
    -> 10.10.20.11:8099 Route 1 0 0
    -> 10.10.20.10:8099 Route 1 0 0
    linux-fw:~/scripts # ipvsadm -l
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port Forward Weight ActiveConn InActConn
    TCP 10.10.20.1:http rr
    -> 10.10.20.11:http Route 1 0 0
    -> 10.10.20.10:http Route 1 0 0
    TCP 10.10.20.1:8098 rr
    -> 10.10.20.11:8098 Route 1 0 1
    -> 10.10.20.10:8098 Route 1 0 1
    TCP 10.10.20.1:8099 rr
    -> 10.10.20.11:8099 Route 1 0 0
    -> 10.10.20.10:8099 Route 1 0 0


    As I said before, the packets can reach the real servers on the LAN connected to the eth1 interface and the answer paquets from the servers can reach the eth1 interface, but when I make a tcpdump over the eth0 I only see query paquets from the browser's client.

    There are the outputs of tcpdump on both interfaces:

    linux-fw:~ # tcpdump -i eth0 host 10.10.20.1
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
    16:37:53.081073 IP 10.10.10.50.rtc-pm-port > 10.10.20.1.http: S 2164270962:2164270962(0) win 65535 <mss 1460,nop,nop,sackOK>
    16:37:55.875213 IP 10.10.10.50.rtc-pm-port > 10.10.20.1.http: S 2164270962:2164270962(0) win 65535 <mss 1460,nop,nop,sackOK>
    16:38:01.916679 IP 10.10.10.50.rtc-pm-port > 10.10.20.1.http: S 2164270962:2164270962(0) win 65535 <mss 1460,nop,nop,sackOK>
    16:38:13.918354 IP 10.10.10.50.omnilink-port > 10.10.20.1.http: S 482489625:482489625(0) win 65535 <mss 1460,nop,nop,sackOK>

    4 packets captured
    9 packets received by filter
    0 packets dropped by kernel

    linux-fw:~ # tcpdump -i eth1 host 10.10.20.1
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
    16:37:53.079167 IP 10.10.10.50.rtc-pm-port > 10.10.20.1.http: S 2164270962:2164270962(0) win 65535 <mss 1460,nop,nop,sackOK>
    16:37:53.080158 IP 10.10.20.1.http > 10.10.10.50.rtc-pm-port: S 1853741642:1853741642(0) ack 2164270963 win 16384 <mss 1460,nop,nop,sackOK>
    16:37:55.875355 IP 10.10.10.50.rtc-pm-port > 10.10.20.1.http: S 2164270962:2164270962(0) win 65535 <mss 1460,nop,nop,sackOK>
    16:37:55.897313 IP 10.10.20.1.http > 10.10.10.50.rtc-pm-port: S 1853741642:1853741642(0) ack 2164270963 win 16384 <mss 1460,nop,nop,sackOK>
    16:38:01.916879 IP 10.10.10.50.rtc-pm-port > 10.10.20.1.http: S 2164270962:2164270962(0) win 65535 <mss 1460,nop,nop,sackOK>
    16:38:02.486411 IP 10.10.20.1.http > 10.10.10.50.rtc-pm-port: S 1853741642:1853741642(0) ack 2164270963 win 16384 <mss 1460,nop,nop,sackOK>
    16:38:13.918561 IP 10.10.10.50.omnilink-port > 10.10.20.1.http: S 482489625:482489625(0) win 65535 <mss 1460,nop,nop,sackOK>
    16:38:13.922831 IP 10.10.20.1.http > 10.10.10.50.omnilink-port: S 1530845933:1530845933(0) ack 482489626 win 16384 <mss 1460,nop,nop,sackOK>
    16:38:16.792644 IP 10.10.20.1.http > 10.10.10.50.omnilink-port: S 1530845933:1530845933(0) ack 482489626 win 16384 <mss 1460,nop,nop,sackOK>
    16:38:23.381968 IP 10.10.20.1.http > 10.10.10.50.omnilink-port: S 1530845933:1530845933(0) ack 482489626 win 16384 <mss 1460,nop,nop,sackOK>

    10 packets captured
    20 packets received by filter
    0 packets dropped by kernel

  2. #2
    Just Joined!
    Join Date
    Sep 2007
    Posts
    6

    Smile Fixed

    Hello,

    Yesterday, while reading documentation about LVS I've found the bug on my configuration. To do balanced connections with DR in a LVS that acts as the gateway of the real servers, the LVS must not have the VIP configured and the realservers must modify the response paquets.

    Fortunately, I can use NAT instead of DR so my colleagues agree.

    jruz

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •