Re: Routing to multiple uplinks

2009-12-19 Thread Steven King
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  > 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
> 
> 
> > anog29
> >
> > Might need to know a little more about the layout here for a
> better answer.
> >
> >   -Scott
> >
> > -Original Message-
> > From: rodrick brown [mailto:rodrick.br...@gmail.com
> ]
> > Sent: Friday, December 18, 2009 7:47 PM
> > To: nanog@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



Re: Routing to multiple uplinks

2009-12-19 Thread Rodrick Brown
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  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
> > anog29
> >
> > Might need to know a little more about the layout here for a better
> answer.
> >
> >   -Scott
> >
> > -Original Message-
> > From: rodrick brown [mailto:rodrick.br...@gmail.com]
> > Sent: Friday, December 18, 2009 7:47 PM
> > To: nanog@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


Re: Routing to multiple uplinks

2009-12-19 Thread Steven King
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
> anog29
>
> Might need to know a little more about the layout here for a better answer.
>
>   -Scott
>
> -Original Message-
> From: rodrick brown [mailto:rodrick.br...@gmail.com] 
> Sent: Friday, December 18, 2009 7:47 PM
> To: nanog@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




Re: Chinese bgp metering story

2009-12-19 Thread Joel Jaeggli


Paolo Lucente wrote:
> On Fri, Dec 18, 2009 at 10:09:32PM -0600, James Hess wrote:
>> On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin  wrote:
>> ..
>>> modified if need be - to achieve this. ?Mixing billing with the reachability
>>> information signalled through BGP just doesn't seem like a good idea.
>> Indeed not..  but it might offer one advantage, if  it was mandatory
>> for any such tarrif/cost to be advertised there to be valid, and  in
>> the form of an  ancillary BGP route attribute,  rather than buried in
>> some  500,000 page  treaty that forces all ISPs to decipher it and
>> try to figure out what their liabilities are.
>>
>> Mainly because it makes any tarrif very visible, and easily understood.
>> and offers an easy ability to automatically make decisions like
>> discard reachability information that has any billing labels or
>> "strings" attached to it, or has a cost greater than $X per million
>> packets  listed for 'source'...  and easily allows an ISP to  replace
>> the  next hop with null  when a tarrif option has been listed, or use
>> only a route not subject to tarrif.
> 
> I concur. Such visibility is efficient and drives simplification and
> automation from a data mining perspective, when analyzing accounting
> information.
> 
> In such context, some care is required. Reachability information is
> destination based. Mixing accounting (ie. NetFlow) and reachability
> (ie. BGP) information is of good value for traffic delivered out of
> a routing domain but not for traffic received, ie. reverse reachability
> lookups can be a way although they are not truly deterministic due to
> routing asymmetries; 

deliberate tunning for purposes of TE, use of default. will all
contribute to ingress path not resembling egress...

> a mix of ingress measurements, lookup maps and
> an export protocol supporting L2 information (ie. for same interface,
> multiple peers scenarios) give way a better chance to resolve which
> neighboring party is pulling which traffic into the observed domain.
> 
> Cheers,
> Paolo
> 
> 



Re: Chinese bgp metering story

2009-12-19 Thread Paolo Lucente
On Sat, Dec 19, 2009 at 08:42:33PM +0900, Randy Bush wrote:
> i am truely in awe how deeply the implications and alternatives have
> been analysed.  this is particularly impressive given the complete
> absense of any facts about the alleged proposal.

Part of the thread just went more of general discussion about
mixing accounting/reachability information despite the original
subject label was retained.

Cheers,
Paolo




Re: Chinese bgp metering story

2009-12-19 Thread Dobbins, Roland

On Dec 19, 2009, at 6:42 PM, Randy Bush wrote:

>  this is particularly impressive given the complete absense of any facts 
> about the alleged proposal.

I think the whole brouhaha is the merely result of someone saying 'BGP-speaking 
routers' vs. saying 'peering/transit edge routers', combined with the notion of 
somehow cartelizing this on a national basis vs. the current individual 
network-to-network private/public basis.

---
Roland Dobbins  // 

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken






Re: Chinese bgp metering story

2009-12-19 Thread Randy Bush
i am truely in awe how deeply the implications and alternatives have
been analysed.  this is particularly impressive given the complete
absense of any facts about the alleged proposal.

randy



Re: Chinese bgp metering story

