[155958] in North American Network Operators' Group
RE: Redundant Routes, BGP with MPLS provider
daemon@ATHENA.MIT.EDU (Bill.Ingrum@t-systems.com)
Fri Aug 31 12:34:50 2012
Date: Fri, 31 Aug 2012 12:33:45 -0400
In-Reply-To: <CAD8GWstGiChvoH48oPXyqv+iLqpTm-xeDDAKXf7QzMgP1+VPZw@mail.gmail.com>
From: <Bill.Ingrum@t-systems.com>
To: <ler762@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I work for an MPLS provider, so I guess I tend to trust them ;)
Bill
-----Original Message-----
From: Lee [mailto:ler762@gmail.com]=20
Sent: Friday, August 31, 2012 11:28 AM
To: Ingrum, Bill
Cc: WTribble@sterneagee.com; nanog@nanog.org
Subject: Re: Redundant Routes, BGP with MPLS provider
On 8/31/12, Bill.Ingrum@t-systems.com <Bill.Ingrum@t-systems.com> wrote:
> I think having a GRE tunnel for the internal routing protocol is=20
> unnecessary.
It might be, but we have a requirement for multicast over the wan so the
GRE tunnels had to be there.
> Can you explain the reasoning behind this? I understand the=20
> technical issue whereby GRE will allow multicast for EIGRP, OSPF, etc,
> but why not just redistribute into BGP?
I see no reason to trust the provider that much.
> I work on a lot of MPLS CE routers, and in general you can accomplish=20
> anything you need by redistributing your internal routing protocol=20
> into BGP, and adjusting LP, MED and AS Prepend as needed.
Sure.. but how do you *know* you're not getting anything added/removed
by the provider?
Lee
>
> Thanks,
>
> Bill
>
> -----Original Message-----
> From: Lee [mailto:ler762@gmail.com]
> Sent: Friday, August 31, 2012 11:15 AM
> To: Tribble, Wesley
> Cc: nanog@nanog.org
> Subject: Re: Redundant Routes, BGP with MPLS provider
>
> On 8/30/12, Tribble, Wesley <WTribble@sterneagee.com> wrote:
>> Hello all,
>>
>> I am an Network Operator working in an Enterprise environment with=20
>> offices all over the country(mostly connected via MPLS). We are=20
>> currently working towards building a Disaster Recovery Site that will
>> host some of our vendor routers and provide the capability to access=20
>> these vendors from both our primary and backup data center locations.
>
>> The routes(as advertised by the vendor's routers) will be the same at
>> both locations. I would like to advertise the routes from multiple=20
>> locations at the same time, rather than suppress the routes and
> advertise conditionally.
>
> At work, we have our internal routing protocol running on GRE over=20
> IPSec tunnels & keep the BGP sessions with the MPLS provider limited=20
> to just the MPLS network. And have an ACL on the MPLS network
> interface that allows only what's expected in... some providers are
> better than others at not having anything hit the 'deny any any log'
> line
>
> Regards,
> Lee
>
>
>>
>> What is the best method to Instruct the provider's network to prefer=20
>> the Primary Data Center routes over the DR site? Keep in mind that I
>> am only peering with the provider over BGP and I have no visibility=20
>> to
>
>> the underlying MPLS architecture or configuration. Although if you=20
>> have specific questions about their architecture, I can work to get
> answers.
>>
>> Discussing in house, we have gone over a few different options:
>>
>> -Advertise specific routes from primary site and summary routes from=20
>> the DR site. Most specific will always be chosen.
>> -Prepend the routes from the DR site so that they will have a longer=20
>> AS-path than the Primary location -Use Community Strings to influence
>> local preference.(Still working to find out if Provider will pass our
>> community strings)
>>
>> Just looking for some ideas and best practices. Any thoughts or=20
>> insight would be much welcomed and appreciated. This is my first=20
>> message on NANOG, so please be gentle. I apologize in advance if I=20
>> have done something incorrectly.
>>
>>
>> Wes
>>
>>
>> ________________________________
>> *********************************************************************
>> *
>> **************************** Sterne Agee Group, Inc. and its=20
>> subsidiaries request that you do not transmit orders and instructions
>> regarding your Sterne Agee account by e-mail. Transactional details=20
>> do
>
>> not supersede normal trade confirmations or statements. The=20
>> information contained in this transmission is privileged and=20
>> confidential. It is intended for the use of the individual or entity=20
>> named above. The information contained herein is based on sources we=20
>> believe reliable but is not considered all-inclusive. Opinions are=20
>> our
>
>> current opinions only and are subject to change without notice.
>> Offerings are subject to prior sale and/or change in price. Prices,=20
>> quotes, rates and yields are subject to change without notice. Sterne
>> Agee & Leach, Inc. member FINRA and SIPC, is a registered=20
>> broker-dealer subsidiary of Sterne Agee Group, Inc. Generally,=20
>> investments are NOT FDIC INSURED, NOT BANK GUARANTEED, and MAY LOSE=20
>> VALUE. Please contact your Financial Advisor with information=20
>> regarding specific investments.
>> Sterne Agee
>> reserves the right to monitor all electronic correspondence.
>>
> **********************************************************************
> **
> **************************
>>
>
>
