Redundant Routes, BGP with MPLS provider

Fri Aug 31 17:18:05 UTC 2012

I'd prefer to trust / get the provider to do the right thing over losing
the 40 mtu points.... and all the associated headache therein.

-Blake

On Fri, Aug 31, 2012 at 11:33 AM, <Bill.Ingrum at t-systems.com> wrote:

> I work for an MPLS provider, so I guess I tend to trust them ;)
>
> Bill
>
> -----Original Message-----
> From: Lee [mailto:ler762 at gmail.com]
> Sent: Friday, August 31, 2012 11:28 AM
> To: Ingrum, Bill
> Cc: WTribble at sterneagee.com; nanog at nanog.org
> Subject: Re: Redundant Routes, BGP with MPLS provider
>
> On 8/31/12, Bill.Ingrum at t-systems.com <Bill.Ingrum at t-systems.com> wrote:
> > I think having a GRE tunnel for the internal routing protocol is
> > 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
> > 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
> > anything you need by redistributing your internal routing protocol
> > 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 at gmail.com]
> > Sent: Friday, August 31, 2012 11:15 AM
> > To: Tribble, Wesley
> > Cc: nanog at nanog.org
> > Subject: Re: Redundant Routes, BGP with MPLS provider
> >
> > On 8/30/12, Tribble, Wesley <WTribble at sterneagee.com> wrote:
> >> Hello all,
> >>
> >> I am an Network Operator working in an Enterprise environment with
> >> offices all over the country(mostly connected via MPLS).  We are
> >> currently working towards building a Disaster Recovery Site that will
>
> >> host some of our vendor routers and provide the capability to access
> >> 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
> >> 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
> > IPSec tunnels & keep the BGP sessions with the MPLS provider limited
> > 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
> >> 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
> >> to
> >
> >> the underlying MPLS architecture or configuration.  Although if you
> >> 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
> >> the DR site.  Most specific will always be chosen.
> >> -Prepend the routes from the DR site so that they will have a longer
> >> 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
> >> insight would be much welcomed and appreciated.  This is my first
> >> message on NANOG, so please be gentle.  I apologize in advance if I
> >> have done something incorrectly.
> >>
> >>
> >> Wes
> >>
> >>
> >> ________________________________
> >> *********************************************************************
> >> *
> >> **************************** Sterne Agee Group, Inc. and its
> >> subsidiaries request that you do not transmit orders and instructions
>
> >> regarding your Sterne Agee account by e-mail. Transactional details
> >> do
> >
> >> not supersede normal trade confirmations or statements. The
> >> information contained in this transmission is privileged and
> >> confidential. It is intended for the use of the individual or entity
> >> named above. The information contained herein is based on sources we
> >> believe reliable but is not considered all-inclusive. Opinions are
> >> our
> >
> >> current opinions only and are subject to change without notice.
> >> Offerings are subject to prior sale and/or change in price. Prices,
> >> quotes, rates and yields are subject to change without notice. Sterne
>
> >> Agee & Leach, Inc. member FINRA and SIPC, is a registered
> >> broker-dealer subsidiary of Sterne Agee Group, Inc. Generally,
> >> investments are NOT FDIC INSURED, NOT BANK GUARANTEED, and MAY LOSE
> >> VALUE. Please contact your Financial Advisor with information
> >> regarding specific investments.
> >> Sterne Agee
> >> reserves the right to monitor all electronic correspondence.
> >>
> > **********************************************************************
> > **
> > **************************
> >>
> >
> >
>
>