Subject: RE: [Tsvwg] RE: multihoming issues via SCTP

From: [email-masked]
Date: Thu, 13 Sep 2001 13:54:48 +0300

Hi again!

	(a lot of stuff deleted)

> > > Now another issue with this that people keep forgetting is that
> > > in general the source address of the packet DOES NOT HELP the
> > > IP stack choose the interface the packet will be emitted on.
> > > Yes, you can in some instances turn on source based routing
> > > but this IS STILL A REASEARCH issue and is not generally done.
> > 
> >         Exactly, this is my concern... As you can't select 
> the physical card
> > used, you can't control the path, and so those problems 
> arise... In the most
> > common case you will be sending all your datagrams from a 
> single NIC, unless
> > the destination addresses lead to the use of different 
> gateways, reachable
> > through different NICs (which is what usually happens in 
> the bake-offs)...
> 
> 
> This is a routing table configuration issue. Just like in the 
> bake-offs
> if you want to use the redundancy you must make sure your routing
> tables are configured... If you just put in a default it will
> go at that one address...

	So I guess that I wasn't wrong... It is nice to discover that I'm
not that silly :-)

	The point is that the routing tables only specify one NIC. So, I
guess that in SS7 there won't be such a problem, since everything will be
set beforehand, but in Internet, if you are a server and you don't know who
can connect to you, your routing tables will choose the default route for
99.99% of the datagrams you send, since they will be directed somewhere
outside your own network. If this happens so often, then multihomming will
be reduced to the last hop (or almost).

	If both peers have two addresses, two NICs in different networks,
and I'm the sender, all my packets will follow the same default path at
least during its first hops. They all will use only one of my NICs (in the
normal case), and I won't ever use the other one to send anything. Of
course, my packets will be directed to either one or the other IP of the
receiver, and at least the last hop will be different, but I would bet that
in most cases all the previous path followed will be the same... but this is
completely normal, as if the NICs are physically close, the path must be
mostly the same...

	The receiver will in turn do the same, just sending SACKs using only
one of their NICs...

	The final result is that even if you are multihomed, if any of the
"main" NICs is broken, the whole association will be down... In any case, I
don't think there is any easy solution to this... The routing procedure
should be changed... If you have two NICs, then you should have two default
paths, each of them using as its interface one of the NICs... There should
have to be some way in which you look at the routing tables, and if you see
there are several options (since you have several default paths used to
reach the same group of addresses), then you should take a look to the
source address to choose one or the other NIC... But I guess this is already
invented, called source routing, and under study as Randall said... :-)

	BR Iván Arias Rodríguez

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Thu, 13 Sep 2001 08:38:53 -0500

>         So I guess that I wasn't wrong... It is nice to discover that I'm

Ivan, my silly comment was directed to thinking you could not
set/control the IP source address of out-going packets. I think
you were talking about MAC address... which is a different thing....very
confusing...

>         The point is that the routing tables only specify one NIC. So, I

No, some routing tables can have two default routes... again it
becomes an implementation issue... I think linux is this way.. it
seems to me my linux box has had several occasions where it had
two different def-routes.. not sure if both of them were used :/

But I am thinking systems like this COULD build a special routing
request that SCTP could use... that way YOU WOULD use all of the
NIC's

> be reduced to the last hop (or almost).

Of course.. unless as I said above you design the SCTP routing lookups
to be able to select from more than one default..  This would only
work when you had two ISP's anyway... most folks probably in the 90%
range do NOT have two ISP's. So even having this option only would
help 10% of the folks... and I bet for the 10% of folks it helps
a LOT of them will have setup routing tables (even using the Interent)
to give them path divergacny... maybe doing something in BSD is
not worth it...

> completely normal, as if the NICs are physically close, the path must be

Of course.. if you only have one IP provider this cannot help but
be true. If you have multiple... it may not be true depending on
how you setup routing... For example.

