Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP

[Lixia Zhang <lixia at CS.UCLA.EDU>]

From: dino at cisco.com

Date: April 12, 2007 9:41:23 PM PDT

Cc: "Templin, Fred L" <Fred.L.Templin at boeing.com>,

 ram at iab.org

From: Dino Farinacci <dino at cisco.com>

Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP

Date: Thu, 12 Apr 2007 21:41:21 -0700

To: marcelo bagnulo braun <marcelo at it.uc3m.es>

i have sent this question a while ago that described this exact  

situation, maybe you can describe how LISP deals with this  

situation....

Sure.

I assume we are using LISP1

Consider that we have a host A in a site a that has EID EIDA (which  

is globally routable in order to be able to bootstrap the initial  

EID-to-RLOC mapping) and RLOCA which is a different address.  

Suppose that site

We have another host B located in a different site b that has a  

another locator RLOCB. Suppose that both site a and site b has  

multiple ISPs (at least two and they have several TR, for fault  

tolerance reasons)

Okay, first off the hosts don't have locators. The locators are  

assigned to the ETRs.

Suppose now that host B initiates a communication with Host A

Host B sends a packet to host A

The packet contains EIDA as dest add and EIDB as src addr

The packet is processed by an ITRB1 close to site b

Since we are in LISP1, the packet is forwarded as it is

No, not true. ITRB1 prepends an IP header to the host's packet. The  

outer SA is ITRB1's locator address and the outer DA is the EIDA  

(copied from the inner DA). This is only used to trigger a mapping  

reply from the ETR that is responsible for the EID range associated  

with host A. This happens in both LISP 1.0 and LISP 1.5.

the packet reaches the ETRA1 close to site a and the ETR sends a  

ICMP packet back to the ITRB1 with the RLOCA information and the  

mapping between EIDA and RLOC is stored in ITRB1.

The source address in the ICMP reply is one of ETRA1's locator  

addresses. The ICMP payload that describes the mapping indicates the  

*EID-prefix* that ETRA1 is responsible for and a list of all locators  

for this range (and their priority and weight values for each  

locator). All locators means IP addresses assigned to it or any other  

ETR in site A.

We have documented this in the spec.

Now bad things start :-)

Oh good, the meat.

First there is a failure and EIDA is no longer reachable

No problem with that, since ITRB1 has the information about  

alternative locators for host A, it will start sending tunneled  

packets using RLOCA as dest address in the outer header and the  

communication is preserved through this outage.

Ah, no fair, you avoided the real problem. You didn't even try to ask  

how does ITRB1 know the ETRA1 is not reachable.  ;-)

We do have answers for them though.  ;-)

However, now a second bad thing happens, which is that ITRB1 fails

I assume that it is possible in LISP, that an alternative ITR ITRB2  

is used for site B, so packets are rerouted to that backup ITRB1  

for site b.

Yes, of course. There are two ways an ITR determines a locator is not  

reachable:

o It receives an ICMP Unreachable message.

o It stops seeing packets it decaps from the EID-prefix range coming  

from one of

   the locators in the locator-set.

The later is better and more reliable. And I'm not worrying about  

asymmetric paths.

But the problem is that packets that host b is sending contain EIDA  

as destiantion address which is unfortunatelly unreachable at this  

time. this was not a problem

No, not true. EIDs are always reachable because they are not location  

addresses. The only time you can't get packets to EIDA, is when all  

locators are not reachable.

before because ITRB1 had the alternative locator information, but  

it has failed. The backup router ITRB1 does not contain the  

alternative locator information for EIDa (i.e. RLOCA), so how can  

the communication survive this outage?

Yes it does. This is not that hard.

I mean, i guess that fault tolerance is the key feature and the  

LISP boxes cannot become a single point of failure, so i guess it  

should be possible to survive this type of situations

If you deploy a single ETR, you have a single point of failure. So  

you deploy two of them. And if you have two ISP connections, each ETR  

has two locator addresses, one from each ISP block. Then when the  

mapping is advertised for this site it is done with a single EID- 

prefix advertisement with 4 locators.

See the section in the spec for locator selection. It is spec'ed to  

be flexible for the ETR to choose what locators the ITR uses, or the  

ETR allows the ITR to choose which ones.

Dino

From: ram-request at iab.org

Subject: confirm af86831f93db598d55a443098b7a4569dbaf4b59

If you reply to this message, keeping the Subject: header intact,

Mailman will discard the held message.  Do this if the message is

spam.  If you reply to this message and include an Approved: header

with the list password in it, the message will be approved for posting

to the list.  The Approved: header can also appear in the first line

of the body of the reply.

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram