Jack- We did discuss this when designing our solution. In then end we decided not to introduce another routing protocol to our enviornment. We rely exclusivly on BGP and EIGRP. It may not be the best solution, but servicability is also important.
Dylan -----Original Message----- From: Jack Carrozzo [mailto:[email protected]] Sent: Wednesday, April 07, 2010 10:34 AM To: Dylan Ebner Cc: Beavis; [email protected] Subject: Re: Best Practice: 2routers, 2isp, 1AS Could also just push default into OSPF from both ends (assuming you have the iBGP between both borders) if your goal is redundancy. -Jack Carrozzo On Wed, Apr 7, 2010 at 10:06 AM, Dylan Ebner <[email protected]> wrote: > You can still use vrrp in the inside. We have a similar configuration to what > you have defined. Two routers, 4 ISPs, BGP annoucing 2 /24's. We get partial > routes and prepend on 3 of the isps to only use our primary. Our primary is > delivered via fiber and the backup isps are delivered via copper ethernet. We > use interface tracking with reachability to determine if we are having a > problem with one of our downstreams. This way, if we still have a link light, > but no traffic flow we can detect and adjust accordingly. > > > > Dylan > > -----Original Message----- > From: Beavis [mailto:[email protected]] > Sent: Wednesday, April 07, 2010 12:42 AM > To: [email protected] > Subject: Re: Best Practice: 2routers, 2isp, 1AS > > thanks for the reply brian. :) > > sorry for a bit lack on the info, I was thinking of using VRRP. but my > 2 links are running on different interface-types isp1 runs via > ethernet while the other is on an ATM interface. I only have 1 router > that has an ATM interface. setting it to VRRP would cause me problems > if it was a physical failure. I have a small /24 to advertise on my > AS. I'll go and check on the "Performance Based Routing" you > recommend. > > > thanks, > -b > > On Tue, Apr 6, 2010 at 11:25 PM, Brian Feeny <[email protected]> wrote: >> >> There are alot more questions that need to be asked. Like how much address >> space do you have to announce? What routes are you getting from each ISP? >> >> Assuming you are an end user, and knowing the very limited information I >> know at this point, I would make sure that these two routers LAN interfaces >> are in some sort of transit vlan/subnet with my downstream router, which >> would also be participating in iBGP. Alternately you could have that router >> do VRRP/HSRP with your two border routers, but I prefer iBGP. >> >> I would then setup both routers using OER (Optimized Edge Routing, i think >> now known as Performance Based Routing), to handle outbound. You could just >> announce your /24 out each provider (assuming that's what you had) to handle >> inbound, or if you have larger than that you could announce the aggregate >> out both and more specifics out each to do some type of balancing. >> >> Its hard to say there is a best practice here, as there are so many >> scenarios. I will say that I like OeR/PfR for edge customers who are dual >> homed. BGP is very arbitrary, and its nice to have some real metrics that >> mean something to play with :) >> >> Brian >> >> >> On Apr 7, 2010, at 1:14 AM, Beavis wrote: >> >>> Greetings! >>> >>> Want to ask out anybody on the list about a "best practice" of the >>> setup below: >>> >>> - 2 ISP's (A & B) >>> - 2 Routers (A & B) >>> >>> I want Router-A for ISP-A, Router-B for ISP-B and have Router-A & >>> Router-B talk and be able to pass routes on each side in an event of a >>> physical failure on one of the Routers. >>> >>> I was planning at first to setup a multi-home BGP, but I want to have >>> physical redundancy as well. >>> >>> ASCII-diag >>> >>> =--[RouterA]--isp1(bgp) >>> L | >>> A iBGP >>> N | >>> =--[RouterB]--isp2(bgp) >>> >>> Any recommendation would awesomely appreciated. >>> >>> -B >>> >>> >>> -- >>> () ascii ribbon campaign - against html e-mail >>> /\ www.asciiribbon.org - against proprietary attachments >>> >> >> > > > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > > >
