Chesapeake Computer Consultants

Multihoming: Problems and Solutions From the Customer Point of View

Howard Berkowitz

Table of Contents

• Slides from this Talk
• Stan Barber's Notes
• February 1998 NANOG Home Page

Stan Barber's Notes

This talk is the result of a ID that was submitted and discussed at the December IETF. There it was decided that it was not suitable for a standards track RFC, but it is something that should written down.

Noone has a consistent definition of multi-homing.

There is some stuff available. There are some RFCs available. The RFCs assume that the multi-homing using routing.

The multi-homing problem falls into one of four catagories.

1. I have servers on the Internet and I want the customer to go to the least busy server. This is not really a routing problem. What the user wants is availability and response time. The user also may want a service level guarantee. When you try to educate them, they want to talk to the folks in charge of the Internet. Education is the best solution. What's the difference between a used car salesman and a Tier-1 Internet Service Provider salesman? The used car salesman knows he is lying. The solution is probably going to be done by using DNS or something like that.
2. I want to have a highly reliable Internet connection. This is a traditional type of use of the Internet. It is a routing problem. This might be something that requires BGP. It does not have to require BGP. Often, in staying with the same ISP, they can require that ISP to engineer it for diversity by connecting to different pops over geographically diverse paths.
3. I and my partners want to hook up using a VPN like technology. This is probably not a routing problem (except at the level of creating the VPN tunnels). There are security issues and there are coodination issues.
4. I want to replace my Enterprise WAN with VPN. This is probably not a routing problem. There are security issues and the Internet does not generally perform as well as a private-line based networks.

In doing planning & budgeting, there is a trade-off between MBTF and the cost of protecting against a particular incident.

The customers need to understand the difference among the various technical tradeoff.

Solution Family 1: Application/Transport/Name Multihoming

• Multiple Server addresses in DNS
• Application caching
• DNS-route linkage

Solution Family 2: Layer 3/2 Multihoming

• Multilink PPP
• Multiple defaults into IGP
• BGP tunnel over multiple media
• BGP primary/backup
• BGP full routes

Solution Family 3: Medium /Tranmission Multihoming

• Multiple cable entrances
• Sonet redundancy
• Wireless backup
• RFC1149

What happens next?

Read the draft and send Howard comments. Let him know what are other cases he may have missed. He also like to hear more about provider provisioning needs.

Also, how can we get more of this documented.

Questions & Answers

Do you agree that more end users are multihoming?

Yes, I do. However, lots of end users don't really understand how it works and hence they don't know all the details. As a result, they end up with connectivity gaps.