Routing to multiple uplinks

Steven King sking at kingrst.com
Sat Dec 19 14:20:03 CST 2009


HSRP/VRRP can be tweaked to less than 1s fail over time. Can you provide
a copy of your network map for analysis? GLBP might be a viable option
as fail over is not actually an issue at that point.

On 12/19/09 2:48 PM, Rodrick Brown wrote:
> VRRP/HSRP does not cause latency the problem we faced prior was when
> links flapped or timed out this would be too much of a hindrance for
> our users to reconcile application state with various trading venues
> we are trading thousands upon thousands of trades a minute to various
> destinations.
>
> As stated before Path A and Path B are two distinct paths they do
> however provide identical services but application state is not
> preserved. A new session and state must be established if a user
> decides to switch between paths.
>
> Essentially we provide the ability for users either shutdown and start
> sending orders to Path A or Path B based on latency from our servers
> to these trading venues we're actively monitoring latency between both
> end points.
>
> The overall design is being driven by our rigorous application needs
> more than anything.
>
> The implementation is straight forward we receive a duplicate set of
> feeds from site A and site B and can also access various services
> coming from site A or site B however, at any given time a user will be
> sending/recieving data from one of those destinations. Never both
> simultaneously.  So my question what is the best way to provide this
> type of redundancy at the host level?
>
> The application will only use one target address.
>
> On Sat, Dec 19, 2009 at 1:17 PM, Steven King <sking at kingrst.com
> <mailto:sking at kingrst.com>> wrote:
>
>     Maybe I am missing something, but how does VRRP/HSRP cause latency?
>
>     On 12/19/09 3:45 AM, Scott Berkman wrote:
>     > Anycast?
>     >
>     http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=&nm=n
>     <http://www.nanog.org/meetings/nanog29/abstracts.php?pt=NjcxJm5hbm9nMjk=&nm=n>
>     > anog29
>     >
>     > Might need to know a little more about the layout here for a
>     better answer.
>     >
>     >       -Scott
>     >
>     > -----Original Message-----
>     > From: rodrick brown [mailto:rodrick.brown at gmail.com
>     <mailto:rodrick.brown at gmail.com>]
>     > Sent: Friday, December 18, 2009 7:47 PM
>     > To: nanog at nanog.org <mailto:nanog at nanog.org> list
>     > Subject: Routing to multiple uplinks
>     >
>     > This may be slightly off topic however I have a very unique
>     situation
>     > where I need to provide two diverse paths to a major stock exchange.
>     > Each host may either use route A or B for any given reason to access
>     > this particular exchange using two distinct routers and target
>     address.
>     >
>     > The applicatiOn running on these hosts must only see/use one target
>     > address this needs to be transparent as possible. NIC
>     bonding/teaming
>     > on the host side isn't a viable solution because of the latency
>     > overhead same goes for vrrp/hsrp.
>     >
>     > I believe my only option here is to setup multiple default
>     routes with
>     > a preferred path of some sort. This seems to be possible using ip
>     > route2 on Linux.
>     >
>     > This just seems wrong on many levels and I thought I would post here
>     > because I know there is something obvious I'm missing.
>     > Please clue me in.
>     >
>     > Thanks.
>     >
>     > Sent from my iPhone 3GS.
>     >
>     >
>     >
>     >
>
>     --
>     Steve King
>
>     Network Engineer - Liquid Web, Inc.
>     Cisco Certified Network Associate
>     CompTIA Linux+ Certified Professional
>     CompTIA A+ Certified Professional
>
>
>
>
>
> -- 
> [ Rodrick R. Brown ]  
> http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown

-- 
Steve King

Network Engineer - Liquid Web, Inc.
Cisco Certified Network Associate
CompTIA Linux+ Certified Professional
CompTIA A+ Certified Professional




More information about the NANOG mailing list