[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [mif] Some thoughts



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.

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.


> 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,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.