Lets say Company A and Company B exchange information a lot
over the Internet. Now Company A and B both get two differnt ISP's.
They both get two small subnets from there ISP's... so we have
four subnets. Now I in Company A (in the IT dept) can point my routing
tables
through to the two seperate subnets so that they use the two
differnt providers... This of course does NOT mean that the paths
somewhere do not overlap... it depends... if both companies got
the same "large" two IP providers that had there own networks then
it may be that NONE of the paths overlap. It can be done.

In the worst case you have some redundancy for a single NIC
failure. This in itself is a good thing. 

I really think that if you are willing to go to the extra expense
of getting two ISP's and you WANT redundancy the scenario above is
much more likely... after all who gets two ISP's except for someone
that is willing to go the extra steps for some critical data they
wish to pass.. maybe even between two seperate parts of the
same company.. 

> invented, called source routing, and under study as Randall said... :-)
No, I don't think source address routing is the thing here. Instead with
two defaults with some minor kernel additions one can make the routing
tables give a default route per destination. This then would make
it so when I sent to Dest IP-A we use Default-1 and when I send to
Dest IP-A' I would send to Default-2.

I will be investagating getting this to work in BSD land... not sure
it is possilbe but I will see..

R
-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 13 Sep 2001 13:00:25 -0700 (PDT)

> completely normal, as if the NICs are physically close, the path must be

I know very little about routing.  But I think the above is not strictly
true.  Suppose 2 addresses belong to 2 different ISPs, packets sent to
them probably will not be routed the same...  It may be true that the
first few hops will be the same as the hops are within an organization and
most organizations do not have redundant paths internally.  But once
outside the organization, the paths to the 2 different IP addresses will
probably not be the same.  Only when the packets enter the peer's network,
they may follow similar path.  Please correct me if I am wrong.

As pointed out by various other people, there is really no reason why a
host cannot use more than one interface to send out packets.  Suppose
a host has 2 interfaces and they are in different networks.  There is
really no reason why the host OS should restrict the use of both of
them for sending packets.  Are you suggesting that only one of the 2
interfaces has a router on its link?  If not, I'd say the OS is
broken if SCTP cannot use both of them to send out packets.  This at
least provides a local interface level reducdancy in sending.  This
means that even if the peer has only 1 interface, SCTP can at least
provide the local interface reducdancy.  As a matter of fact, I think
this was mentioned in a previous thread which suggested that SCTP can
only provide this kind of reducdancy.  So please don't take it away (-:

It seems to me that you are talking about an environment (maybe host
OS or whatever system the SCTP stack is implemented) which needs to
be enhanced.

							K. Poon.
							[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Sep 2001 23:00:04 +0200 (CEST)

> 	Hi again!

Hi!

> 	The point is that the routing tables only specify one NIC.

Actually, that doesn't have to be the case. The routing table just point a
default route at one default gateway. (I'm not sure how having multiple
default routes works on hosts.)

But this could be over multiple interfaces if you use link aggregation,
such as Cisco's fast etherchannel or IEEE 802.3ad. However, in this case
you would use one address for both interfaces...

The problem that always remains is how to detect failures, so you can stop
routing packets over a broken link. Obviously, the system should detect a
"no carrier" condition. But in most cases there are switches in the path
and if the switch or a link "behind" the switch fails the host won't
notice. Listening to RIP broadcasts or Router Advertisements will help in
these situations, but the timeouts associated with this are very long.

Shame we don't use FDDI any more. There you could attach a host to both
rings so the likelihood of fatal problems was much smaller than with
ethernet.

> paths, each of them using as its interface one of the NICs...

I'm afraid the concept of having two different routes to a single
destination (that destination could be the default route) and having the
transport protocol choose which packets use which route, is not compatible
with current implementations of IP.

We keep focussing on the last hop here, but this is not typically the
part of the path where most failures occur, at least on the Internet.

Iljitsch van Beijnum