2009-12-19 Thread Paolo Lucente
On Fri, Dec 18, 2009 at 10:09:32PM -0600, James Hess wrote:
> On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin  wrote:
> ..
> > modified if need be - to achieve this. ?Mixing billing with the reachability
> > information signalled through BGP just doesn't seem like a good idea.
> 
> Indeed not..  but it might offer one advantage, if  it was mandatory
> for any such tarrif/cost to be advertised there to be valid, and  in
> the form of an  ancillary BGP route attribute,  rather than buried in
> some  500,000 page  treaty that forces all ISPs to decipher it and
> try to figure out what their liabilities are.
> 
> Mainly because it makes any tarrif very visible, and easily understood.
> and offers an easy ability to automatically make decisions like
> discard reachability information that has any billing labels or
> "strings" attached to it, or has a cost greater than $X per million
> packets  listed for 'source'...  and easily allows an ISP to  replace
> the  next hop with null  when a tarrif option has been listed, or use
> only a route not subject to tarrif.

I concur. Such visibility is efficient and drives simplification and
automation from a data mining perspective, when analyzing accounting
information.

In such context, some care is required. Reachability information is
destination based. Mixing accounting (ie. NetFlow) and reachability
(ie. BGP) information is of good value for traffic delivered out of
a routing domain but not for traffic received, ie. reverse reachability
lookups can be a way although they are not truly deterministic due to
routing asymmetries; a mix of ingress measurements, lookup maps and
an export protocol supporting L2 information (ie. for same interface,
multiple peers scenarios) give way a better chance to resolve which
neighboring party is pulling which traffic into the observed domain.

Cheers,
Paolo




Re: Edge-Core (Accton) switches

2009-12-19 Thread Raoul Bhatia [IPAX]

On 02.12.2009 19:12, Todd Mueller wrote:

Anyone have any experience using Edge-Core switches (or Accton,
Edge-Core is a subsidiary)? Good/bad? Pricing/features seem good, but
you often get what you pay for . . .


we have a couple of Foundry Networks EdgeIron 4802CF, which should be 
similar to accton's ES3550C [1].


we have a hand full of vlans (10-20) configured and use them as a
top-of-the-rack (?) switch to connect our customer's servers. the gbit
uplink(s) are connected to our core equipment.

on our experience, the do no good job at handling too much load.
depending on the firmware, the management cpu will become too loaded
and you'll have troubles accessing the switch via ssh or you'll see
snmp issues.

however, i haven't seen any real issues with switching performance.

cheers
raoul
[1] http://www.accton.com/products/product_range/01_l2fes/es3550c.htm
--

DI (FH) Raoul Bhatia M.Sc.  email.  r.bha...@ipax.at
Technischer Leiter

IPAX - Aloy Bhatia Hava OEG web.  http://www.ipax.at
Barawitzkagasse 10/2/2/11   email.off...@ipax.at
1190 Wien   tel.   +43 1 3670030
FN 277995t HG Wien  fax.+43 1 3670030 15




Re: Chinese bgp metering story

2009-12-19 Thread Adrian Chadd
On Sat, Dec 19, 2009, Dobbins, Roland wrote:

> Existing hardware does this today with NetFlow, et. al.

.. not only that, we've been doing this for a bloody long time in
internet years. About all that really matter is figuring out how
to engineer your network to allow for netflow based billing without
having subtle duplicate flows everywhere..


Adrian
(Ah, thinking about this stuff brings back memories, and I'm only 30..)



RE: Routing to multiple uplinks

2009-12-19 Thread Scott Berkman
Anycast?
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.br...@gmail.com] 
Sent: Friday, December 18, 2009 7:47 PM
To: nanog@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.





Ipsec/VRF Mpls ?

2009-12-19 Thread Stephane MAGAND
Hi

after a first post with 0 answer (very thanks ..) i test a second post for
get a small help.

I am search a simple sample of configuration for a cisco 2821 for connect
a Ipsec routers ton a MPLS IP VPN Backbone

My cisco 2821 have two interface, one connected at my MPLS network
and the second at the Internet.

I create two vrf, one for a site to site and the second for a Remote User
Access

anyone have this into a config ? because i never have used Ipsec actually on

cisco.

The site-to-site router are a C1721, and remote user use cisco IPSEC client
and
i want a radius authentification (and it's the radius that sent the vrf)

thanks for your help
Stephane