Redundant Routes, BGP with MPLS provider

virendra rode virendra.rode at gmail.com
Fri Aug 31 18:32:57 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/31/2012 09:21 AM, Bill.Ingrum at t-systems.com wrote:
> I think having a GRE tunnel for the internal routing protocol is 
> unnecessary.  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 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.
> 
> Thanks,
> 
> Bill
- -----------------------
Using bgp communities (MED attribute "inbound") helped influence our
path(s) between our mpls providers.


regards,
/virendra
> 
> -----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.
>> 
> ************************************************************************
>
> 
**************************
>> 
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlBBA1kACgkQ3HuimOHfh+HhsgD7BGtBuiX9tw0leW5e2Jv3jT5E
OvAlvkc6bJgE6oSPwdYA/2AkjAWawOOJAIvkmIh6+jXQJo5IRJhl5u6IqtbwFKsy
=zUYy
-----END PGP SIGNATURE-----




More information about the NANOG mailing list