Re: [Idr] VPN black holing because of non-checking next-hop

Robert Raszuk <robert@raszuk.net> Thu, 14 March 2013 17:44 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B691C11E8110 for <idr@ietfa.amsl.com>; Thu, 14 Mar 2013 10:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Level:
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ7oOEP5C5le for <idr@ietfa.amsl.com>; Thu, 14 Mar 2013 10:44:54 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5D82E11E80E9 for <idr@ietf.org>; Thu, 14 Mar 2013 10:44:54 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id 16so3391173iea.36 for <idr@ietf.org>; Thu, 14 Mar 2013 10:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Xz14G7yy5pdj9uFx/NnWjnImD3g7dfXf7h1wiMmrdHg=; b=UYFzMMamRX0gqqlyBLZGzuRxCNDd1q6ErnS6ei/FB/YWZv3Al2miKhHeTCY9e7svx1 d2A8Q4o9lWRKysDkxFKTRiOTja60j05NgcE7IEQ+4yIt2n60+B9WwfQgXDbdssoP3Ien a0yAWAvfokxoC8U8YMP4YhhhMPoE0vF4W7VJNBACU3oapRKSt2wPz2dZ/4ikjsxJfzme v/M/BWlocT098scKQaeb5YfR2qPGT3YEWvQPNlSvD0VkvEe8nTQm28046TlUg22/3WoP tYl+fu3g/WXSu/qMDYFTkQH8zg4h5BRUNZ2GPApJwtGsgDTFpddfLu7axwFVDk2jHVns 2BTQ==
MIME-Version: 1.0
X-Received: by 10.50.57.168 with SMTP id j8mr21254902igq.51.1363283093925; Thu, 14 Mar 2013 10:44:53 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.100.207 with HTTP; Thu, 14 Mar 2013 10:44:53 -0700 (PDT)
In-Reply-To: <391EA8C7AA431041830DE3479304D61E0906E839@ARCRNMSP223.latam.telefonica.corp>
References: <391EA8C7AA431041830DE3479304D61E0906E839@ARCRNMSP223.latam.telefonica.corp>
Date: Thu, 14 Mar 2013 18:44:53 +0100
X-Google-Sender-Auth: LNK6pcTlP7OujavDPxdKIfxqeYQ
Message-ID: <CA+b+ERmojhRg8mAgC0QLqraJyumcOAGJz+-0+awZcpA-zmgkbg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Antonio Huete <antonio.huete@telefonica.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "idr@ietf.org" <idr@ietf.org>, Ignacio Vazquez Tirado <ignacio.vazquez@telefonica.com>, Pablo Sesmero <pablo.sesmero.ext@telefonica.com>, Nuria Juarez Bengoa <nuria.juarez.ext@telefonica.com>
Subject: Re: [Idr] VPN black holing because of non-checking next-hop
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 17:44:55 -0000

Hello Antonio,

> §  If it is a Cisco PE (IOS or IOS-XR), no checking is done at all and if
> this next-hot meets conditions to become the “best” it is selected as such,
> causing service disruption because of traffic black-holing

Why wouldn't you use cisco ios build in LSP health monitor: http://goo.gl/vCLW0

You could also combine LSP ping with object tracking provided that
proper hooks are in place - I have not tested this myself, but found
object tracking to be a very powerful yet quite unknown tool ...

And above all you could just use IP mGRE automatic encapsulation
between PEs rather then LDP to architecturally solve your problems of
broken MPLS LSPs for good !

Cheers,
R.

PS. Before others will point it out this thread is more applicable to
c-nsp alias rather then IDR WG.



> On Tue, Mar 12, 2013 at 11:10 PM, Antonio Huete <antonio.huete@telefonica.com> wrote:
>
> Dear all,
>
>
>
> I write this e-mail for you because I knew you were working in draft
> http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selection-criteria/
> and the technology group I work in is very interested in these kinds of
> features as we consider them an important improvement when selecting
> next-hops that will become eligible, removing those that do not meet needed
> rules to become a best path.
>
>
>
> Let me explain some historical data about our network:
>
>
>
> -          Since 2001, the main vendor deployed in our network has been
> Juniper (close to 95% of routers) and the another 5% were Cisco 7600 acting
> as PE routers. But from last year, Cisco CRS-3 (in the core) and ASR9000 (in
> the edge) are being deployed, allowing this vendor to increase its presence
> in our network at the expense of Juniper.
>
>
>
> -          Historically,  Juniper routers have developed mechanisms to check
> if next-hops are valid, and if so they become as “eligible” as a previous
> step to become the “best”. If they are not valid they become “Unusable”, but
> never it will be selected as a best path, in which case it could provoke a
> traffic blackholing.
>
>
>
> -          Let me put a real example to illustrate how we take advantage of
> features like this:
>
>
>
> o   Our company offers MPLS VPN service to our clients
>
> o   LDP is used as transport mechanism
>
> o   If for any reason a label is not available for this next-hop (FEC) we
> find out 2 different behaviors:
>
>
>
> §  If it is a Juniper PE, it checks this next-hop is not valid and it
> declares it as “Unusable”, using the next  option it has available  as
> “best” path.
>
> §  If it is a Cisco PE (IOS or IOS-XR), no checking is done at all and if
> this next-hot meets conditions to become the “best” it is selected as such,
> causing service disruption because of traffic black-holing
>
>
>
> I would like you to be aware of the importance this feature has for us and
> take into account we have always had this feature on Juniper routers, but we
> found it was not available in Cisco devices, which is amazing for us.
>
>
>
> I also would like to know if you have plans to continue developing this
> draft.
>
>
>
> Best Regards,
>
>
>
> Antonio Huete | Telefónica Global Solutions
>
> IP Technology – Network Area
>
> Ronda de la Comunicación, s/n
>
> Oeste 1. Pl. 3, 28050 Madrid, Spain
>
> +34 670419485| +34 914830596
>
> antonio.huete@telefonica.com
>
>
>
> www.internationalservices.telefonica.com
>
> www.multinationalsolutions.telefonica.com
>
>
>
>
> ________________________________
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de la
> legislación vigente. Si ha recibido este mensaje por error, le rogamos que
> nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>