Multihoming - Resilience or Independence

> Your prefixes (let's say /24) has to be announced by two ISPs 
> so the packets
> will come back to you. If ISP A's link failed then that /24 
> with ISP A in
> the
> ASPATH will be withdrawn. And ISP B's /24 will become active. 
> So in the
> global
> routing table there will be TWO /24 with different ASPATH.
> 
> If this /24 is in ISP A's PA space then it saves one but the 
> one from ISP
> B's one 
> NEEDs to be in the global routing table.
Either I didn't understand you right, or you were wrong.

It does not save a route in the DFZ.
Let's say the customer gets A/24 out of proider A's A/17 prefix.
B has to announce A/24 to the internet along with it's current prefixes.
A has to announce A/17 AND A/24 to the internet. If A advertises A/17
only all the traffic for A/24 will go through B (because of the longest
match rule), and I think that's not what that customer wants.

So
Being multihomed to two ASs with NAT or two addreses on each host does
not create an extra route in the DFZ.
Being multihomed to a single AS does not create an extra route in the
DFZ.
Being multihomed to two ASs (It doesn't matter PA or PI, separate AS or
anounced by the two ASs. Prefix out of PA, separate AS is generally
recognised to be the better technical solution.) does create at least 1
extra prefix and 2 extra as-paths in the DFZ.
These are the facts about growth of the DFZ routing table caused by
multihoming as I see them.
There are of course other reasons for the growth like providers
advertising 14 separate /24s when they can agregate it to /20 because
"We were trying to do some input channel load balacing and have left
this anouncements for months because our administrator does not have the
time to deal with this thing, he/she has more important work to do".

Now it's time to think how we can make people prefer the first 2
possibilities over the third. We've had enough of technical discussion I
think.

Regards,
Boyan Krosnov, CCNP
Network Administrator
Lirex Net
phone: +359-2-91815