Re: [mif] Some thoughts

On Nov 10, 2009, at 6:44 PM, William Herrin wrote:

On Tue, Nov 10, 2009 at 12:00 AM, Jan Melen <jan.melen at nomadiclab.com> wrote:
On Nov 10, 2009, at 6:03 AM, William Herrin wrote:
Starting from a post-multipath TCP world...

The situation that jumps to mind is:

3 offices, A B and C.

B connects to A with a T1.
C connects to A with a T1.
B connects to C with a T1. So they're connected in a triangle.

A connects to the Internet with a DSL.
B also connects to the Internet with a WiMax link.

Server located at C called CS. It has an address from the DSL ISP and
an address from the WiMax ISP.

CS(DSL)->CA router->AC Router->DSL Router->Internet
CS(WiMax)->CB router->BC Router->WiMax Router->Internet

But if the CA T1 is down then:
CS(DSL)->CA router->CB Router->BC Router->BA Router->AB Router->DSL
Router->Internet

The CA router can't for the packet that has the source address of the DSL
ISP to the CB router.

It should. If we remove the WiMax connection so there's only one
network domain, we would certainly expect a packet for the Internet at
router CA to find it's way to the DSL router at site A regardless of
whether the T1 from site C to site A was up. Adding the WiMax internet
link at site B should in no way impact CS(DSL)'s ability to reach the
Internet via the DSL line at site A.

Oops sorry my mistake I though you were talking about that the connection to ISP went down but obviously you meant that the T1 connection between C and A dies. In that case, yes, the routing protocol should resolve this situation. As probably the routers A, B, C run some routing protocol (OSPF, BGP, RIP or whatever) that will have to resolve the situation and get the packets routed correctly through although using route that is less preferred than the route normally used due to higher metric value. Of course as we now are talking about multiple default routes that are advertised between the routers A, B, C so we need to add source address prefix in to the default route advertisements. Right? Then the C router should see that router A is advertising (default, prefix:1.2.3.0/24, metric 1) and B is advertising (default, prefix:1.2.3.0/24, metric 2). This information doesn't necessarily need to go all the way to client. If it does, e.g. there are two physically different routers that CS may use to reach networks A and B, then we need that CS listens to these advertisements and makes up his mind and if it is the CS that has to select the correct next hop router then DHCP is not the protocol you want to use to configure routes as it is designed to deliver more or less static routes that do not change (at least) during the address lease time.

That's among the reasons I think its important to consider the router
case in addition to the host case.

Now if you go back and think of host CS the same way as the routers,
CS has the following routes:
1.2.3.35/32+1.2.3.32/28->eth0
1.2.3.35/32+0.0.0.0/0->Router CA metric 2
1.2.3.35/32+0.0.0.0/0->Router CB metric 3
4.5.6.35/32+4.5.6.32/28->eth0
4.5.6.35/32+0.0.0.0/0->Router CB metric 2
4.5.6.35/32+0.0.0.0/0->Router CA metric 3
7.8.9.35/32+7.8.9.32/28->eth0
7.8.9.35/32+0.0.0.0/0->Cable Modem metric 1
127.0.0.0/8+127.0.0.0/8->loopback

If any of the default routes fail in such configuration it should be the
routing protocol that stops advertising default route through that interface
at that point in which case it would result that default route through that
interface deprecates in few minutes and the traffic will be routed through
another router. Existing connections will break if there is no translation
in place in the network see the earlier comments about source address
filtering.

Yes. That's the desired behavior: if the internet link is unavailable
for a given source address then depending on the nature of the failure
packets to the Internet from that source address either vanish into
the ether or return a destination unreachable. It's then up to higher
level protocols (like Multipath TCP) to detect and deal with the path
failure, shifting the failed source address out of use.

On the other hand, just because the Internet link was lost doesn't
mean the administrative domain goes away. In the scenario I painted,
the IP addresses from the failed Internet link are still valid for
communication within three sites; they just aren't workable for a
default route any more.

Yep, the addresses are valid for internal traffic but the default route is not any more valid.

DHCP has very poor or non-existing mechanisms to inform the clients about
changes in the network routing information as the protocol is designed to be
pull instead of push where as all routing protocols are much more
appropriate for this type of operation.

A good point to make in the problem statement if it isn't already there.

Regards,

Jan