Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: Routing problem in SLES 11 SP1

  1. #11

    Re: Routing problem in SLES 11 SP1

    ramesh tn wrote:

    > I am now working on automatically detecting dead
    > gateways and for that I need to be able to ping the real web through
    > any/all my interfaces and detect which is down.


    Would something like this work for you?

    If you have four ISP's, that should be four distinct networks. Choose a
    device on each network, perhaps the first router (which could change)
    or the ISP's DNS server. Set up a route via the appropriate interface
    in your server's routing table to each of the selected devices and ping
    the specific device. The default route should not affect the more
    specific route you have defined.

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are using the web interface,
    show your appreciation and click on the star below...

  2. Re: Routing problem in SLES 11 SP1

    Quote Originally Posted by ramesh_tn View Post
    Jens, the nating happens on my linux box and on the dsl-routers. The firewall is also setup and uses nothing more than standard suse options. Your third question-- I do not understand.
    My third comment was focusing on what's going on... when you have a successful "ping", that's because you send an "ICMP echo request" and the target system answers with an "ICMP echo response". When you notice failing pings, then it might not be that the echo request is being sent incorrectly but that the response is not reaching you.

    For instance, you might send the request via one interface, but due to some NAT rule "problem" with a sender IP address of a different (i.e. the default route) interface. The ping target system then would send the reply to that IP address, and the reply would enter your system via that other interface. As that response packet might not be matched to the sent packet (so to speak), the "ping" command would report this as a lost packet.

    You might be able to track this down via "tcpdump", checking on the wire what packet gets sent and if there are stray ICMP echo responses coming in via i.e. one of the other interfaces.

    Regards,
    Jens

  3. #13

    Re: Routing problem in SLES 11 SP1

    Quote Originally Posted by jmozdzen View Post
    My third comment was focusing on what's going on... when you have a successful "ping", that's because you send an "ICMP echo request" and the target system answers with an "ICMP echo response". When you notice failing pings, then it might not be that the echo request is being sent incorrectly but that the response is not reaching you.

    For instance, you might send the request via one interface, but due to some NAT rule "problem" with a sender IP address of a different (i.e. the default route) interface. The ping target system then would send the reply to that IP address, and the reply would enter your system via that other interface. As that response packet might not be matched to the sent packet (so to speak), the "ping" command would report this as a lost packet.

    You might be able to track this down via "tcpdump", checking on the wire what packet gets sent and if there are stray ICMP echo responses coming in via i.e. one of the other interfaces.

    Regards,
    Jens
    You have tell me how to "tcpdump".

    BUT: If the problem is per your thoughts, why does "ping" work when the default route is set. Like I said before, when the multi-path default route is set through all interfaces, everything works fine. All my pings through each of the interfaces brings a response.

    FURTHER: Based on some googling, I also set the rp_filter from the default "1" to "0". System is currently set to use "0". Still no help.

  4. Re: Routing problem in SLES 11 SP1

    > You have tell me how to "tcpdump".

    Normally I'd respond to that with "if you don't know how to use tcpdump, then you'd have even more trouble reading the results." - it's a tool to dump network packets as seen on the interface. Are you familiar with network traffic, then "man tcpdump" should give you a good start. If you're not familiar with the in-depths of network packets, then tcpdump most probably isn't your tool of choice.

    > BUT: If the problem is per your thoughts, why does "ping" work when the default route is set. Like I said before, when the multi-path default route is set through all interfaces, everything works fine. All my pings through each of the interfaces brings a response.

    Sorry, can't tell you. I typically judge such situations by looking at what's actually going on at the wire level after the system has tried to do all its "packet voodoo". There's a lot of complexity build into the IP stack nowadays and configuration can get confusing really fast - I like to avoid spending too much time barking up the wrong tree. Only after I know what wrong result was created, I try to find out where and who the culprit is.

    Regards,
    Jens

  5. #15

    Re: Routing problem in SLES 11 SP1

    ramesh tn wrote:

    > why does "ping" work when the
    > default route is set. Like I said before, when the multi-path default
    > route is set through all interfaces, everything works fine. All my
    > pings through each of the interfaces brings a response.


    1. Your VLANs all use private IP's

    2. <assumed> you have separate public networks for each ISP.

    3. Packets leaving from a specific VLAN/ISP will be assigned the public
    IP address associated with that particular ISP.

    4. Responses to your pings will be routed back through the ISP from
    which they were sent.

    So, while you may not know from which interface the ping originated,
    you should always see an echo reply because the response is returned to
    the originating interface.

    The problem as you described it is that you can't determine which
    interface will be used unless you change the default route. If you do
    what I suggested in my last post and set a specific route to a specific
    device on each ISP's network, you could then determine if a specific
    interface were down.

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are using the web interface,
    show your appreciation and click on the star below...

  6. #16

    Re: Routing problem in SLES 11 SP1

    ramesh tn wrote:

    > FURTHER: Based on some googling, I also set the rp_filter from the
    > default "1" to "0". System is currently set to use "0". Still no help.


    Perhaps you have already seen this, but I thought I would pass it along.

    TID 7007649
    Applying SLES 11 SP 1 Causing Communication Issues
    http://www.novell.com/support/viewCo...7649&sliceId=1

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are using the web interface,
    show your appreciation and click on the star below...

  7. #17

    Re: Routing problem in SLES 11 SP1

    Thx Kevin...this fixed my issue.

  8. #18

    Re: Routing problem in SLES 11 SP1

    Quote Originally Posted by ramesh_tn View Post
    My problem, if you remove all the vlan, load balancing etc, is very simple.
    I am unable to ping anything through vlan4, if the default route is not through vlan 4. The minute i change default route to use vlan4 things start working. If I change default route to use vlan5, that starts working, but vlan4 stops. This happens for all the interfaces. In fact, things work on all interfaces when the muti-path default route is set to use all 4 interfaces.
    Hi,

    I don't know if you have solved this yet, but setting
    "net.ipv4.conf.all.rp_filter = 0" in /etc/sysctl.conf solved it for me.

  9. #19

    Re: Routing problem in SLES 11 SP1

    Quote Originally Posted by tgm_its View Post
    Hi,

    I don't know if you have solved this yet, but setting
    "net.ipv4.conf.all.rp_filter = 0" in /etc/sysctl.conf solved it for me.
    I also had an issue that turned out to be ICMP redirects. In addition to rp_filter setting above, I set the following to disallow redirects, which is the recommended setting if you're not using your linux server as a router:

    Code:
    # /etc/sysctl.conf
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.all.secure_redirects = 0
    net.ipv4.conf.all.send_redirects = 0
    net.ipv4.conf.default.accept_redirects = 0
    net.ipv4.conf.default.secure_redirects = 0
    net.ipv4.conf.default.send_redirects = 0
    FYI, redirect messages were sent from my router whenever a leg of our MPLS went down. I could see the redirect stored in cache on my host 172.20.64.25. This was a redirect for a route between two specific hosts: 172.20.64.25 to 172.20.17.18.

    Code:
    $ ip route list cache match 172.20.17.18
    172.20.17.18 via 172.20.64.11 dev eth1  src 172.20.64.25
        cache <redirected>  ipid 0x3f1a rtt 15ms rttvar 11ms ssthresh 61 cwnd 61
    Doing ip route flush cache did not fix the issue due to some kind of bug. The cache apparently clears itself after 10 minutes, but only if you're not attempting any communication between the two specific hosts.

    I had to reboot to clear the cache. I'm hoping the sysctl settings above will work - haven't had any network issues to be able to test it, and haven't tried any artificial tests.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Bookmarks

Posting Permissions

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