Professional Web Applications Themes

Complicated Routing problem - Linux / Unix Administration

Short form of the question: If I can ping/traceroute C from B, and B from A, then shouldn't it logically follow that I must be able to ping/traceroute C from A? I can't! Long form: --- here's a fairly large preamble to all of this, so please bear with me. We are a wireless ISP, providing Broadband to people in rural areas further away from their nearest exchange than the 3.5km allowed by wired DSL. One large chunk of our network was bought wholesale from another ISP as they were about to go bust. It consists of a network of ...

  1. #1

    Default Complicated Routing problem

    Short form of the question:

    If I can ping/traceroute C from B, and B from A, then shouldn't it
    logically follow that I must be able to ping/traceroute C from A? I
    can't!

    Long form:
    ---
    here's a fairly large preamble to all of this, so please bear with me.

    We are a wireless ISP, providing Broadband to people in rural areas
    further away from their nearest exchange than the 3.5km allowed by wired
    DSL.

    One large chunk of our network was bought wholesale from another ISP as
    they were about to go bust. It consists of a network of cut-down Red Hat
    boxes acting as routers (the OS is stored on a Flash card on the
    motherboard. The cutting down of Linux was fairly drastic, so many
    useful diagnostic tools are missin - for example there's no ssh.

    The whole network is hidden behind a NAT at the entry box of the
    network. Each village has its own "Head Box" and there is a cipe pipe to
    it. Subscribers have their own boxes which associate with the head box.

    We wish to extend our network by adding one of our own router boxes - we
    run the Commercial Star-OS Operating system on our boxes. These are
    administered using ssh.

    We have connected the new box to an existing head boox using an ethernet
    crossover cable, assigning the box an external IP address, and adding
    routing statements to allow the box to be accessed by ssh. This works
    very efficiantly.

    This time we're trying to add a box to a client box, not a head box. The
    connection is like this:

    ========================
    | Network Gateway |
    ========================
    | |
    Cipe Tunnel
    | |
    ========================
    | Head Box |
    ========================
    | |
    IPSec
    | |
    ========================
    | Customer Box |
    ========================
    | |
    Ethernet
    | |
    ========================
    | StarOs Box |
    ========================
    (Most of this came with the old network, so we're stuck with it).

    I have assigned the static address of the two ethernet ports to be
    212.24.92.249 and 212.24.92.250 (The StarOS box is 250).
    I've added routing commands to the Gateway to route
    212.24.92.248/30 to the Head Box over cipe, and on the head box to route
    it to the Customer box.

    Complicated, but should work, right?

    It doesn't. If I log onto the Head box, I can ping 212.24.92.250, ans
    traceroute gose straight to it; If i go back one step backwards I can't
    ping and if I try and traceroute it routes as far as the headbox and
    then returns "* * *" until it reaches 30 jumps.

    Oh, and one other thing? The Customer box is getting perfect delivery of
    Internet. You can connect a PC to it and surf the net perfectly.

    What's going wrong? I've tried routing over the unencrypted IP
    connections over which the tunnels are built, and the same thing happens.

    Most sincere thanks for any hints or pointers as to what to look at.
    I've posted below the routing tables of the Head Box; with the way
    they've implemented IPSec it makes fairly gruesome reading, so only look
    if you've a strong stomach.

    Thanks in Advance, Andy Holyer

    -------------- Cut Here --------------------------------
    # route
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    10.0.7.12 10.0.7.20 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.24 10.0.7.20 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.10 10.0.7.15 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.21 10.0.7.15 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.6 10.0.7.4 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.7 10.0.7.13 255.255.255.255 UGH 0 0 0
    wlan0
    192.168.105.7 * 255.255.255.255 UH 0 0 0
    cipcb0
    10.0.7.17 10.0.7.15 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.2 10.0.7.15 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.18 10.0.7.20 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.3 10.0.7.15 255.255.255.255 UGH 0 0 0
    wlan0
    10.0.7.19 10.0.7.20 255.255.255.255 UGH 0 0 0
    wlan0
    212.24.92.236 10.0.7.13 255.255.255.252 UG 0 0 0
    ipsec0
    212.24.92.248 10.0.7.15 255.255.255.252 UG 0 0 0
    wlan0
    212.24.92.240 10.0.7.14 255.255.255.252 UG 0 0 0
    ipsec0
    212.24.92.244 10.0.7.9 255.255.255.252 UG 0 0 0
    ipsec0
    212.24.92.220 * 255.255.255.252 U 0 0 0
    eth1
    212.24.92.248 10.0.7.15 255.255.255.248 UG 0 0 0
    wlan0
    10.8.6.0 10.0.7.6 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.22.0 10.0.7.22 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.7.0 10.0.7.7 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.23.0 10.0.7.23 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.4.0 10.0.7.4 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.20.0 10.0.7.20 255.255.255.0 UG 0 0 0
    ipsec0
    192.168.21.0 10.0.7.15 255.255.255.0 UG 0 0 0
    wlan0
    10.8.5.0 10.0.7.5 255.255.255.0 UG 0 0 0
    ipsec0
    10.0.7.0 * 255.255.255.0 U 0 0 0
    wlan0
    10.0.7.0 * 255.255.255.0 U 0 0 0
    ipsec0
    192.168.20.0 10.0.7.15 255.255.255.0 UG 0 0 0
    wlan0
    10.8.21.0 10.0.7.21 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.2.0 10.0.7.2 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.18.0 10.0.7.18 255.255.255.0 UG 0 0 0
    ipsec0
    192.168.19.0 * 255.255.255.0 U 0 0 0
    eth1
    192.168.2.0 192.168.11.1 255.255.255.0 UG 0 0 0
    wlan1
    10.8.3.0 10.0.7.3 255.255.255.0 UG 0 0 0
    ipsec0
    192.168.18.0 * 255.255.255.0 U 0 0 0
    eth0
    10.8.19.0 10.0.7.19 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.16.0 10.0.7.16 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.17.0 10.0.7.17 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.14.0 10.0.7.14 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.15.0 10.0.7.15 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.12.0 10.0.7.12 255.255.255.0 UG 0 0 0
    ipsec0
    192.168.12.0 10.0.7.15 255.255.255.0 UG 0 0 0
    wlan0
    10.8.13.0 10.0.7.13 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.10.0 10.0.7.10 255.255.255.0 UG 0 0 0
    ipsec0
    192.168.11.0 * 255.255.255.0 U 0 0 0
    wlan1
    10.8.11.0 10.0.7.11 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.8.0 10.0.7.8 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.24.0 10.0.7.24 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.9.0 10.0.7.9 255.255.255.0 UG 0 0 0
    ipsec0
    10.8.25.0 10.0.7.25 255.255.255.0 UG 0 0 0
    ipsec0
    default 192.168.105.7 0.0.0.0 UG 0 0 0
    cipcb0
    #

    --
    Andy Holyer, Systems Administrator
    Hedgehog Broadband Ltd, 11 Marlborough Place, Brighton UK BN1 1UB
    [url]http://www.hhbb.co.uk/[/url]
    Andy Holyer Guest

  2. #2

    Default Re: Complicated Routing problem

    On Thu, 02 Sep 2004 13:13:11 +0100, Andy Holyer <andyhhhbb.co.uk> wrote:
    > Short form of the question:
    >
    > If I can ping/traceroute C from B, and B from A, then shouldn't it
    > logically follow that I must be able to ping/traceroute C from A? I
    > can't!
    Sounds like B isn't routing, or isn't routing properly.
    > We are a wireless ISP, providing Broadband to people in rural areas
    > further away from their nearest exchange than the 3.5km allowed by wired
    > DSL.
    I'm doing something similar; neighbor with a T1, several of us using
    802.11b to bounce signal around to get connectivity.
    > The cutting down of Linux was fairly drastic, so many
    > useful diagnostic tools are missin - for example there's no ssh.
    Ouch. But telnet is on? Ouch.
    > It doesn't. If I log onto the Head box, I can ping 212.24.92.250, ans
    > traceroute gose straight to it; If i go back one step backwards I can't
    > ping and if I try and traceroute it routes as far as the headbox and
    > then returns "* * *" until it reaches 30 jumps.
    >
    > Oh, and one other thing? The Customer box is getting perfect delivery of
    > Internet. You can connect a PC to it and surf the net perfectly.
    So you _are_ routing then. Is ICMP turned off, so you're just seeing
    what looks like a problem and actually isn't?

    Dave Hinz
    Dave Hinz Guest

  3. #3

    Default Re: Complicated Routing problem

    In article <andyh-51A396.13131102092004mercury.nildram.net>, Andy Holyer wrote:
    >Short form of the question:
    >
    >If I can ping/traceroute C from B, and B from A, then shouldn't it
    >logically follow that I must be able to ping/traceroute C from A?
    No. Does C know to use B to reach A? Does A know to use B to reach C?
    >One large chunk of our network was bought wholesale from another ISP as
    >they were about to go bust. It consists of a network of cut-down Red Hat
    >boxes acting as routers (the OS is stored on a Flash card on the
    >motherboard. The cutting down of Linux was fairly drastic, so many
    >useful diagnostic tools are missin - for example there's no ssh.
    None the less, that sounds like a good point to be looking at. Does
    the RH box have 'tcpdump'? If not, grab a laptop and a hub and some
    Ethernet cables, and hook that into the Ethernet connection that
    plugs into the headbox. What do you see?
    >I've posted below the routing tables of the Head Box; with the way
    >they've implemented IPSec it makes fairly gruesome reading, so only look
    >if you've a strong stomach.
    And without knowing what is what and where, it also causes my eyes to
    water. Look at the routing tables on all hosts involved. Do they know
    how to pass packets for destination A and C? Do A and C know how to
    reach each other. This may mean using explicit routes, rather than
    relying on defaults.

    Old guy
    Moe Trin Guest

  4. #4

    Default Re: Complicated Routing problem

    In article <slrncjfj3b.sa9.ibuprofinatlantis.phx.az.us>,
    [email]ibuprofinpainkiller.example.tld[/email] (Moe Trin) wrote:
    > In article <andyh-51A396.13131102092004mercury.nildram.net>, Andy Holyer
    > wrote:
    > >Short form of the question:
    > >
    > >If I can ping/traceroute C from B, and B from A, then shouldn't it
    > >logically follow that I must be able to ping/traceroute C from A?
    >
    > No. Does C know to use B to reach A? Does A know to use B to reach C?
    >
    Yes, and Yes.
    > >One large chunk of our network was bought wholesale from another ISP as
    > >they were about to go bust. It consists of a network of cut-down Red Hat
    > >boxes acting as routers (the OS is stored on a Flash card on the
    > >motherboard. The cutting down of Linux was fairly drastic, so many
    > >useful diagnostic tools are missin - for example there's no ssh.
    >
    > None the less, that sounds like a good point to be looking at. Does
    > the RH box have 'tcpdump'? If not, grab a laptop and a hub and some
    > Ethernet cables, and hook that into the Ethernet connection that
    > plugs into the headbox. What do you see?
    >
    No tcpdump. Could you expand on what you were saying about using a
    laptop? Just to make things really tricky, the headbox is mounted to the
    top of a gable about 15 meteres above the ground.
    > >I've posted below the routing tables of the Head Box; with the way
    > >they've implemented IPSec it makes fairly gruesome reading, so only look
    > >if you've a strong stomach.
    >
    > And without knowing what is what and where, it also causes my eyes to
    > water. Look at the routing tables on all hosts involved. Do they know
    > how to pass packets for destination A and C? Do A and C know how to
    > reach each other. This may mean using explicit routes, rather than
    > relying on defaults.
    As far as I can see, all is fine. That's what makes it all so
    frustrating.

    --
    Andy Holyer, Systems Administrator
    Hedgehog Broadband Ltd, 11 Marlborough Place, Brighton UK BN1 1UB
    [url]http://www.hhbb.co.uk/[/url]
    Andy Holyer Guest

  5. #5

    Default Re: Complicated Routing problem

    In article <2posbmFmhccvU2uni-berlin.de>,
    Dave Hinz <DaveHinzspamcop.net> wrote:
    > On Thu, 02 Sep 2004 13:13:11 +0100, Andy Holyer <andyhhhbb.co.uk> wrote:
    >
    > > The cutting down of Linux was fairly drastic, so many
    > > useful diagnostic tools are missin - for example there's no ssh.
    >
    > Ouch. But telnet is on? Ouch.
    >
    My thoughts entirely. I lost a FreeBSD Box to some script kiddies using
    a telnetd exploit and it was only the fact that they did it on the night
    of 10 September 2001 that saved my hid - the customer had something else
    to worry about the next morning, if you get my drift.

    Haven't touched telnet since then.

    --
    Andy Holyer, Systems Administrator
    Hedgehog Broadband Ltd, 11 Marlborough Place, Brighton UK BN1 1UB
    [url]http://www.hhbb.co.uk/[/url]
    Andy Holyer Guest

  6. #6

    Default Re: Complicated Routing problem

    Mail-Copies-To: poster

    Sorry - can't do that anymore.

    In article <andyh-624C45.10051503092004mercury.nildram.net>, Andy Holyer wrote:
    >In article <slrncjfj3b.sa9.ibuprofinatlantis.phx.az.us>,
    > [email]ibuprofinpainkiller.example.tld[/email] (Moe Trin) wrote:
    >> No. Does C know to use B to reach A? Does A know to use B to reach C?
    >>
    >Yes, and Yes.
    Hate to tell you how often that one is the problem. "I can talk fine to box
    X". Of course box X is turning about in circles trying to figue out where
    the heck this unknown host is, so that it can reply, or go after the
    tormentor with a broadsword. The other problem is where some router has
    an entry that sends the packets to the Falkland Islands or South Georgia,
    and the penguin running the router down there had to put in a firewall rule
    to stop being bothered by this stuff.
    >No tcpdump. Could you expand on what you were saying about using a
    >laptop?
    Laptop, network sniffer - just about anything that lets you see the
    packets that are passing by. It's called 'divide and conquer". Can you
    see packets from A going to C? What about C going to A. Are ther also
    some ICMP Type 3 (or 5) packets trying to scream "NNNnnnoooooooo!!!"
    >Just to make things really tricky, the headbox is mounted to the
    >top of a gable about 15 meteres above the ground.
    Oh, joy!!! Well, I suppose it keeps the local children from stealing
    the hardware. ;-)
    >As far as I can see, all is fine. That's what makes it all so
    >frustrating.
    Pushing a bit - could there be a firewall someplace that's dropping
    stuff? Another idea - traceroute from A to C and vice versa, or
    is there someone dropping ICMP packets? If so, if you know the IP
    addresses of the intermediate hosts, you could even try telnetting
    to them. You're not looking to get in, just seeing if the connection
    gets refused or rejected (which means you got there, but the server
    doesn't want to speak to you).

    Old guy
    Moe Trin Guest

  7. #7

    Default Re: Complicated Routing problem

    In article <slrncjhvu5.267.ibuprofinatlantis.phx.az.us>,
    [email]ibuprofinpainkiller.example.tld[/email] (Moe Trin) wrote:
    > Pushing a bit - could there be a firewall someplace that's dropping
    > stuff? Another idea - traceroute from A to C and vice versa, or
    > is there someone dropping ICMP packets? If so, if you know the IP
    > addresses of the intermediate hosts, you could even try telnetting
    > to them. You're not looking to get in, just seeing if the connection
    > gets refused or rejected (which means you got there, but the server
    > doesn't want to speak to you).
    There's something subtly wrong with the setup of the secure tunnels,
    both IPSEC and CIPE, in that they don't return pings from a traceroute -
    you just get *.*.* from that box.

    I can traceroute from A to B over the unencrypted hops ant then it goes
    wrong when we get there. Here's to output:

    (On B):
    # traceroute 192.168.12.2
    traceroute to 192.168.12.2 (192.168.12.2), 30 hops max, 40 byte packets
    1 192.168.12.2 (192.168.12.2) 8.883 ms 7.729 ms 5.14 ms
    #

    Not surprising, as 192.168.12.1/24 is one of B's WLAN IP addresses

    Now from A:

    # traceroute 192.168.12.2
    traceroute to 192.168.12.2 (192.168.12.2), 30 hops max, 40 byte packets
    1 192.168.2.2 (192.168.2.2) 4.146 ms 3.358 ms 4.157 ms
    2 192.168.4.2 (192.168.4.2) 4.359 ms 5.624 ms 4.611 ms
    3 192.168.6.2 (192.168.6.2) 7.86 ms 8.081 ms 7.792 ms
    4 192.168.9.2 (192.168.9.2) 13.121 ms 8.946 ms 7.934 ms
    5 192.168.11.2 (192.168.11.2) 11.699 ms 11.248 ms 11.121 ms
    6 * * *
    7 * * *
    ....and so it continues until traceroute runs out of road.

    My suspicion is that for some reason it's trying to use one of its IPSEC
    tunnels, but in that case, why does it work when telnetted in? It's
    suypicous that B's default route is back over the cipe tunnel to A, but
    that's true of all the other boxes as well, each of them has a cipe
    tunnel back to the mail access box.

    Curiouser and curiouser

    --
    Andy Holyer, Systems Administrator
    Hedgehog Broadband Ltd, 11 Marlborough Place, Brighton UK BN1 1UB
    [url]http://www.hhbb.co.uk/[/url]
    Andy Holyer Guest

  8. #8

    Default Re: Complicated Routing problem

    In article <andyh-163E13.09333706092004mercury.nildram.net>, Andy Holyer
    wrote:
    >There's something subtly wrong with the setup of the secure tunnels,
    >both IPSEC and CIPE, in that they don't return pings from a traceroute -
    >you just get *.*.* from that box.
    Unix traceroute uses UDP pasckets (by default starting at 33434 and
    incrementing per hop) starting with a TTL of 1, and incrementing that.
    It depends on receiving an ICMP Time Exceeded error (Type 11 code 0)
    from intermediate hops, and a Port Unreachable (Type 3 code 3) when
    it reaches it's destination. (It's the b0rken microsoft 'tracert'
    that uses pings for this, although the Unix version can be made to
    do so with the -I option.) Could your tunnel be blocking or
    dropping the ICMP stuff? As suggested, try telnetting to each box
    and looking at the response (hopefully, a ACK RST packet, rather
    than an ICMP error). Don't forget that telnet accepts a port number
    arguement when connecting.
    ># traceroute 192.168.12.2
    >traceroute to 192.168.12.2 (192.168.12.2), 30 hops max, 40 byte packets
    > 1 192.168.12.2 (192.168.12.2) 8.883 ms 7.729 ms 5.14 ms
    >#
    Well, you got there.
    > 4 192.168.9.2 (192.168.9.2) 13.121 ms 8.946 ms 7.934 ms
    > 5 192.168.11.2 (192.168.11.2) 11.699 ms 11.248 ms 11.121 ms
    > 6 * * *
    > 7 * * *
    >...and so it continues until traceroute runs out of road.
    What are the missing steps between 192.168.11.2 and 192.168.12.2?
    Can you reach those steps by any other means? Can any of them run
    tcpdump to see what packets are passing by?
    >My suspicion is that for some reason it's trying to use one of its IPSEC
    >tunnels, but in that case, why does it work when telnetted in?
    Different protocol? Telnet solely depends on TCP, while traceroute
    must have ICMP, and probably needs UDP in *nix. Take that back,
    telnet _MAY_ need a UDP connection from each end to their name servers,
    but the symptoms would be noticable if that weren't working.
    >Curiouser and curiouser
    Just another happy day in networking land ;-)

    Old guy
    Moe Trin Guest

  9. #9

    Default Re: Complicated Routing problem

    [email]ibuprofinpainkiller.example.tld[/email] (Moe Trin) wrote in message news:
    > ># traceroute 192.168.12.2
    > >traceroute to 192.168.12.2 (192.168.12.2), 30 hops max, 40 byte packets
    > > 1 192.168.12.2 (192.168.12.2) 8.883 ms 7.729 ms 5.14 ms
    > >#
    >
    > Well, you got there.
    >
    > > 4 192.168.9.2 (192.168.9.2) 13.121 ms 8.946 ms 7.934 ms
    > > 5 192.168.11.2 (192.168.11.2) 11.699 ms 11.248 ms 11.121 ms
    > > 6 * * *
    > > 7 * * *
    > >...and so it continues until traceroute runs out of road.
    >
    > What are the missing steps between 192.168.11.2 and 192.168.12.2?
    > Can you reach those steps by any other means? Can any of them run
    > tcpdump to see what packets are passing by?
    >
    There are no missing steps. wlan0 of the box is configured to
    192.168.11.2/24, and wlan1 is 192.168.12.1/24. Here's (part of) the
    ifconfig to prove it:

    wlan0 Link encap:Ethernet HWaddr 00:02:6F:04:54:AC
    inet addr:10.0.7.1 Bcast:10.0.7.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2464996 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2908055 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:643652625 (613.8 MiB) TX bytes:1520352586 (1449.9
    MiB)
    Interrupt:10 Base address:0x100

    wlan0:0 Link encap:Ethernet HWaddr 00:02:6F:04:54:AC
    inet addr:192.168.12.1 Bcast:192.168.12.255
    Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    Interrupt:10 Base address:0x100

    wlan1 Link encap:Ethernet HWaddr 00:02:6F:05:4A:92
    inet addr:192.168.11.2 Bcast:192.168.11.255
    Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2582605 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2172520 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:1745937590 (1665.0 MiB) TX bytes:809435215 (771.9
    MiB)
    Interrupt:10 Base address:0x140
    Andy Holyer Guest

  10. #10

    Default Re: Complicated Routing problem

    In article <google.com>, Andy Holyer
    wrote: 

    OK - this might explain the traceroute outout. Do remember that
    the NIC isn't the thing that is answering - it's the kernel. The NIC
    is merely the "door" you go through to access the kernel. Thus,
    when the trace got to 192.168.11.2, it was at the destination. Now
    I'm not exactly sure why you didn't get the normal 'port unreachable
    response. Technically, when you reached 192.168.11.2, you were at
    the destination computer - just at a different "door". I suppose it
    could have tried to send the packet on from 192.168.11.2 to 192.168.12.2,
    but because those packets are to/from the same host, the packet would
    be routed via the loopback interface. The kernel knows it's addresses,
    and doesn't waste bandwidth on the wire when it's talking to itself.
     

    And the routing table? (Hopefully it's not that huge thing you posted
    at the start of this thread ;-) )
     
     

    Ohhh, this could be something, the wlan0:0. I'm used to seeing that
    nomenclature as an IP alias - and have seen problems where the alias is
    used for _receiving_ packets, but the data transmitted may relate to
    the base address - here, 10.0.7.1.

    Old guy
    Moe Guest

  11. #11

    Default Re: Complicated Routing problem

    example.tld (Moe Trin) wrote in message news:<phx.az.us>... 
    >
    > And the routing table? (Hopefully it's not that huge thing you posted
    > at the start of this thread ;-) )
    >[/ref]
    Yep, I'm afraid it's the big scary thing I quoted earlier. I'll
    summarize what i think the routing was trying to do in a moment.
     

    >
    > Ohhh, this could be something, the wlan0:0. I'm used to seeing that
    > nomenclature as an IP alias - and have seen problems where the alias is
    > used for _receiving_ packets, but the data transmitted may relate to
    > the base address - here, 10.0.7.1.[/ref]

    So.. if I ifconfig'ed the wlan0 interface the other way round - so the
    alias was 10.0.7.1, nor 192.168.12.1, thangs might start working...

    I've been hesitant to do that for a reason, which it's now pertinant
    to explain.

    The box in question is a "head box" - the main router for a village
    (as it happens, Rotherfield in East Sus, UK). There are about 20
    subscribers who all get their signal from this box, and each of these
    is assigned an addess such as 10.8.4.1. These are routed through IPSec
    in a way that I don't really understand, and is routed to 10.0.7.4 in
    the case above. 10.0.7.0/24 is the unencrypted channel.
    Just to complicate matters, some people are supplied by relaying the
    signal via other subscribers. That's real fun when people go on
    holiday and turn all the electrics off, i can tell you :-)

    Why didn't they just use WEP, you ask? I don't know, these boxes came
    with no doenteation, not even any source code, only a compiled MS
    Access application which used to administer them. The company we
    bought the network off connected using telnet - no, worse than that,
    they connect using telnet, *and*you*have*to*sign*in*as*root*.

    <flame off>
    Phew.

    Anyway, the reason I've been chary of touching the routing like this
    is that I stand the risk of disconnecting about 15 subscribers who up
    until now have been blocked in return for connecting up one set of
    people.

    But it might be worth a try.
    Andy Guest

  12. #12

    Default Re: Complicated Routing problem

    In article <google.com>, Andy Holyer
    wrote: 
    >Yep, I'm afraid it's the big scary thing I quoted earlier. I'll
    >summarize what i think the routing was trying to do in a moment.[/ref]

    Oh, crap. Well, it has expired off my feed, so I had to go upstream
    and grab another copy of that post. Editing the table so that each line
    is less than 78 characters, and then starting to play with it, one
    thing caught my eye:

    [compton ~]$ sort < post1.routing | head -3
    10.0.7.0 * 255.255.255.0 U 0 0 0 ipsec0
    10.0.7.0 * 255.255.255.0 U 0 0 0 wlan0
    10.0.7.10 10.0.7.15 255.255.255.255 UGH 0 0 0 wlan0
    [compton ~]$

    You have the same network going to two places. NORMALLY, the last place
    configured wins. The kernel will not send packets to "both" or "either".
    This isn't the only place:

    10.8.4.0 10.0.7.4 255.255.255.0 UG 0 0 0 ipsec0
    10.0.7.6 10.0.7.4 255.255.255.255 UGH 0 0 0 wlan0

    10.8.13.0 10.0.7.13 255.255.255.0 UG 0 0 0 ipsec0
    212.24.92.236 10.0.7.13 255.255.255.252 UG 0 0 0 ipsec0
    10.0.7.7 10.0.7.13 255.255.255.255 UGH 0 0 0 wlan0

    10.8.15.0 10.0.7.15 255.255.255.0 UG 0 0 0 ipsec0
    192.168.12.0 10.0.7.15 255.255.255.0 UG 0 0 0 wlan0

    10.8.20.0 10.0.7.20 255.255.255.0 UG 0 0 0 ipsec0
    10.0.7.12 10.0.7.20 255.255.255.255 UGH 0 0 0 wlan0

    and 10.0.7.4, 10.0.7.13, 10.0.7.15, and 10.0.7.20 are also reachable two
    ways. I don't know about the kernel, but _I'm_ certainly confused.

    Also, you have some routes reachable via two steps:

    10.0.7.0 * 255.255.255.0 U 0 0 0 ipsec0
    10.0.7.0 * 255.255.255.0 U 0 0 0 wlan0
    10.0.7.3 10.0.7.15 255.255.255.255 UGH 0 0 0 wlan0
    10.8.3.0 10.0.7.3 255.255.255.0 UG 0 0 0 ipsec0

    I don't know how the kernel would route packets to 10.8.3.0. See the
    confusion? In routing tables, the more definitive route wins. So this says
    10.8.3.0 is on ipsec0 and you get there via 10.0.7.3, but the route to
    10.0.7.3 is via 10.0.7.15 on the wlan0. "I wonder if I should have taken
    that left turn in Albuquerque." (Bugs Bunny - late 1940s?)
     

    Either that, or they'd break in different ways. ;-)
     

    B2100, about 4 clicks East of Crowborough says Michelin
     

    I can sorta see this. I really don't understand everything either.
     

    Yeah - I'm guessing I can see this in the routing table too.
     

    Is the stuff mainly done with the routing tables and such? _MOST_
    configurations in Linux (or any *nix) are done from text based files,
    so I imagine that it might be possible to trace things out that way.
    I'm not saying it would be easy - just that it can be done.
     

    Probably not quite as bad as it seems - few windoze users have the
    clue to run a sniffer. But then, even as late as 1996, the last
    company I worked at in California was doing that, and using NIS too.
     

    Understood. I think you mentioned this box doesn't have tcpdump
    installed either, which would help a lot.

    This routing table is a beaut! In the previous article, you said:
     

    and
     

    but the routing table tells me

    10.0.7.0 * 255.255.255.0 U 0 0 0 ipsec0
    10.0.7.0 * 255.255.255.0 U 0 0 0 wlan0

    192.168.12.0 10.0.7.15 255.255.255.0 UG 0 0 0 wlan0

    so 10.0.7.1 and 192.168.12.1 are on the same interface, but to get to
    the 192.168.12.0, I have to send packets to 10.0.7.15. Huh? If it
    weren't so early in the afternoon, I'd have to get a pitcher of beer
    (about 3.8 liter) to think that one over. ;-)

    Old guy
    Moe Guest

  13. #13

    Default Re: Complicated Routing problem

    Dnia Wed, 08 Sep 2004 18:31:00 -0500, Moe Trin
    <example.tld> tako rzekł:
    : [compton ~]$ sort < post1.routing | head -3
    : 10.0.7.0 * 255.255.255.0 U 0 0 0 ipsec0
    : 10.0.7.0 * 255.255.255.0 U 0 0 0 wlan0
    : 10.0.7.10 10.0.7.15 255.255.255.255 UGH 0 0 0 wlan0
    : [compton ~]$
    :
    : You have the same network going to two places. NORMALLY, the last place
    : configured wins. The kernel will not send packets to "both" or "either".

    _Usually_, ipsec takes precedence.
    And, again, _usually_, ipsec doesn't really like aliases (this wlan0:0) -
    IPSec is kinda harsh when it comes to IP addresses ;-). The thing (in this
    case) probably is that the "192.168.12.1 machine" answers with a "10.0.7.1"
    address (and IPSec kills that connection, because it's not in SAD/SPD).

    I've had these issues, using FreeBSD and KAME (IPSec implementation).
    On Cisco routers, aliases seemed to work fine.

    : This routing table is a beaut! In the previous article, you said:
    :
    :>wlan0 Link encap:Ethernet HWaddr 00:02:6F:04:54:AC
    :> inet addr:10.0.7.1 Bcast:10.0.7.255 Mask:255.255.255.0
    :
    : and
    :
    :>wlan0:0 Link encap:Ethernet HWaddr 00:02:6F:04:54:AC
    :> inet addr:192.168.12.1 Bcast:192.168.12.255
    :
    : but the routing table tells me
    :
    : 10.0.7.0 * 255.255.255.0 U 0 0 0 ipsec0
    : 10.0.7.0 * 255.255.255.0 U 0 0 0 wlan0
    :
    : 192.168.12.0 10.0.7.15 255.255.255.0 UG 0 0 0 wlan0
    :
    : so 10.0.7.1 and 192.168.12.1 are on the same interface, but to get to
    : the 192.168.12.0, I have to send packets to 10.0.7.15. Huh? If it

    Probably (90% sure) needed for encryption (ipsec0, see?).

    : weren't so early in the afternoon, I'd have to get a pitcher of beer
    : (about 3.8 liter) to think that one over. ;-)

    ;-)

    --
    Konrad
    http://amba.matrix.pl/~kurak/
    'W życiu nie licz± się tylko ciało i muskuły - ważny jest jeszcze fryz.' -
    Johnny Bravo
    Konrad Guest

Similar Threads

  1. Routing with WSE 2.0
    By Pete Wright in forum ASP.NET Web Services
    Replies: 3
    Last Post: February 3rd, 04:00 PM
  2. Help on routing
    By Martin Jeppesen in forum Linux / Unix Administration
    Replies: 0
    Last Post: October 15th, 02:24 AM
  3. MDK 9.1: Is it a routing problem?
    By Michael Badt in forum Linux Setup, Configuration & Administration
    Replies: 0
    Last Post: September 14th, 07:07 PM
  4. routing problem
    By cyborg in forum Windows Networking
    Replies: 5
    Last Post: September 9th, 11:28 PM
  5. Problem with PCI-IRQ routing
    By Pigeon in forum Debian
    Replies: 0
    Last Post: August 4th, 01:30 AM

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
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139