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.ing...@t-systems.com> wrote: > I work for an MPLS provider, so I guess I tend to trust them ;) > > Bill > > -----Original Message----- > From: Lee [mailto:ler...@gmail.com] > Sent: Friday, August 31, 2012 11:28 AM > To: Ingrum, Bill > Cc: wtrib...@sterneagee.com; nanog@nanog.org > Subject: Re: Redundant Routes, BGP with MPLS provider > > On 8/31/12, bill.ing...@t-systems.com <bill.ing...@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:ler...@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 <wtrib...@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. > >> > > ********************************************************************** > > ** > > ************************** > >> > > > > > >
