Which entry of the routing table was selected? - TCP-IP

This is a discussion on Which entry of the routing table was selected? - TCP-IP ; Walter Roberson wrote: > If a packet came in from a 10.1.1 source IP destined for > 138.139, then which interface would it have come in on? It depends on whether the PC is set up as a router, and ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 49

Thread: Which entry of the routing table was selected?

  1. Re: Which entry of the routing table was selected?

    Walter Roberson wrote:

    > If a packet came in from a 10.1.1 source IP destined for
    > 138.139, then which interface would it have come in on?


    It depends on whether the PC is set up as a router, and hosts on
    10.1.1.0 know that it's a router, or whether the PC is just operating
    as a dual-homed host.

    In the former case, the packet from the 10.1.1.0 subnet to the
    138.139.92.167 would go via the 10.1.1.125 interface of the PC. In the
    latter case, the packet has to find that external router, and the hosts
    on 10.1.1.0 would know about that other router. (The one with
    138.139.1.1 address on the 138.139.0.0 subnet.)

    > In Windows 2000 and XP (and possibly a few others), if the the gateway
    > for an interface is in a different subnet, then an ARP for the gateway
    > is sent to the "all stations" broadcast IP (255.255.255.255), which
    > then answers directly [which it can do by reading the MAC off of the
    > ARP packet], and you get conversations flowing at layer 2 even
    > though the layer 3 is funky. This process is not invalid, but
    > it is unusual.


    I don't think ARP has anything to do with what the situation is here,
    but just for interest:

    ARP doesn't use IP addresses for delivering ARP frames. ARP is not an
    IP protocol at all. ARP requests are always sent to a MAC all 1s
    broadcast destination address. What happens is that inside the ARP
    frame are the source and destination IP addresses. Hopefully, in cases
    where the same wire supports multiple IP subnets (i.e. not the case in
    this thread), an ARP reply is only sent when the requestor is in the
    same IP subnet as the responder.

    Even if one link layer supports multiple IP subnets, a packet going
    between two different IP subnets on that wire have to go through the
    router. So ARP is not involved, other than to find the hardware address
    of the router.

    Bert


  2. Re: Which entry of the routing table was selected?


    "Walter Roberson" wrote in message news:IOJ7g.139587$WI1.19193@pd7tw2no...
    > In article <1147094052.871711.220640@u72g2000cwu.googlegroups. com>, Alex Vinokur wrote:

    [snip]
    > >We consider only applications that have to call bind() to specify the
    > >source address of an outgoing connection.

    >
    > My response still holds. The potential alternative routing processes
    > I mention in my aside have nothing to do with whether bind() was
    > used or not. I don't know of any Windows software to do the
    > alternative routings, but it might exist. (It is fairly common in Linux,
    > as it is integrated into one of the common pieces of firewall software.)
    >
    >
    > > Part 2. Tests

    >
    > Somehow I'm not surprised that homework or assignments or cert study
    > is behind these questions.


    No homework/assignments/cert study is behind these questions.

    >
    > In future, if your questions come from an outside source, then
    > indicate what the source is,

    The source is me.
    > and tell us *your* reasoning about
    > the answer. People here are willing to -assist- others in their
    > learning processes, but are not willing to do their work for them.


    I came across incomprehensible (to me) traffic of UDP messages relatively the routing table.

    --
    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn






  3. Re: Which entry of the routing table was selected?

    "Alex Vinokur" wrote in message news:1147094052.871711.220640@u72g2000cwu.googlegr oups.com...
    >
    > Walter Roberson wrote:
    > [snip]
    > > No, we told you already that the source IP is not considered in
    > > normal routing decisions. [In many systems, it is possible to replace
    > > the normal routing process with one which routes based on "policies"
    > > that might examine e.g. the source IP address, or destination port,
    > > or even the content.]

    >
    >
    > We consider only applications that have to call bind() to specify the
    > source address of an outgoing connection.

    [snip]

    The text with the example can be downloaded as separate file at
    http://groups.google.com/group/sourc...110fe7d284e617 (file routing-table.txt).


    --
    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn





  4. Re: Which entry of the routing table was selected?


    Albert Manfredi wrote:
    > q_q_anonymous@yahoo.co.uk wrote:
    >
    > > Looking at what I think is your reason for saying first entry.
    > > in order to have that source ip, (you think?) it had to have gone
    > > through the first entry, the default route.. But why! there's a more
    > > specific route. I'm not sure if that was your reason. But I kind of
    > > run into that hole , and I can't fill it.

    >
    > Yes, that was my thinking. Since one of the the source addresses was in
    > fact the 138.139.92.167 address, the message was forced to use that
    > interface.
    >
    > I had suspected that this machine had two NICs, one on the 138.139.0.0
    > subnet and one on the 10.1.1.0 subnet (and I think that was confimed
    > now). And there is an external router between these two subnets as
    > well. So if a packet were forced to use the 138.139.92.167 interface
    > and was addressed to something in the 10.1.1.0 network, that packet
    > would then use the external router to find its destination.
    >
    > I'm not saying this would be the normal default way of sending messages
    > from the PC to the 10.1.1.1 destination. I'm just saying that is how
    > they appear to have been sent. There's nothing impossible about forcing
    > packets out one of two NICs in a dual-homed host, even if that's not
    > the most efficient route.
    >
    > Bert


    I guess windows does that(forcing or choosing between 2 equally
    efficient routes) using the Metric. If so, (if it can choose between
    unequally efficient routes nad force to the less effiicient) then, even
    in this case, it looks ilke the metric is the same for efficieint and
    the inefficent rotue . So effiicient route should be chosen.

    Besides using the metric to force (which I only guess at). Maybe it's
    poss for a prog to send a packet bypassing the router aspect of the
    computer. But then it doesn't get 'routed'. Or it does, but not using a
    routing table and nto using that one. Though anyhow, I dont thin'
    that's the case here.

    is there a hole in my view of reasoning the second entry? (that the
    source ip represents the ip of the comp, not the interface of the
    router that the packet goes out of).


  5. Re: Which entry of the routing table was selected?

    wrote:

    > is there a hole in my view of reasoning the second entry? (that the
    > source ip represents the ip of the comp, not the interface of the
    > router that the packet goes out of).


    I could be wrong about this, but as far as I know, if a host transmits
    an IP datagram out of a given interface, the IP Source Address is the
    address of that interface. Not some other interface the host may also
    have.

    In this example, the PC *may* be operating as a router, in which case
    the situation is a little murkier. If the host is set up as a router,
    but is only transmitting IP datagrams it generates internally, why would
    it ever use the IP source address of the "wrong" interface? I don't
    think this should ever happen. When routers transfer routing protocol
    messages among themselves, for example, don't they always use the source
    IP of the port the datagram originates from?

    Bert


  6. Re: Which entry of the routing table was selected?

    In article , "Albert Manfredi" writes:
    > wrote:
    >
    >> is there a hole in my view of reasoning the second entry? (that the
    >> source ip represents the ip of the comp, not the interface of the
    >> router that the packet goes out of).

    >
    > I could be wrong about this, but as far as I know, if a host transmits
    > an IP datagram out of a given interface, the IP Source Address is the
    > address of that interface. Not some other interface the host may also
    > have.
    >
    > In this example, the PC *may* be operating as a router, in which case
    > the situation is a little murkier. If the host is set up as a router,
    > but is only transmitting IP datagrams it generates internally, why would
    > it ever use the IP source address of the "wrong" interface?


    Consider a multi-homed PC configured to operate as a DNS server.

    In the typical case, DNS uses UDP port 53.

    The server PC has interface 1.1.1.1 and 2.2.2.2.

    A client, at 7.7.7.7 sends a DNS query to 1.1.1.1. The DNS server
    software does its thing and generates a reply packet addressed to
    7.7.7.7.

    If the DNS software does not specify the source IP address for the
    response packet, the TCP stack will fill in the source IP address
    by default. If the packet is routed out the 1.1.1.1 interface,
    the source address will be 1.1.1.1 and all is well.

    If the packet is routed out the 2.2.2.2 interface the source
    address on the response will be 2.2.2.2 and the client will
    ignore it. The client is expecting a response from 1.1.1.1 after all.

    In order to avoid this problem, DNS software takes pains to
    generate reply packets with the source address that the client
    addressed the original query to.

    This may well be the "wrong" interface in your sense.

  7. Re: Which entry of the routing table was selected?


    Albert Manfredi wrote:
    > wrote:
    >
    > > is there a hole in my view of reasoning the second entry? (that the
    > > source ip represents the ip of the comp, not the interface of the
    > > router that the packet goes out of).

    >
    > I could be wrong about this, but as far as I know, if a host transmits
    > an IP datagram out of a given interface, the IP Source Address is the
    > address of that interface. Not some other interface the host may also
    > have.
    >
    > In this example, the PC *may* be operating as a router, in which case
    > the situation is a little murkier. If the host is set up as a router,
    > but is only transmitting IP datagrams it generates internally, why would
    > it ever use the IP source address of the "wrong" interface? I don't
    > think this should ever happen. When routers transfer routing protocol
    > messages among themselves, for example, don't they always use the source
    > IP of the port the datagram originates from?
    >
    > Bert


    I haven't really studied routing protocols , (though they only
    populate/fill routing tables).
    But I think if a router generaets a packet, (not forwarding), then it
    probably would use the ip of the interface it sends the packet out of.
    (though I guess it needn't, there's no reason not to). But in this
    case, the router isn't generating the packet, the comp generates it and
    the router forwards it.

    I think rotuers don't know or care what port the ip datagram originates
    from - unless they originated it. They don't ever change the source IP
    of the packet they receive. They don't even look at it. As far as the
    router is concerned, it's not generated internally, it's received from
    a computer.. It's not generated by the router. If it were generated by
    the router then the origianl ip would prob be the interface it's sent
    out from. But in this case, the packet is generated by the computer.
    (if it were generated by a router, I guess the question would say so)
    So, the software in the computer chose one of the comp's IPs. For a
    good reason or no reason. heh, maybe the software didn't even notice
    the comp had 2 NICS . Or maybe the software just didn't care.Any of the
    comp's IPs will do Infact, a good reason for not caring, is if it'll
    still be routed the same anyway (so same efficiency) - which if it is
    second entry, then it is.

    I imagine a sort of logical connection between comp and router. using
    logical interfaces. In whose IPs match those on those shared NICs.
    Either one logical interface with - imagine 2 ips - or. 2 logcial
    interfaces with those ips. Key is, it orgiinates with the comp and
    get sent to the router. The router treats it just as any other comp
    physically connected to the router. Maybe somebody that knows behind
    the scenes can fill in here?


    I think I once made a worse thought , I think it was mistake. The key
    is The routing table is for INCOMING messages. When that router
    receives and so routes a packet, it had to be an incomign message.
    If the router were generating its own packet, then maybe it'd be an
    outgoing message and not routed at all. Perhaps that's the case with
    routing protocol messages.


  8. Re: Which entry of the routing table was selected?

    In article ,
    Albert Manfredi wrote:

    >I could be wrong about this, but as far as I know, if a host transmits
    >an IP datagram out of a given interface, the IP Source Address is the
    >address of that interface. Not some other interface the host may also
    >have.


    That is wrong unless you think of a multi-homed host as a multi-part
    system. If you consider a multi-homed system (even if only multi-homed
    by interface "aliases") as several separate virtual hosts, one for each
    interface, plus an additional virtual or imaginary router, then your
    model fits. An application running on a virtual host sends packets
    only from its virtual interface, but the virtual router routes or
    forwards those packets out any of the real interfaces.

    That model has some oddities that would need patching. The imaginary
    router does not decrement the IP TTL as it would if it were a real
    router. Many applications must be modeled as distributed, because the
    same application state that affects packets emitted from one
    virtual/internal interface can affect packets emitted from another
    interface.


    Vernon Schryver vjs@rhyolite.com

  9. Re: Which entry of the routing table was selected?

    wrote:

    > Consider a multi-homed PC configured to operate as a DNS server.
    >
    > In the typical case, DNS uses UDP port 53.
    >
    > The server PC has interface 1.1.1.1 and 2.2.2.2.
    >
    > A client, at 7.7.7.7 sends a DNS query to 1.1.1.1. The DNS server
    > software does its thing and generates a reply packet addressed to
    > 7.7.7.7.
    >
    > If the DNS software does not specify the source IP address for the
    > response packet, the TCP stack will fill in the source IP address
    > by default. If the packet is routed out the 1.1.1.1 interface,
    > the source address will be 1.1.1.1 and all is well.
    >
    > If the packet is routed out the 2.2.2.2 interface the source
    > address on the response will be 2.2.2.2 and the client will
    > ignore it. The client is expecting a response from 1.1.1.1 after all.
    >
    > In order to avoid this problem, DNS software takes pains to
    > generate reply packets with the source address that the client
    > addressed the original query to.
    >
    > This may well be the "wrong" interface in your sense.


    Interesting example. If the server is DNS, the message transfers are
    UDP, and I suppose that works fine. If the server were something that
    needed TCP, the result wouldn't be quite so good. But, good point. It
    happens.

    In this case, then, it would have been possible for the packet with
    source IP 138.139.92.176 to be coming out the 1.1.1.125 interface port
    of the PC, and use the routing table entry everyone else seemed to
    prefer.

    Bert


  10. Re: Which entry of the routing table was selected?

    In article ,
    Albert Manfredi wrote:

    >> In order to avoid this problem, DNS software takes pains to
    >> generate reply packets with the source address that the client
    >> addressed the original query to.
    >>
    >> This may well be the "wrong" interface in your sense.

    >
    >Interesting example. If the server is DNS, the message transfers are
    >UDP, and I suppose that works fine. If the server were something that
    >needed TCP, the result wouldn't be quite so good.


    On the contrary, TCP to a multi-homed host is an even better example
    precisely because a TCP server can never change to the "right" IP source
    address. Regardless of the interface on which a TCP SYN arrives and
    regardless of the source address of the SYN-ACK, the SYN-ACK will be
    sent via the interface that routing says is best. That is true even
    if it is the "wrong" interface.


    Vernon Schryver vjs@rhyolite.com

  11. Re: Which entry of the routing table was selected?

    Vernon Schryver wrote:

    > On the contrary, TCP to a multi-homed host is an even better example
    > precisely because a TCP server can never change to the "right" IP source
    > address. Regardless of the interface on which a TCP SYN arrives and
    > regardless of the source address of the SYN-ACK, the SYN-ACK will be
    > sent via the interface that routing says is best. That is true even
    > if it is the "wrong" interface.


    But how are the two directions expected to remain symmetric? If in one
    direction the packets are addressed correctly, but in the return
    direction they are expected to go along a bogus route, how does that
    work? Are the routers expected to maintain this special return path
    state for the duration of the session? And if so, and one router along
    the way fails, aren't you guaranteeing the session will fail?

    If I remember right, in the DNS example, the response from the server
    went out on a different interface, not the same as the one on which the
    query arrived. I can see that working for a unidirectional protocol,
    because the only problem there is a make-believe source IP in packets
    along the return path. There's no necessary tight couplling between the
    two directions. So the only possibilities I can see are that the
    routers maintain state for this session, to make both directions go
    along the same path, or that asymmetric paths are okay for TCP. (I know
    asymmetric TCP can work, but I thought it was only done in sort of
    weird situations.)

    Bert


  12. Re: Which entry of the routing table was selected?

    In article <1147222546.016554.37400@j73g2000cwa.googlegroups.c om>,
    "Albert Manfredi" wrote:

    > Vernon Schryver wrote:
    >
    > > On the contrary, TCP to a multi-homed host is an even better example
    > > precisely because a TCP server can never change to the "right" IP source
    > > address. Regardless of the interface on which a TCP SYN arrives and
    > > regardless of the source address of the SYN-ACK, the SYN-ACK will be
    > > sent via the interface that routing says is best. That is true even
    > > if it is the "wrong" interface.

    >
    > But how are the two directions expected to remain symmetric? If in one
    > direction the packets are addressed correctly, but in the return
    > direction they are expected to go along a bogus route, how does that
    > work? Are the routers expected to maintain this special return path
    > state for the duration of the session? And if so, and one router along
    > the way fails, aren't you guaranteeing the session will fail?


    The two directions don't have to be symmetric.

    Except under special circumstances, routing is simply by destination
    address. There's nothing "bogus" about the return route being different
    from the forward route.

    Consider the following diagram, where A and B are the addresses of the
    server's two interfaces. Client sends a request to A, so it will take
    the path through routers R1 and R2. The server may send the reply back
    via R3, since that's the shorter path. So it will go out interface B,
    but the source address will still be A.

    Client
    |
    ---------------------
    | |
    R1 R3
    | |
    R2 |
    | |
    | |
    ------ ------
    | |
    |-----Server---|
    A B

    The only time this may cause a problem is if R3 implements "reverse path
    verification", a form of anti-spoofing that blocks traffic if it doesn't
    arrive on the interface that would be used to send traffic back to the
    source address. This type of filtering is generally only valid on
    connections to singly-homed leaf nodes or subnets. When multi-homing is
    involved, you can't use such simplistic filtering because asymmetric
    routing is normal.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  13. Re: Which entry of the routing table was selected?

    In article <1147222546.016554.37400@j73g2000cwa.googlegroups.c om>,
    Albert Manfredi wrote:

    >> On the contrary, TCP to a multi-homed host is an even better example


    >But how are the two directions expected to remain symmetric? If in one
    >direction the packets are addressed correctly, but in the return
    >direction they are expected to go along a bogus route, how does that
    >work?


    What's that about a bogus route? I don't understand the other person's
    situation. I'm only responding to what I thought was your claim that
    the source address in an IP packet must always match the IP address
    of the host interface from which it is sent.

    > Are the routers expected to maintain this special return path
    >state for the duration of the session?


    Who said anything about special paths? What paths are not special?

    > And if so, and one router along
    >the way fails, aren't you guaranteeing the session will fail?


    Well, if the route breaks and there is no replacement, then yes,
    the TCCP session will fail.


    >If I remember right, in the DNS example, the response from the server
    >went out on a different interface, not the same as the one on which the
    >query arrived.


    I don't recall that as being critical in the DNS example, but it
    can happen.

    > I can see that working for a unidirectional protocol,
    >because the only problem there is a make-believe source IP in packets
    >along the return path. There's no necessary tight couplling between the
    >two directions. So the only possibilities I can see are that the
    >routers maintain state for this session, to make both directions go
    >along the same path, or that asymmetric paths are okay for TCP. (I know
    >asymmetric TCP can work, but I thought it was only done in sort of
    >weird situations.)


    Such situations are not at all wierd for multi-homed hosts. They can
    be seen as the reason to pay for multi-homing.

    Asymmetric paths are okay for TCP, because TCP doesn't know about them.

    I trust you'd have no problem with packets going out the "wrong" interface
    of a router if the "right" interface is broken and the "wrong" interface
    is the start of a usable path to the destination.
    So what's wrong with combining a router with a host in a single box?


    Vernon Schryver vjs@rhyolite.com

  14. Re: Which entry of the routing table was selected?

    Barry Margolin wrote:

    > The two directions don't have to be symmetric.
    >
    > Except under special circumstances, routing is simply by destination
    > address. There's nothing "bogus" about the return route being different
    > from the forward route.
    >
    > Consider the following diagram, where A and B are the addresses of the
    > server's two interfaces. Client sends a request to A, so it will take
    > the path through routers R1 and R2. The server may send the reply back
    > via R3, since that's the shorter path. So it will go out interface B,
    > but the source address will still be A.
    >
    > Client
    > |
    > ---------------------
    > | |
    > R1 R3
    > | |
    > R2 |
    > | |
    > | |
    > ------ ------
    > | |
    > |-----Server---|
    > A B


    Yes, I understood that if asymmetric paths are acceptable, then clearly
    the source IP of the packet doesn't need to point to the true source
    port used by the machine.

    > The only time this may cause a problem is if R3 implements "reverse path
    > verification", a form of anti-spoofing that blocks traffic if it doesn't
    > arrive on the interface that would be used to send traffic back to the
    > source address. This type of filtering is generally only valid on
    > connections to singly-homed leaf nodes or subnets. When multi-homing is
    > involved, you can't use such simplistic filtering because asymmetric
    > routing is normal.


    Dual-homing is often used for improved reliability. There are of course
    different strategies one can use. If one uses TCP instead of UDP, one
    strategy might be to keep two parallel sessions open at all times. The
    reason to do this is to prevent a single failure from breaking the
    logical link.

    If asymmetric paths are allowed to occur, this strategy would not work.
    There would be no way to guarantee that the two simultaneous sessions
    are taking different paths. A single failure would potentially break
    both links. I'm not sure how to achieve "active redundancy" with TCP,
    unless one can guarantee that dual-homed hosts use the proper source
    address one each of their interfaces.

    Bert


  15. Re: Which entry of the routing table was selected?

    Vernon Schryver wrote:

    > I trust you'd have no problem with packets going out the "wrong" interface
    > of a router if the "right" interface is broken and the "wrong" interface
    > is the start of a usable path to the destination.
    > So what's wrong with combining a router with a host in a single box?


    Routers don't change the source IP of packets from a host, so that's
    not a problem. However, to make the correct analogy, I'd have big
    problems with routers using unpredictable interfaces. If I set up a
    network to operate in a predictable way as failures occur, I need to
    know that routers select the "correct" routes in each case.

    Bert


  16. Re: Which entry of the routing table was selected?

    In article <1147278806.621567.155080@j33g2000cwa.googlegroups. com>,
    Albert Manfredi wrote:
    >
    >> I trust you'd have no problem with packets going out the "wrong" interface
    >> of a router if the "right" interface is broken and the "wrong" interface
    >> is the start of a usable path to the destination.
    >> So what's wrong with combining a router with a host in a single box?

    >
    >Routers don't change the source IP of packets from a host, so that's
    >not a problem.


    No source IP addresses are being "changed." The host is merely picking
    one IP addresses and using an interface other than a very naive and
    wrong model of the host might predict.

    (Let's not worry about NAT routers that do change the source IP address
    of packets from a host.)


    > However, to make the correct analogy, I'd have big
    >problems with routers using unpredictable interfaces. If I set up a
    >network to operate in a predictable way as failures occur, I need to
    >know that routers select the "correct" routes in each case.


    That is exactly what is happening in the multi-homed host case. The
    host picks the source IP address for its IP datagram. It then picks
    an outgoing network interface or wire for the datagram using exactly
    the same algorithms as a router. Some multi-homed hosts will even use
    the same routing protocols to inform those algorithems.


    Vernon Schryver vjs@rhyolite.com

  17. Re: Which entry of the routing table was selected?

    In article <1147278124.754476.199300@u72g2000cwu.googlegroups. com>,
    Albert Manfredi wrote:


    >Dual-homing is often used for improved reliability. There are of course
    >different strategies one can use. If one uses TCP instead of UDP, one
    >strategy might be to keep two parallel sessions open at all times. The
    >reason to do this is to prevent a single failure from breaking the
    >logical link.
    >
    >If asymmetric paths are allowed to occur, this strategy would not work.
    >There would be no way to guarantee that the two simultaneous sessions
    >are taking different paths. A single failure would potentially break
    >both links. I'm not sure how to achieve "active redundancy" with TCP,
    >unless one can guarantee that dual-homed hosts use the proper source
    >address one each of their interfaces.


    None of that is consistent with how multi-homed IP hosts work or could
    possibly work. It seems to be based on the mistaken assumption that
    IP is a virtual circuit protocol like ATM. IP is about packet switching
    instead of circuit switching. Perhaps the fundamental difference is
    that in circuit switching the ends of the circuit have some control
    and a pretty good idea of the paths their data follow, but in packet
    switching, the hosts just toss their data out and just hope the next
    hop will pass it along in approximately the right direction. That is
    why the IP packet header includes a TTL field but the ATM cell header
    doesn't.


    Vernon Schryver vjs@rhyolite.com

  18. Re: Which entry of the routing table was selected?

    > >If asymmetric paths are allowed to occur, this strategy would not work.
    > >There would be no way to guarantee that the two simultaneous sessions
    > >are taking different paths. A single failure would potentially break
    > >both links. I'm not sure how to achieve "active redundancy" with TCP,
    > >unless one can guarantee that dual-homed hosts use the proper source
    > >address one each of their interfaces.


    Vernon Schryver wrote:
    >
    > None of that is consistent with how multi-homed IP hosts work or could
    > possibly work. It seems to be based on the mistaken assumption that
    > IP is a virtual circuit protocol like ATM. IP is about packet switching
    > instead of circuit switching. Perhaps the fundamental difference is
    > that in circuit switching the ends of the circuit have some control
    > and a pretty good idea of the paths their data follow, but in packet
    > switching, the hosts just toss their data out and just hope the next
    > hop will pass it along in approximately the right direction. That is
    > why the IP packet header includes a TTL field but the ATM cell header
    > doesn't.


    This is going rather far afield of the original thread, but I think
    you're being overly pessimistic. The only requirement for this to work,
    with TCP, is that the source IP of packets be the IP address of the
    actual port that transmitted the packet.

    There's plenty of fussing going on as we speak, in IPv6, to figure out
    which of the multiple available IPv6 source addresses should be used in
    specific sessions. It is going to depend in part on where the network
    is at the other end of the session link. And even more interesting, the
    specific case of a multihomed host came up. The problem is, some IPv6
    addresses might not have scope compatible with the other end of the
    link.

    This is related. The relationship between port used and source address
    matters. Sure, circuit-switched techniques make the redundant data path
    comms more clear-cut. But in a controlled network, i.e. not the
    Internet, the path taken by packets in normal conditions should be very
    predictable. I just don't think this is so absurd.

    Bert


  19. Re: Which entry of the routing table was selected?

    On Wed, 10 May 2006 09:22:04 -0700, Albert Manfredi wrote:

    > Yes, I understood that if asymmetric paths are acceptable, then clearly
    > the source IP of the packet doesn't need to point to the true source
    > port used by the machine.


    I think you mean s/port/interface/. In that case, stop thinking of an
    interface having an IP adress. That is a big step, but one that will help
    you keep your sanity. Think of a machine having the IP address, it is much
    more accurate[0].

    The coupling between an IP address an an interface is used only in a few
    specific instances.
    - When a locally generated packet doesn't have a source address, the
    address of the outgoing interface is used[1].
    - When responding to an arp request[2].
    - To add the correct route to the routing table[3].

    Other than that, don't think of an interface as "having" an address. The
    machine has addresses and the routing tables route the packet through a
    specific interface.

    M4

    [0] Except in the so called "strong ended IP model". In that model all I
    say is wrong. However I have never seen an IP stack implement that model,
    so better forget this footnote.

    [1] Strictly speaking, this is not correct. What if an interface has
    multiple IP adresses? Which one should be choosen? The first? There are
    situations where that is wrong. In Linux, the source address is determined
    by the routing table to avoid this problem[4].

    [2] But nothing stops an IP stack to respond on all interfaces to arp
    requests for all IPs of that machine. In fact, this is not uncommon. So
    even there the coupling is not so strict[4].

    [3] And again, this is not exactly an interface property, but a side
    effect of setting up the interface[4].

    [4] And even this is not completely correct, but hey, let's not make it
    even more complex!

    --
    Redundancy is a great way to introduce more single points of failure.


  20. Re: Which entry of the routing table was selected?

    In comp.protocols.tcp-ip Martijn Lievaart wrote:
    > Think of a machine having the IP address, it is much more
    > accurate[0].


    > [0] Except in the so called "strong ended IP model". In that model
    > all I say is wrong. However I have never seen an IP stack implement
    > that model, so better forget this footnote.


    Depending on which stacks you've seen you may have seen it and not
    noticed it

    HP-UX 11 and later offers the Strong End System Model via an ndd
    setting. The default is the "weak" end system model. Later versions
    have a "firm" end-system model. Firm end-system in HP-UX means that
    source IP is part of the route selection, but the restriction on
    datagrams arriving on interfaces with matching IP(s) is relaxed to be
    like the "weak" end system model.

    I suspect that Solaris 2 and later also offers the strong end-system
    model with the weak as the default. I've no idea if it does something
    akin to a "firm" one.

    rick jones
    --
    a wide gulf separates "what if" from "if only"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast