Re: Best Linux (or BSD) hosted BGP?

[Andy Davidson]

Hi, Bryan

You wrote:
> I know best subjective, but I'm looking at a project to announce some IP space
> that's between uses now and see what's there.  I'm planing to run a flow
> logger and ntop on the VM and see what is coming in if anything.  I'm looking
> at the options for BGP out there, and there's quite a few […]

Others have pointed several great open source BGP daemons which can interface
with Linux routing.  If you just want to ignore BGP for forwarding, and point a 
default
at one place, you might like to consider ExaBGP.  This is very lightweight - it 
can do
the BGP announcing of your prefix(es) without syncing routing changes to the 
Linux
routing table.  There are some simple AS112 instances, for example, delivered 
with
this model.  https://github.com/Exa-Networks/exabgp

Andy

Re: BFD for routes learned trough Route-servers in IXPs

[Andy Davidson]

Hi,

Douglas Fisher wrote:
> B) There is any other alternative to that?

Don't connect to IXPs with very very large and complicated topologies. Connect 
to local IXPs where the design makes a forwarding plane failure that causes the 
problem you describe less likely. 

Andy

Re: Announcing Peering-LAN prefixes to customers

[Andy Davidson]

Hi, Dominic --

On 20/12/2018, 17:49, Dominic Schallert  wrote:

> this might be a stupid question but today I was discussing with a colleague if
> Peering-LAN prefixes should be re-distributed/announced to direct 
> customers/peers.
> My standpoint is that in any case, Peering-LAN prefixes should be filtered 
> and not
> announced to peers/customers because a Peering-LAN represents some sort of
> DMZ and there is simply no need for them to be reachable by third-parties not 
> being
> physically connected to an IXP themselves.

There are no stupid questions!  It is a good idea to not BGP announce and 
perhaps also to drop traffic toward peering LAN prefixes at customer-borders, 
this was already well discussed in the thread.  But there wasn’t a discussion 
on how we got to this point. Until the Cloudflare 2013 BGP speaker attack, that 
sought to flood Cloudflare’s transfer networks and exchange connectivity (and 
with it saturating IXP inter-switch links and IXP participant ports), it was 
common for IXP IPv4/6 peering LANs to be internet reachable and BGP transited. 

This facilitated troubleshooting (e.g. traceroutes showing peering lan 
interfaces in traceroutes instead of ‘starring out’) and PMTUD (e.g. see 
recommendation in 
https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html which 
actually asked for IXP peering LANs to be announced).

There are good reasons to announce but there are better reasons to filter.  The 
security benefits of filtering outweigh the upsides on today’s internet, but 
fashions and best practice may further evolve over time. 

Andy


-- 
Andy Davidson
Director, Asteroid International BV  www.asteroidhq.com
Director, Euro-IX - The European Internet Exchange Association  www.euro-ix.net

Re: validating reachability via an ISP

[Andy Davidson]

On 29/03/2018, 00:22, Andy Litzinger <andy.litzinger.li...@gmail.com> wrote:
>
>> The root cause is that the our prefix is not being adequately
>> re-distributed globally by the regional ISP.  This is unexpected and we are
>> working through this with them now.

Hi, Andy —

Are you failing to advertise it, or are they filtering it on ingress, or are 
they failing to send it to their other peers?

One configuration mishap which is starting to come along more and more partial 
or poor reachability caused by route objects which are not correctly published 
in the IRRDB. It is going to be essential to make sure that you have properly 
recorded IRR route objects in, for instance, RADB.  More BGP speakers properly 
filter their peers using information that is published there.  Avoid future 
reachability problems by checking this today!

Yours,
A friendly route-server operator with strict filtering

-a



-- 
Andy DavidsonAsteroid International BV
https://www.asteroidhq.com@asteroidhq   @andyd
--
Local interconnection.  Where you need it.

Re: AS36040 Prefix Limits

[Andy Davidson]

Hi, Mike

On 18/10/2017, 18:39, Mike Hammett  wrote:

> I am looking for someone that can speak authoritatively regarding AS36040's
> ability to change their own prefix limits, prefix filtering, etc. 
> My current contact is advising the IX to do the filtering for them, which
> is not something IXes should be doing. 

Unless this is in conjunction with a multilateral peering session 
(“route-server”), when prefix-filtering is something that the IXP very much 
should be doing. 

Andy

Re: Peering + Transit Circuits

[Andy Davidson]

Hi, Max --





On 19/08/2015 17:36, Max Tulyev max...@netassist.ua wrote:

My solution is:

1. Don't care.
2. If some peer steal your transit, and it is noticeable amount of
traffic causing some problems for you - investigate and terminate that peer.

Unless this bandwidth fraud is taking place over a public peering LAN (IX).  
You could find that a non-peer is “stealing bandwidth”.  In which case, tell 
the IX operator (they *do* care, and *do* want to stop abusive or fraudulent 
behaviour).  

You can, if paranoid, apply some l2/3 filters to only hear from expected peers 
at the IX (which prevents non-peers from pointing statics at you, but not peers 
though.)  How paranoid shall we take it ?  You can also - with a small enough 
customer footprint - perhaps put each peer into their own VRF and apply 
policies which prohibit forwarding except to customer prefixes.  

-a

Re: Euro-IX quagga stable download and implementation

[Andy Davidson]

On 25 Apr 2015, at 15:16, Goran Slavić gsla...@sox.rs wrote:

   Considering what I have learned in your posts (and on other places
 that I have informed myself) I will definitely suggest to SOX management to
 go the way similar to what LINX did (1 Bird + 1 Quagga as route servers) for
 the simple reason that 2 different solution provides more security in
 context of new program update-new bugs problems and incidents and
 prevents other potential problems.

Goran - glad to have helped.

One last piece of advice which might be useful - to help to guarantee 
consistency of performance between the two route-servers, you should consider a 
configuration generator so that your route-server configs are in sync.  The 
best way to implement this at your exchange is to use IXP Manager, maintained 
by the awesome folks at the Irish exchange point, INEX.  
https://github.com/inex/IXP-Manager

IXP Manager will get you lots of other features as well as good route-server 
hygiene.

There’s also a historic perl-script that does this on my personal github.  Both 
of these solutions allow you to filter route-server participants based on IRR 
data, which has proved to be a life-saver at all of the exchanges I help to 
operate.  Having my horrible historic thing is maybe better than no thing at 
all, but I deliberately won’t link to it as you should really use IXP Manager. 
:-)

Andy

Re: Euro-IX quagga stable download and implementation

[Andy Davidson]

Hi, Goran, everyone --

On 23 Apr 2015, at 09:06, Goran Slavic gsla...@sox.rs wrote:

 at the mailing list and have an interest in downloading and implementing the 
 Euro-IX version of Quagga in our Internet exchange. My questions are simple:
 - Considering the time when the post is written (2012) - what is the current 
 status of the Euro-IX Quagga ?
 - Where can it be downloaded as a stable release / version ?

This email is a comment on using this software as a route-server, and not a 
comment on using this software as a RIB manager on a forwarding device - if 
you’re a reader from the future trying to understand about running this 
software on a router, then please bear this in mind.

There are three well known open source BGP implementations which are commonly 
used as a route-server - BIRD, Quagga, and OpenBGPd.  It is typical to 
configure them today in a way that has the route-server calculate a different 
RIB for every connected ASN on your exchange.  This is because it is also 
common to allow route-server users to filter (prevent their prefixes reaching) 
other participants.  Information about why this is important has been published 
in various presentations and papers at IX and operator events.

Calculating best-path for every participant becomes complex when you have a lot 
of participants, further when the number of prefixes on the exchange grows.  

OpenBGPd will stay up but take a very long time to process and forward 
announce/withdraw BGP messages.  On a ~100 ASN/participant/table system with 
~5000 prefixes, it can take anywhere up to an hour for a withdraw to be 
processed and forwarded which means your participants will get a route that is 
withdrawn for a long time and blackhole traffic at the exchange. It is 
therefore problematic to use this software on all but the smallest exchanges.  
It’s OK on small instances but does not scale.

Quagga’s vanilla build will fail to stay up with large numbers of tables and 
participants.  Chris Hall did an amazing job at making a build that was more 
prone to staying up and his build is doing a sterling job at LINX (alongside 
BIRD) but I understand that this source tree is no longer maintained and that 
the task of merging his stability fixes into the mainline or OSR 
(https://www.opensourcerouting.org) version is not a simple job and has not 
been done.  This gives me a serious concern about the future of this branch.

BIRD just doesn’t die, no matter what scale we seem to throw at it.  This thing 
just keeps flying.

We now have two (busy) BIRD instances at the LONAP exchange in London where 
most of our 150 exchange point members use the service.

Goran - SOX is a member of the Euro-IX association for exchange points and 
there is a private mailing list for members who operate route-servers.  There 
may be a greater concentration of route-server operators on that list so it’s 
probably worth continuing the discussion there?  You sign in to the website and 
visit https://www.euro-ix.net/mailing-list-archives to subscribe.

With best wishes,
Andy Davidson
(Relevant Hats: LONAP, IXLeeds, Euro-IX, IIX, NapAfrica)

RE: Prefix hijacking, how to prevent and fix currently

[Andy Davidson]

Hi,

Matthew Petach wrote:
 Be aware that even if you don't think you're peering with them 
 directly, you may be picking up routes via the public route 
 servers at exchange points, so check to see if you need to apply
 filters on your route server peerings as well.

At the risk of receiving 1,000 critical replies along the lines of an internet 
exchange is not the routing police, I will point out that an IXP route-server 
is actually a really elegant place to do route filtering.  

The IXPs I help to maintain (LONAP  IXLeeds in the UK) do perform IRR 
filtering on the MLP route-servers.  This is handy in the scenario that the ISP 
is manually filtering customers, where such a technique scales badly when 
considering how to filter peers.  We're transparent and help customers fix 
route objects when they don't understand why an MLP peering is not effective.  
If IRR wasn't a total crock, it'd be a really good system.


Saku Ytti wrote:
 Companies who are likely target for this, like MSFT and GOOG, 
 might want to monitor DFZ and see if they are receiving prefixes
 no one else is receiving.

The more eyes on the problem, the harder it is for these attacks to work, so 
the more likely targets (not specifically identifying the two companies in your 
example, there are lots of likely targets, many in the Enterprise space) who 
feed services like RIPE RIS or Routeviews, the easier it will be to learn what 
the attack vectors are and fight them.

Andy

RE: We hit half-million: The Cidr Report

[Andy Davidson]

Hi,

Patrick wrote:
 25-04-14500177  282878
 I think congratulations are still in order, but frankly, 
 I am less impressed with getting to 500 than 150. 
[...]
 Anyway, congratulations everyone. 

 now aggregate it back down again, please. :-)

(If only)

Andy

Re: Strict route filtering at IX?

[Andy Davidson]

Hi, Dan --

On 12/12/2012 11:22, Dan Luedtke m...@danrl.de wrote:

So, here's the question: How do you filter at exchanges?
Where is the error in my workflow?
Is strict route filtering a myth?

You can see if the route-servers at the IX already filter.  For example,
this is the case at LONAP, where strict filters against RADB are built.

Networks with open policy and large numbers of peers will naturally find
it hard to filter peer *prefixes* on session config, because as you have
found the config quickly becomes large and unwieldy.  As Arnold has said,
filtering with max-prefix and AS-path is more common on bilateral sessions.

My advice would be to encourage your IX operator to filter on the
route-servers, and rely on MLP derived adjacency for networks that you
want to peer with, but don't trust enough not to prefix-filter.

Andy

Re: Regarding smaller prefix for hijack protection

[Andy Davidson]

On 30/08/12 12:54, Anurag Bhatia wrote:
 Is using /24 a must to protect (a bit) against route hijacking? 

Announcing your, say /19 as 32 /24s does not prevent someone from trying
to hijack you, you will still get some disruption if someone tries, but
you might limit the scope of their success or the scope of your
perceived outage (which is why temporary shorter prefixes are announced
in order to limit the effects of hijacks, including in the example you
cited.)

Far more useful to monitor and take evasive action in the event of a hijack.

 So can we conclude that one should always use /24 to make sure that they
 loose as little as possible traffic during prefix hijacking?

There is not room for 4bn entries in the routing table.  You deserved to
be filtered off the net if you try this stunt !

Andy

Re: Level 3 BGP Advertisements

[Andy Davidson]

On 29 Aug 2012, at 20:28, Nick Olsen n...@flhsi.com wrote:

 In practice, We've always advertised our space all the way down to /24's 
 but also the aggregate block (the /20 or the /21). Just so there was still 
 reachability to our network in the event that someone made the foolish 
 mistake of filtering lets say prefixes smaller /23...

Filtering your de-aggregated prefixes in the presence of covering aggregates in 
this case would certainly not be foolish. :-)

Please, unless you really know why you need to do otherwise, just originate 
your aggregates.

Your friends,
Every other Autonomous System

Re: Bird vs Quagga revisited

[Andy Davidson]

On 22 Aug 2012, at 18:42, David Hubbard dhubb...@dino.hostasaurus.com wrote:

 Of those who have used Quagga or Bird, or anything else,
 would either of them be appropriate and/or well suited for
 use as an iBGP blackhole route server?

You can use Quagga or Bird as a blackhole BGP injector, because the forwarding 
load is next to nothing and the number of prefixes in your blackhole RIB is 
likely to be small.

You might - if you programatically get the blackhole criteria from your crm or 
some other database find ExaBGP to be easier to integrate with your data 
source.  ExaBGP is a very lightweight BGP speaker that is perfectly suited for 
this purpose - http://code.google.com/p/exabgp/

Andy

Re: Bird vs Quagga revisited

[Andy Davidson]

On 22/08/12 06:19, Hank Nussbacher wrote:
 Sorry to disrupt the bad cabling thread, but I'd like to revisit a
 thread from 2 years ago.  I have read over the NANOG presentations:
 http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf

 http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf


Much of the Quagga pain discussed openly in 2010 was related to its
performance as a route-server (which in a large instance might need to
converge many millions of best paths, in a multiple table setup).  A
route-server is more like a database which uses bgp as its interface,
than it is a router.  The problems that we felt as exchange operators at
this time were different to the ones that people using these packages as
a router felt.

 Both Quagga and BIRD have developed since the comparison in 2010:
 http://savannah.nongnu.org/news/?group=quagga
 http://bird.network.cz/?o_news

I'm not clear what you care about from a performance point of view -
forwarding ?  acting as a route-server ?  collector ?  BIRD is a great,
super-fast route-server daemon - much better than typical competitors
Quagga and OpenBGPd at this job.  In a forwarding capacity, I do not
know and I would really think that Operating system performance and
environment tuning will have more to do with forwarding performance than
the daemon used.

I am hoping that forwarding best-practice information for Quagga
eventually comes out of this project :  http://opensourcerouting.org/

Andy

Re: BGP MD5 at IXP

[Andy Davidson]

On 9 Mar 2012, at 22:24, Jay Hanke wrote:

 How critical is BGP MD5 at Internet Exchange Points? Would lack of
 support for MD5 authentication on route servers prevent some peers
 from multilaterally connecting? Do most exchange operators support it?

At LONAP in London, the route-servers do not support TCP MD5 authentication for 
BGP.  i don't think that this policy has led to anyone refusing to connect 
(about 80 of the 110 or so peers connected to the exchange use the Multilateral 
service - it is optional to connect to the MLP).  We have no plans to enable 
TCP MD5 on this service.

Because TCP MD5 packets touch a router's CPU, using MD5 introduces a new attack 
vector - see nanogii passim (e.g. 
http://www.nanog.org/meetings/nanog39/presentations/Scholl.pdf).  Don't do it. 
:-)

Andy

Re: routeviews.org domain registration

[Andy Davidson]

On 20 Dec 2011, at 12:02, Stephen Strowes wrote:

 I pinged John Kemp at uoregon.edu, but unsure if he is the correct contact 
 for this.

I beeped Dave Meyer, who acknowledged, so I think someone is on it.

Andy

Re: v6 Avian Carriers?

[Andy Davidson]

On 1 Apr 2011, at 17:47, Dorn Hetzel wrote:

 I was thinking today would be a good day to write an RFC for fractional 
 DHCP where end-users can get issued say 1/64 of an v4 IP, say 
 155.229.10.20:1024-2047.  Other users on the same DSLAM, etc behind the 
 carrier NAT would have other shares of the same public IP.   :)

Hi,

I'm not sure if this is an attempt at a continuation of the April Fools meme, 
or a serious idea, but this has kind already been thought of. :-)

https://mice.cs.columbia.edu/getTechreport.php?techreportID=560

It's a nice illustration that the only idea which doesn't suck post 
exhaustion[0], is IPv6.  

Andy




[0] i.e., now.

Re: Emulating a cellular interface

[Andy Davidson]

On 6 Nov 2010, at 05:53, Saqib Ilyas wrote:

 A friend of mine is doing some testing where he wishes to emulate a
 cellular-like interfaces with random drops and all, out of an ethernet
 interface. Since we have plenty of network and system ops on the list, I
 thought we might have luck posting the question here. Is anyone aware of a
 simple tool to do this, other than rather involved configuration of
 iptables?

Not withstanding Mikael's comments that it shouldn't be lossy, at times when 
you want to simulate lossy (and jittery, and shaped, and ) conditions, the 
best way I have found to do this is FreeBSD's dummynet :

http://www.freebsd.org/cgi/man.cgi?query=ipfwsektion=8#TRAFFIC_SHAPER_(DUMMYNET)_CONFIGURATION

Andy

Re: (cisco, or any) acl *reducers* out there?

[Andy Davidson]

On 19 Aug 2010, at 04:23, George Michaelson wrote:

 something which can take a couple of hundred basic and extended ACLs and 
 tell you
 these ten don't work
 these twenty conflict
 the remaining x have a sequence and can reduce to this basic x-y set
 A reasonable call. Its probably where we'll be by default, because there 
 isn't anything there and I think first principles upward is better than 
 paring back.
 [...]
 I think its clear a tool like I asked doesn't exist, and very probably won't, 
 anytime soon.

Hello

[ I'm sorry this reply is so late, holiday season ]

I understand the problem and think that it is partly caused by the complexity 
of keeping the acl configuration on all edge ports in sync, and keeping the acl 
definitions/purpose documented.

The way around this, is to have a configuration management system that records 
the detail of the ACL (description / ticket number - along with the filter 
specification in generic terms), which generates the configuration - or even 
better uses flow-specification to distribute the rules.  Further procedures to 
review the data in this management system periodically help this scale.

For the config management, this would tend to have to be locally bespoke (but 
simple to produce) in order to fit with existing policy and procedure, but the 
glue to push these rules out to routers is easy as open source tools exist :- 
  
http://labs.ripe.net/Members/thomas_mangin/content-exabgp-new-tool-interact-bgp 
  http://bgp.exa.org.uk/

Andy

Re: off-topic: historical query concerning the Internet bubble

[Andy Davidson]

On 7 Aug 2010, at 18:09, Roland Perry didn't exactly write:

 'a good rule of thumb during the late 1990's was that traffic doubled every 
 100 days'

This is the West, sir. When the legend becomes fact, print the legend.

To the original poster, there is another collection of memes (some might 
even/one day be true) on the 'Future of the Internet' lecture series, on 
Stanford's 'iTunes U' area - lecture 3 is on Internet Economics and touches on 
the history of this (mis?)-quote ?

Best wishes
Andy

Re: Route reflector/server appliance for access router aggregation

[Andy Davidson]

On 13 Jul 2010, at 15:06, Jack Carrozzo wrote:

 On the subject of route reflection, I've run into a few people happy with
 Quaggo or openBGPd on intel hardware. You can throw a 1U box together with
 dual PSUs, a bunch of ram, and SSD/CF disks for far less than a C or J setup
 and won't be wasting money on ASICs you aren't using. If I recall correctly
 this is  what Any2 was using when I spoke to them some years ago, but
 perhaps someone here can offer more specifics.

A side note - There is not a total commonality of behaviour/featureset between 
a reflector service at an IXP, and on a single AS.  IXP route-servers tend to 
be deployed on pc servers, because the C and J units don't have features 
required[1] for IXP operation (unmodified AS-path, filtering between 
participants, multiple RIBs for shadow-free filtering.)

That's not to say that white-box solutions wont work well on your network.  
It's easy to make the reflector highly available too - just run multiple 
reflectors, and build multiple adjacencies on your forwarding routers.


Andy


[1] Some slides on this topic should you be interested :

General explanation :
http://www.peering-forum.eu/epf3/presentations/day1/inex-epf-dublin-2008-09-15-01.pdf
http://tools.ietf.org/html/draft-jasinska-ix-bgp-route-server-00

Further reading on specific implementations:
http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf
http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf

Re: [Nanog-futures] Moving Forward - What kind of NANOG do we want?

[Andy Davidson]

On 3 Jul 2010, at 04:29, Simon Lyall wrote:

 Unless people serious intended for the organisation to have regular [1]
 meetings outside of North America (which I doubt)

No, don't.  The rest of the world already has $regionNOG.  If Nanog becaome 
WorldNOG, someone would make, err, NANOG again.

Andy


___
Nanog-futures mailing list
Nanog-futures@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-futures

Re: [Nanog-futures] Moving Forward - What kind of NANOG do we want?

[Andy Davidson]

On 1 Jul 2010, at 17:59, William Norton wrote:

 1) We started seeing folks having suite parties,
[...]
 2) We started seeing people quietly passing out logo'd and funny t-shirts,
[...]
 4) tours of data centers that don't sponsor NANOG but are local (we geeks 
 like these things),

These are really the same things.  

A good quality meeting 'Fringe' is a defining characteristic of a mature 
community.  Let it happen.  The fringe is the test-bed for stuff too crazy or 
early for the formal agenda.  Promote this ad-hoc stuff on the nanog site.  A 
good fringe will encourage more long-term attendees and attendee loyalty ( == 
revenue) without the program co-ordinators having to do more work.


Andy
___
Nanog-futures mailing list
Nanog-futures@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-futures

Re: networking podcasts

[Andy Davidson]

On 15 Jun 2010, at 14:37, Stefan Fouant wrote:

 For you Juniper and Arbor wonks out there, you can find some decent podcasts 
 on iTunes...  I can't remember the name of the Juniper Podcast but you should 
 be able to find it on iTunes without much effort... I believe the Arbor one 
 is called Security to the Core.

There are quite a few Juniper ones[0], though they take the format of a 
tutorial rather than a discursive/magazine format though, which is OK, but not 
what I want when driving. :-)

There's a tool called 'Handbrake' for the Mac which can be used to re-encode 
the nanog (and other meeting) video downloads to a format suitable for the 
iPhone/iPod/iPad.  This is quite good for flights/trains.

Andy



[0] Example = 
http://itunes.apple.com/podcast/junos-as-a-switching-language/id292449024, some 
others are linked from the bottom of this page,

Re: [Nanog-futures] Membership, and Transition comment

[Andy Davidson]

On 11 Jun 2010, at 16:55, Sean Figgins wrote:

 I believe that paid membership is the only way to actually have a real, valid 
 membership.

I agree.  Make sure non North Americans can join too, please.

However, I still maintain that, although I do support independence in 
principal, today's nanog community should ratify the decision, and that the 
cost-benfit (in financial and non-financial terms) of independence vs the 
status quo is presented in an easy to understand way.  I trust *this* SC to 
make good decisions, I think they are capable of doing that, I don't have a 
problem with the proposal, but checks and balances are important.  This is a 
big change.

Andy
___
Nanog-futures mailing list
Nanog-futures@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-futures

Re: Strange practices?

[Andy Davidson]

Hi,

On 7 Jun 2010, at 23:02, Joel M Snyder joel.sny...@opus1.com wrote:

 On 6/7/10 11:51 PM:
 Has anyone ever heard of a multi-homed enterprise not running bgp with 
 either of 2 providers, but instead, each provider statically routes a block 
 to their common customer and also each originates this block in BGP?
 Yes, this is common and works fine. [...] Ugly, but given the vast chalice of 
 despair that is the global BGP table, hardly a drop in the bucket.

Ugly, failover might not work depending on just what is actually configured, 
and there is of course no need to take the full table if you want to do it 
right, with BGP.

It does also marry your network to one provider, which might not suit depending 
on how independent you want to be (what will happen to your pricing with the 
address space incumbent at renew time, or what will happen in the event of 
their commercial failure).

Because something will likely work, does not make it a scalable or sensible 
design.

Just do it right from the start :-)

Andy   

Re: [Nanog-futures] Transition update

[Andy Davidson]

On 28 May 2010, at 08:15, Steve Feldman wrote:

 The Transition Team would like to assure everyone that we are working hard to 
 ensure a smooth transition from Merit to the new organization.  Members of 
 the Transition Team flew up to Ann Arbor to meet with Merit in person, and 
 planning is well under way.

Please have a closed ballot all-community vote, if not open consultation before 
doing more work.  (I think the work you are doing is beneficial)

 The full business plan is not yet in place,

Oops, wrong order !

Andy
___
Nanog-futures mailing list
Nanog-futures@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-futures

Re: MRLG Missing?

[Andy Davidson]

On 27 May 2010, at 20:36, Kyle Duren wrote:

 I know we just had a small discussion about this, looking glass stuff
 and such, but I had a copy of MRLG (the one from John Fraizer -
 OP-SEC.US) a while ago about I cannot seem to find the tarball anymore.
 The op-sec site appears to be dead, and so is a mirror site someone else
 put online a while ago (https://arpa.com/code/mrlg-5.4.1.tgz). Does
 anyone know what happened to John and his version of MRLG,

Is this the main distribution ?  I don't have the original tarball, but I have 
a hacked-on version of 5.4.1 in production.  I added in ipv6 command support 
for LONAP's MRLG install - http://www.lonap.net/cgi-bin/mrlg.cgi

I can send you this version if you would like it.

Andy

Re: Junos Asymmetric Routing

[Andy Davidson]

On 28 May 2010, at 00:27, Ken Gilmour wrote:

 ISP1 is the default gateway, ISP2 is a backup provider but which is always
 active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
 Client comes in on ISP2's link (non default gateway) but for some reason,
 the packets seem to be going back out through the link for ISP1.

This is perfectly normal and acceptable.  The problem you are having (the 
traffic ultimately disappearing) is that bad behaviour is happening, caused by 
flow-mode.  It does not work.  Juniper trying to force flow-mode in J-series 
since 9.4 has helped our Cisco mid-range hardware sales no end.  Are you 
reading Juniper ?  It does not work !

Anyway, I digress.

You need to put a filter on your interfaces that references a filter later on 
to not session track a flow.  I think you need to be running Junos-jsr[0] 10.0 
or 10.1 to use this :

interfaces {
  ge-0/0/X {
family inet {
  filter {
input [ packet-mode-in ... ]
output [ packet-mode-out . ]
  }
}
  }
}

firewall {  
family inet {   
   filter packet-mode-out {
 term stuff {
from {
something
}
then {
packet-mode;
accept;  
}
 }
   }
}
}



When we were trying to make this work reliably in the Junos-jsr 10 days, there 
were guides on juniper.net advising the following too, which we have preserved :


security {
alg {
dns disable;
ftp disable;
h323 disable;
mgcp disable;
msrpc disable;
sunrpc disable;
real disable;   
rsh disable;
rtsp disable;   
sccp disable;   
sip disable;
sql disable;
talk disable;   
tftp disable;   
pptp disable;   
}   
flow {  
allow-dns-reply;
tcp-session {   
no-syn-check;   
no-syn-check-in-tunnel; 
no-sequence-check;  
}   
}   
}   



Best wishes,
Andy Davidson




[0] One Operating System, One Big Advantage ?

Re: BT strike could affect internet and phone connections

[Andy Davidson]

On 27 May 2010, at 16:48, Tim Franklin t...@pelican.org wrote:

 Internet and phone connections across Britain could go into meltdown
 as BT workers threaten their first national strike for 23 years...
 I get a lovely vision from that of a real old-style manual switchboard
 operator, frantically plugging internet connections together with patch
 cords as each SYN packet rings a little bell.

So off-topic it hurts, but... http://www.youtube.com/watch?v=AgqEIp2YmtE

Andy 
 

Re: Quick IP6/BGP question

[Andy Davidson]

On 24 May 2010, at 19:21, Thomas Magill wrote:

 From the provider side, are most of you who are implementing IP6
 peerings running BGP over IP4 and just using IP6 address families to
 exchange routes or doing IP6 peering?

Different sessions, one for v4, one for v6.  This keeps config saner, therefore 
debugging easier.  It means you can split out your v4 and v6 edge in the future 
should you want to, without having to renumber and split out the sessions then.

Thanks
Andy

Re: Partial Use Of one Regions IP Block in another

[Andy Davidson]

On 20 May 2010, at 13:06, Net wrote:

 Are there any policies set by internet registries and/or transit providers 
 today that prohibits organizations from using a Partially used IP Block 
 allocated in one region say AP through APNIC to be comissioned and Propagated 
 in another region such as EMEA serviced by RIPE?.

In some circumstances, deaggregation of your rir-assigned prefix might lead to 
partial reachability (some networks filter on rir minimum assignment sizes - 
not a problem in itself, but some unclever networks exist, that don't 
additionally take a default).

Whatever you announce, make sure it's irr registered too, for the networks who 
transit or peer with you, who automatically build pfx filters.

Happy weekend,
Andy

Re: Surcharge for providing Internet routes?

[Andy Davidson]

On 1 May 2010, at 21:43, ML wrote:

 Has anyone here heard of or do they themselves charge extra for
 providing a complete internet table to customers?
 
 Waive the surcharge for sufficiently large commits?

Compared with some kind of reduced/waived fee for partial, or default only, or 
static routes ?

I have seen some of my customers get charged a set up fee (NRC) for bgp (beyond 
the port fee).  Normally an indication to me that we're going to have problems 
with this supplier  And I have never seen this as an MRC, but I guess it 
could happen.  Run a mile if so.

Andy

Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

[Andy Davidson]

On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
 Did you use Yahoo IM, AIM, or Skype?
 Yes, yes, and yes.  Works fine.

What about every other service/protocol that users use today, 
and might be invented tomorrow ?  Do  will they all work with 
NAT ?

Do many others work as well or act reliably through NAT ?

Will it stop or hamper the innovation of new services on the
internet ?

The answer to these questions isn't a good one for users, so
as the community that are best placed to defend service quality
and innovation by preserving the end to end principal, it is 
our responsibility to defend it to the best of our ability.

So get busy - v6 awareness, availability and abundancy are
overdue for our end users.

Andy

Re: Books for the NOC guys...

[Andy Davidson]

On Fri, Apr 02, 2010 at 08:09:29AM -0400, Robert E. Seastrom wrote:
 This morning I went digging for a book to recommend that someone in
 our NOC read in order to understand at a high level how Internet
 infrastructure works

How to do comes automatically, *why* to do is the difference between
a good and great engineer.

Watching old nanog (and other country-nog) archives is good, going to
the actual meetings and meeting people is better, and developing a
culture of shared understanding and colaboration is golden.

I guess I mean, working out the what the best way to build a network
is rather than following an example..

If you do like dead trees, then capturing the spirit of what I mean
comes from older books like my (prized) ISP Survival Guide (Geoff
Huston).

My 2p.

Andy

Re: Connectivity to an IPv6-only site

[Andy Davidson]

On 23 Apr 2010, at 07:50, Steve Bertrand wrote:

 http://onlyv6.com

Its a shame there is not a pair of images on this site - one originated from a 
v4 only box, one a v6 only box.  The img src= could point to the image with a 
query string that was an automatically incrementing counter.  Then you could 
have demonstrated statistics about v4 only, v6 only, and dual stack visitors.  
Alas, it looks like a neat bit of research in any case, hope it helps some folk 
debug their v6 into a working state too.

Andy

Re: IP4 Space

[Andy Davidson]

On 06/03/2010 21:32, Shon Elliott wrote:
 I would love to move to IPv6. However, the IPv6 addressing, I have to say, is
 really tough to remember and understand for most people.

Roll out DNS before you roll out v6 then.


 basically, you need technical knowledge to even understand how the IP address 
 is
 split up.

By split up, do you mean subnetting ?  You have to have technical
knowledge to understand CIDR in v4, and once you do you will understand
subnetting in v6 too.

These excuses are really false and old.  Forget the reasons why you
can't roll v6.  Do a little bit of work for your v6 roll out every day,
and it will be done in a few months.  Assuming you have made v6 support
part of your purchasing policy by now.

Andy

Re: IP4 Space

[Andy Davidson]

On 04/03/2010 19:30, William Herrin wrote:
 On Thu, Mar 4, 2010 at 2:12 PM, Joel Jaeggli joe...@bogus.com wrote:
 handling the v6 table is not currently hard (~2600 prefixes) while long
 term the temptation to do TE is roughly that same in v6 as in v4, the
 prospect of having a bunch of non-aggregatable direct assignments should
 be much lower...
 Because we expect far fewer end users to multihome tomorrow than do today?

The opposite, but a clean slate means multihomed networks with many v4
prefixes may be able to be a multihomed network with just one v6 prefix.

Andy

Re: RIPE NCC Position On The ITU IPv6 Group

[Andy Davidson]

On 26/02/2010 22:59, Bill Stewart wrote to nanog:
 Maybe I'm dense, but I don't see the problem.

The ITU is magic.  I am no expert, but I am aware that sometimes the ITU
decision making processes leads to member states having to adopt those
decisions as telecoms law.

I would not want to replace the very good address policy that I follow
today with laws and procedures that look like the ones used for
telephone numbers.  This is a very real danger.

That governments can form telecoms law, leads me to the conclusion that
we can have an RIR led addressing structure *or* a government one, and
not both.

 One of the great things about IPv6's address space being 
 mindbogglingly large is that there's plenty of it to experiment with.

No.  My IPv6 network is production now.  As are the IPv6 networks of
many other people on the list.  Please don't do experiments with
addressing policy, such behaviour tends to leave a nasty legacy.


On 01/03/2010 08:55, Arjan van der Oest wrote to members-discuss:
 Competition is not a bad thing.

Competition would be if I could approach the NCC or Pepsi Cola for my
integers for use on the internet.  It is not competition if the
government makes me ask them for some integers.

Andy

Re: RIPE NCC Position On The ITU IPv6 Group

[Andy Davidson]

On 01/03/2010 14:04, Arjan van der Oest wrote:
 Andy wrote:
 Competition is not a bad thing.
 Competition would be if I could approach the NCC or Pepsi Cola for my
 integers for use on the internet.  It is not competition if the
 government makes me ask them for some integers.
 Assuming that ITU would become a nationwide alternative RIR, you still
 have the choice to approach NCC, wouldn't you?

Why would this automatically be the case ?  If governments were required
to distribute addresses via the national regulator, then the freedom of
choice would NOT be the case.

 Not sure if Pepsi would be the right comparison for the ITU ;-)

My point entirely. :-)

Andy

Re: BIRD vs Quagga

[Andy Davidson]

On 13 Feb 2010, at 01:01, Nathan Ward wrote:

 On 13/02/2010, at 11:51 AM, Steve Bertrand wrote:
 
 fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I
 haven't tried those either...zebra/Quagga just stuck.
 OpenBGPd would be great for a public route server at an IX.

Nathan has made a good point.  Deploying them in an IX environment, with 
features like per-peer RIBs, very complex filtering, and the numbers of peers 
you might expect on a route-server environment, is a very different beast to 
(and more complicated than) deploying them in a network edge/forwarding role.

In a forwarding role, the underlying OS's features and the robustness of the 
daemon under load matters in different ways.  

So what's best ?  I have used all three in a forwarding role and found BIRD on 
Debian a pretty solid combination.  I found OpenBGPd on OpenBSD a pain to use - 
it converged really slowly and bgpctl seemed to lock up for a while after 
startup in an environment with *many* peers, and the behaviour with ospf3 used 
to change quite a lot.  Quagga on Linux or FreeBSD seemed to work ok, and the 
interface will be quite familiar to Cisco users.

Using all three as an injector for Anycast or similar leads to quite similar 
outcomes.  However you  might find ExaBGP more lightweight in this role - see 
http://bgp.exa.org.uk/ - do check it out.  This has an interface which will 
feel extremely comfortable to Juniper users.


You should still go to the IX Route-Servers panel to learn more about the 
software in question :-)  And its really very good research being presented - 
but I am biased here.

Best wishes
Andy  


-- 
// www.netsumo.com // Professional network engineering consultancy //
//uk ddi: +44(0)20 7993 1702//   us ddi: (415) 520 3589//

Re: Latest Cisco for small dual homed ASN

[Andy Davidson]

On 11/02/2010 18:53, James Smallacombe wrote:
 I have a customer that is looking at using BGP for their network; one
 connection over a few bonded T1s, the other over a Comcast Enterprise
 connection (which supposedly will do BGP now).
 When I was dual homed a few years ago, a 7204VXR with 256MB was more
 than adequate.  With routing tables growing the way they are, what's a
 good Cisco based solution on the lower end of the price spectrum that
 should handle this fine for a few years?

There was a bit of info missing from the replies in this thread, so I
shall inflict my thoughts onto you all.  Sorry, but :

On 11/02/2010 19:12, Matthew Huff wrote:
 You can squeeze by with 512MB, but 1GB of ram would be better.
 A 7204VXR with 1GB of ram will work fine.

... though you would want an npe-g1 or npe-g2 to avoid frustration.

On 11/02/2010 19:08, Seth Mattinen wrote:
 Any 2800/3800 ISR (except the 2801) will handle this just fine

Any sort of attack traffic will hurt this family in a hosting
environment in my experience.  They are good (feature-rich) in the
'branch' environment though.

We are also rolling out huge volumes of Juniper equipment, and medium to
high end J-series equipment is likely to vastly exceed expectations
without exceeding your budget.


Andy
-- 
// www.netsumo.com // Professional network engineering consultancy //
//uk ddi: +44(0)20 7993 1702//   us ddi: (415) 520 3589//

Re: ip address management

[Andy Davidson]

On 02/02/2010 21:14, Scott Berkman wrote:

I was about to suggest IPPlan, but it is lacking the V6 support.  Here is
one I found doing some searching, but I haven't used it myself:


We use IPPlan for ipv4 and a fairly flexible, but less fully featured 
management program called vim for ipv6.


Migrating our data out of ipplan to something else is a flashpoint that 
can lead to error, but we might have to do that.


It looks like the lack of ipv6 support in ipplan is partly due to the 
maintainer not wanting to support it, so we might be tempted to (if the 
license permits) fork the project and hack in support.  We have hacked 
it a lot already to build user-based containment between resources, so 
that we can have a vlan schema for many networks, and many customers 
(with their own logins, and only visability of their own subnets) in the 
same instance.  If we hack v6 support in, we could release the finished 
project - I think there was opposition to doing that thus far because 
the developer was embarrassed about some of the hacks ;-)


Andy

Re: Enhancing automation with network growth

[Andy Davidson]

On 26/01/2010 00:48, Steve Bertrand wrote:
 My original post was completely concerned on automating the process of
 spinning traffic throughput graphs. Are there any software packages that
 stand out that have the ability to differentiate throughput between
 v4/v6, as opposed to the aggregate of the interface? (I will continue
 reading docs of all recommendations, but this may expedite the process a
 bit).

That's a feature of the switch you are probing, not the monitoring suite
per se.

e.g. I have Cisco CPE that does count the difference :

bcliffe-gw#sh int accounting | b Vlan1
Vlan1 Wired network VLAN
ProtocolPkts In   Chars In   Pkts Out  Chars Out
  IP4587251 11371742684757409 3669014365
 ARP  12595 755700  524093144540
IPv6 188872   20699030 223349  131947020

 but these numbers can not be polled via SNMP, so the only way to
graph this device is with an expect script and telnet access.  Nice. :-)

There is an ipv6MIB, with some interface stats defined under
1.3.6.1.2.1.55.1.6.1, but I do not know of a family of devices which
supports this for sure.

If your devices support Netflow9, then this -- whilst an extremely
heavy/kitchen sink approach -- will give you any degree of granularity
that you like.

Not long term reliable, but if your v6 is presented via a tunnel, you
could graph that tunnel interface ?  Yuck, yuck (but we did measure some
ipv6 traffic use (more than we expected actually) at a recent
operational meeting in the UK)

Please let us all know if you find something with good v6 snmp support.

Andy

Re: Using /126 for IPv6 router links

[Andy Davidson]

On 24/01/2010 02:44, Larry Sheldon wrote:
 On 1/23/2010 8:24 PM, Owen DeLong wrote:
 64 bits is enough networks that if each network was an almond MM,
 you would be able to fill all of the great lakes with MMs before you
 ran out of /64s.
 Did somebody once say something like that about Class C addresses?

No.  There are only 2,097,152 Class C networks.

Assuming all MMs are spheroids of uniform oblate nature, radius major
axis=6mm, minor axis=3mm.  Volume is (4/3)Pi (Major^2) Minor
(http://en.wikipedia.org/wiki/Spheroid#Volume)

They will be poured into a great lake of your choice, and we will assume
random close packing (agitation mechanisms are probably best discussed
off-list) and a (generous, but the article insists) void fraction of 32%.
(http://en.wikipedia.org/wiki/Random_close_pack)

Volume of mm = 0.452cm^3, occupies 0.665cm^3.

Lake Erie is 484km^3
http://www.epa.gov/glnpo/factsheet.html

1 km^3 = 1,000,000,000,000,000 cm^3

484,000,000,000,000,000 * 0.665 = 321,860,000,000,000,000 mms needed to
fill this lake.

There are 4,294,967,296 /64s in my own /32 allocation.  If we only ever
use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952
/64s.  This is enough to fill over seven Lake Eries.  The total amount
of ipv6 address space is exponentially larger still - I have just looked
at 2000::/3 in these maths.

THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG.

** Can we please now just go ahead and roll out some ipv6 services ? **

Thanks
Andy

Re: Best Practices - BGP community to signal transit announces.

[Andy Davidson]

On 23/01/2010 17:51, Patrick Tracanelli wrote:

I am acting as transit for a number of ASNs, and my upstream peers do
filter my announces (as they should as I understand).


Absolutely.


Is there any best practices or RFC which shall suggest how this
community should be set up? Say, while I do standardize this community
to be MY-ASN:1 or MY-ASN:65501, is there a difference? Which community
numbers should be used for this purpose, if there are any best practice
for this?


This is a really bad idea, if you tag your customers' prefixes with a 
'do transit' community, then the customer leaks, you will tag the extra 
prefixes, and leak via your transit too.


You must filter your customers based on the data that they put into an 
agreed RPSL database, and then your transit provider should filter you 
on the same basis.


Some people shuffle static prefix lists to negotiate their prefix 
filters.  Life is too short for this though.  Let computers and 
databases do the work for you.



Andy Davidson // www.netsumo.com

Re: Network Bandwidth Reporting Tool

[Andy Davidson]

On 22 Jan 2010, at 02:13, Isaac Conway wrote:

 I am curious what tools you use to generate monthly usage and billing
 reports

This :

 I was thinking about writing some quick scripts to poll the router
 interfaces and put it to database,

Mainly because organisations have different methods for managing the flow of 
business metrics inside the org, e.g. crm/accounting 
packages/policies/products, and by writing your own glue between them you can 
automate the human error prone stages like this :

 a page I can pull up and gives me the numbers (95p,
 cost, overage, etc.) for the past month.  Copy and paste into a
 spreadsheet, job complete

Andy

Re: New netblock Geolocate wrong (Google)

[Andy Davidson]

On 19/01/2010 12:13, Richard Barnes wrote:
 FWIW, there has been some work in the IETF on creating protocols to
 allow pretty rich location information to be published in reverse DNS.

This would be good, but it must be remembered that this would only ever
be one clue about where a user actually is; for example we can not
expect people who use geo-ip to try to honour international copy rights
to ever use it.

Sadly ;-)

Andy

Re: Virbl: The First IPv6 enabled dnsbl?

[Andy Davidson]

On 16 Jan 2010, at 05:30, Tammy A. Wisdom wrote:

 Mark Schouten ma...@bit.nl wrote:
 http://virbl.bit.nl/index.php#ipv6
 Comments on the listing method are appreciated.
 wow bind?  thats gonna get slower and slower and slower.  I hope you have a 
 TON of ram for that box. for example
 if we loaded the current contents of the ahbl from rbldnsd to bind it would 
 take up a TON of ram.   bind would take forever to load and and would be 
 screaming for its dear life.

These problems tend to have a way of solving themselves...

This dnsbl is trying to get experience handling v6 data in an anti-spam 
environment.  We do not know how to do that today - and this is a problem which 
only reduces with experience.  The problems of how to scale it, to me seem like 
a smaller challenge. There are enough clever people who understand how to scale 
specific dns issues. :-)

Good luck to the team at Virbl !

Andy

Re: ip-precedence for management traffic

[Andy Davidson]

On 29 Dec 2009, at 17:19, Jared Mauch wrote:

 I've watched BCPs be diluted at various companies due to market pressures.  
 $major_provider did not require me to register my routes, why should I have 
 to do that in order to give you $X MRC for the next 12-24-36 months?
[...]
 Honestly, I wish we could have a better network.  One where we have 
 mutually agreed I will filter my customers if you do.

You can (should) still filter their prefixes - the customer get added pain 
because changes have to be done by hand, through tickets, maybe as a billable 
incident. :-)

Andy

Re: DNS question, null MX records

[Andy Davidson]

Eric J Esslinger wrote:
 I have a domain that exists solely to cname A records to another domain's 
 websites.
[...]
 I found a reference to a null MX proposal, constructed so:
 example.comINMX 0 .
[...]
 Question: Is this a valid dns construct or did the proposal die?

It's valid, but you will probably find people still try to spam to
machines on the A records, and all of the other weird and wonderful things
that spambots try to do to find a path that will deliver mail...

If there is no time that mail should appear *from* this domain name then
it's polite to set spf records as such - one of the few things spf is
always useful for :-) like this :

@   IN  TXT v=spf1 -all

... all this means in practice though is that spammers who actually bother
to check for this, will find someone else to masquerade.  But you won't
have to deal with the associated attempted bounce delivery connections...

Best wishes
Andy

Re: Leaving public peering?

[Andy Davidson]

On 2 Dec 2009, at 20:46, Lasher, Donn wrote:

This year I've been seeing what appears to be an increasing trend  
among

service providers.. making the decision to leave public peering.


Peering is often sold as 'cheaper than transit' - for everyone that is  
a gross generalisation, for many networks it is not true, but for some  
networks it is true.  But when managed properly peering should always  
lead to improved customer experience (speed of access, latency,  
availability) and access to a community of like minded operators with  
a common interest.


Therefore, certainly in Europe, we are seeing a growth in the number  
of networks peering - and from an ever increasingly wide section of  
the community (service providers, content, e-commerce, enterprise,  
gaming, education/research networks...).  And with a falling cost in  
long haul transmission we are seeing networks in Europe peer mode in  
the US, and networks from all over the world peering in Europe.


Check out this report on the success of peering :  
https://www.euro-ix.net/member/m/document/showDocument/id/158

spam  and then talk to exchange operators in the community about  
how you too can get involved. :-) /spam







--
Regards, Andy Davidson
Director, LONAP Ltd
http://www.lonap.net/

Re: Strip AS in BGP peer

[Andy Davidson]

Sherwin Ang wrote:
 well here it goes.  we'll soon form a new internet exchange and i
 would like to suggest a model in the route-server wherein the
 route-server would strip out it's own AS and give the neighbors/peers
 the AS's of the members.  I have seen this in Any2IX but i have no
 idea on how to implement it as if i am the Any2 route-server.


Hi, Sherwin

Sorry for the late reply.

We (LONAP, London UK) have deployed our route-servers using BIRD and
OpenBGPd on unix servers, rather than traditional big iron hardware for the
following reasons :

 - Availability of the 'stripped asn' feature as you describe.
 - Multiple RIBs per BGP instance, so that route-server participants who
filter (on the route-server) can do so without causing shadowing of prefixes.
 - Don't need the high-capacity forwarding - the route-servers swap
prefixes, not traffic.

As other posters in this thread have described, it's also possible to do
this with the Quagga software, but the current codebase appears to creak
(and then croak !) with scale, when multiple-ribs are enabled.

This email is pretty brief; the exchange community have been discussing
this and publishing talks on the subject since the beginning of the year,
as our understanding of the problems of running the common open-source so I
can point you to some resources that you may find interesting :

Our decisions and introduction to the LONAP service :
http://www.uknof.org.uk/uknof13/Davidson-LONAP_routeservers.pdf

INEX (Dublin, IE) describe the per-peer RIB problem and Quagga problems :
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/Hilliard-Why_use_Quagga_for_Route_Servers.pdf

LINX (London, UK) also describe the per-peer RIB problem and explain their
efforts to solve the Quagga problems :
http://www.uknof.org.uk/uknof13/Hughes-IXP_routeservers.pdf

EuroIX route server activity report from October :
http://www.ripe.net/ripe/meetings/ripe-59/presentations/hiliard-euroix-update.pdf
(Situation is more evolved now, but I don't know if more recent slides are
public)


The situation is likely to move quickly by the middle of next year, if
there is interest it sounds like a good operational BOF for N'49.

Andy

Re: IPv6 Deployment for the LAN

[Andy Davidson]

Iljitsch van Beijnum wrote:
 This would be a big mistake. Fate sharing between the device that
 advertises the presence of a router and the device that forwards packets
 makes RAs much more robust than DHCPv4.

No, what we want are better first hop redundancy protocols, and DHCP for
v6, so that everyone who has extracted any value from DHCP in their toolkit
can continue to do so, and roll out v6 !

A

Re: IPv6 Deployment for the LAN

[Andy Davidson]

On 18 Oct 2009, at 09:22, Mark Smith wrote:

If it's because somebody could start up a rogue router and announce  
RAs, I think a rogue DHCPv6 server is (or will be) just as much a  
threat, if not more of one - I think it's more likely server OSes  
will include DHCPv6 servers than RA servers.


Disagree - rogue offers affect people without a lease, so the impact  
of an attack is not immediate.  Filtering DHCP on v4 is well  
understood, an update to current operational practice rather than a  
new system.



On 18 Oct 2009, at 09:29, Nathan Ward wrote:


RA is needed to tell a host to use DHCPv6


This is not ideal.

Andy

Re: bgp best path compare-routerid implementation example

[Andy Davidson]

On 25 Sep 2009, at 05:24, devang patel wrote:


I am looking for the *bgp best path compare*-*routerid* implementation
example? I know the function of it but looking for some scenario  
where its

been used...


Hi, Devang

This option is really only used in order to instruct a router to skip  
the option before it in best path selection algorithm (prefer the path  
learned from the older established session).


I don't think you'd use it if you ran a normal network (or knew what  
you were doing ;-) ) because you'd typically use much more  
deterministic decisions to send traffic to specific and predictable  
paths, or you'd use hot-potato routing and send the traffic to the  
nearest equivalent exit ('prefer ebgp over ibgp' and 'prefer path with  
lowest igp metric' comes before 'use the oldest path').


Andy



--
Regards, Andy Davidson   +44 (0)20 7993 1700   www.netsumo.com
NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC

Re: Multi-homed implementation and BGP convergence time

[Andy Davidson]

On 11 Sep 2009, at 21:54, andrew.clayba...@securian.com wrote:

Hello - my company currently has two connections with a single tier  
1 ISP. We are using the AS from our ISP at this time.  In the next  
month we will be implementing a third connection with a second tier  
1 ISP, so we will now be using our own AS number on all three routers.


Does this mean that right now, you BGP peer with your ISP on a private  
ASN which they have given you ?


I also assume that you have your own PI, and that you are not  
deaggregating some of your providers' addressing 


My question is when we implement the new connection and update our  
existing connections to use are own AS number, how much downtime  
will there be?  So far the second ISP has only said that it could be  
hours for BGP to fully converge.  We are looking for more detail  
about how long the outage will be and how widespread.


It will be hours if you don't plan the work in advance, but if you  
partner with someone who rolls this stuff out all of the time to plan  
and execute the work, then there will be a short amount of downtime.


If your kit supports local-as, then I would roll this out in a few  
phases.


 - Migrate to your new ASN for ibgp, use local-as to announce via the  
old asn on your ebgp session with ISP1.  This is the bit where the  
service disruption will be.  By keeping the scope of this window  
small, you increase the chances of this disruptive maintenance working  
fine.

 - Turn up isp2.  Test, thoroughly.
 - Migrate isp1 from the private asn to your new public asn.  All  
traffic should pass through isp2, so disruption should be limited.  
Test, thoroughly.


Will it be relatively short to our customers that are on one of the  
ISPs we are directly connected to?  Is downtime less for customers  
on other tier 1 ISPs versus tier 2, etc. ISPs?


Downtime is less the more competent your ISP. :-)  Tierness is not a  
measure of this.


Sorry for the late reply, if this still needs to be rolled out, then  
we can help.




Best wishes
Andy



--
Regards, Andy Davidson   +44 (0)20 7993 1700   www.netsumo.com
NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC
/* Opinions are mine  do not constitute policy of those I work for */

Re: BGP Confederation over Route Reflector

[Andy Davidson]

On 10 Sep 2009, at 03:52, devang patel wrote:

What are the advantages of BGP Confederation over Route Reflector? I  
mean when one should decide to deploy BGP Confederation over Route  
Reflector deployment?



When doing so is simpler to support in your ibgp mesh than not doing  
so.  And probably not before this time !



Best wishes,
Andy




--
Regards, Andy Davidson   +44 (0)20 7993 1700   www.netsumo.com
NetSumo  Specialist networks consultancy for ISPs, Whitelabel 24/7 NOC
/* Opinions are mine  do not constitute policy of those I work for */

Re: Repeated Blacklisting / IP reputation

[Andy Davidson]

On 9 Sep 2009, at 06:04, Peter Beckman wrote:

How about a trial period from ARIN?  You get your IP block, and you  
get 30 days to determine if it is clean or not.


The reuse issue is possibly decades away in v6 land.

The reuse issue can't really be solved for v4 in a year or two.

Sounds like a waste of time to develop this idea further IMO.

A

Re: OSPF vs IS-IS vs PrivateAS eBGP

[Andy Davidson]

On 19 Aug 2009, at 16:12, Clue Store wrote:
I would like to run an IGP (currently OSPF) to our customers that  
are multi-homed in a non-mpls environment. They are multi-homed with  
small prefixes that are swipped from my ARIN allocations.

[...]

Customers do, err, interesting and creative things, in unexpected  
ways.  Develop a standard filtering/protection layer from them and  
deploy it however they connect to you - ergo use one routing protocol.


Using bgp means you can transit people who aren't pinching your own  
arin space with the same filtering techniques.  The filtering methods  
and techniques for customer/provider edges are well understood and  
documented for bgp so if you need help, then help is out there.  With  
bgp you'd also leave less of a time bomb for whoever succeed you in  
the future.  This is before we even look at the technical reasons why  
bgp is more suitable than a flooding RP for this deployment.


Use BGP ;-)

A

Re: East Africa Fibre Connectivity- Heads up

[Andy Davidson]

On 5 Aug 2009, at 11:13, Raymond Macharia wrote:

Hello all,in the last two weeks or so providers in East Africa,  
particularly

in Kenya where I am, have been moving from Satellite to Fibre for the
internet Back bone connectivity. From where I am I have seen an  
upsurge of

about 100Mbps in the last two days from my users.


Hi, Raymond --

We see similar changes to traffic in the internet exchange world when  
someone changes their connection from 1GE to 10GE.  Before they turn  
up additional sessions, they often peer more traffic, which I  
attribute to sliding window doing its thing, and eventually user  
behaviour altering.


It's encouraging that your customers' internet performance experiences  
are improving - do share your upgrade stories with other providers in  
your region !


Best wishes,
Andy

Re: OOB customer communications (Re: Looking for Support Contact at Equifax)

[Andy Davidson]

On 27 Apr 2009, at 04:24, Suresh Ramasubramanian wrote:


If your email and phone communications are down due to a connectivity
break, and your customers get connectivity from you [assume no backup
links, by default .. you'd be surprised at how many smaller customers
get by with a single link and no backups at all.  If their
connectivity is down too - they just cant get to twitter right?


Twitter, in line with the subject line, has got out of band - updates  
by SMS.


So the general lesson is that even organisations with single homed  
connectivity can post updates to colleagues, peers, customers, if they  
build tools that let them do so from their cellphones... whether this  
is via twitter or an externally hosted blog, or status page, or  
something else.


Andy

Re: SIP - perhaps botnet? anyone else seeing this?

[Andy Davidson]

On Wed, Apr 15, 2009 at 11:35:43AM -0500, Dane wrote:
 Today I heard from someone who says Verizon is telling them they see
 about 700 calls per hour to Cuba originating from their PRI.
 Obviously some type of toll fraud. 

In the same way that it's possible to configure a mail relay as a
device that forwards mail between unintended parties, it is possible 
to configure a SIP proxy as a device that causes calls to be 
forwarded between unintended parties too.

Likewise, in the same way that spammers scan network ranges for these
misconfigured mail gateways, thieves look for unsecured SIP gateways
to relay calls through.

The SIP traffic mentioned at the start of this thread doesn't follow
the pattern of this constant background noise.


Kind regards,
Andy

Re: AS path weirdness

[Andy Davidson]

On 21 Mar 2009, at 02:48, Jason Lewis wrote:

I'm not entirely sure what I'm looking at. The reserved AS, 65490  
appears in parentheses and I've never seen that in MRT formatted  
data and not sure why it's happening.


This has been observed when a vendor runs 32-bit AS aware code on part  
of their edge, and non-32-bit AS aware code on a different part of  
their edge.


I'm also not clear on why I see 23456 *and* a 32 bit AS in the  
path.  Is anyone else seeing this or is it something wacky at RRC04?

91.207.218.0/23|29222 6830 (65490) 3356 35320 3.21 23456


There's some history with this prefix.

http://www.andyd.net/media/talks/asn4_breaks_network.pdf [from nanog45]

Andy

Re: Anyone using any Linux SSL proxies?

[Andy Davidson]

On 15 Mar 2009, at 18:04, Michael K. Smith wrote:


We use Apache with mod_security and mod_proxy to do this, although the
application is more as an application layer firewall than an SSL  
offloader.
It works well for lower traffic applications; I haven't tested it  
under the

loads that are advertised by the hardware vendors you mentioned.


hi

If you have multiple back end worker web services, then you should  
investigate the mod_proxy_balancer module, as it gives you an extended  
feature set that helps in this regard.



Best wishes
Andy Davidson

Re: Usage-Based Billing for DIA

[Andy Davidson]

On 5 Mar 2009, at 22:02, Rodriguez, Mauricio wrote:


Looking at possibilities for an implementation of usage-based billing,

[...]

+Techniques
   --SNMP polling of interface counters to determine  
95th percentile traffic levels



+Tools
   --RTG
   --MRTG
   --Cacti


You can be pretty sure that there are probably a lot of billing  
systems based loosely around the tools mentioned here, and that in  
their particular environments they are robust enough to be successful.


If you go down this route, or a similar route, you need to remember  
that you MUST update the default RRD storage behaviours so that the  
most granular data is not aggregated until four or five months after  
the billing month, otherwise you will find that the averaging causes  
different results to fall out of your scripts when you look into  
customer queries on their bill !


Best wishes
Andy

Re: anyone else seeing very long AS paths?

[Andy Davidson]

Hi,

Yep, we see them too.  Nasty because there are lots of networks  
flapping as the long as-paths are tickling old bug CSCdr54230, so even  
networks not affected by the bug will be getting lots of extra updates.


Anyone with contacts at 47868 ?  Any upstreams onlist that want to bin  
them ?


Andy

Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

[Andy Davidson]

On Thu, Feb 05, 2009 at 07:19:37PM -0500, Robert D. Scott wrote:
 Wii should not even consider developing  a cool new protocol for the Wii
 that is not NAT compliant via V4 or V6. And if they do, we should elect a
 NANOG regular to go POSTAL and handle the problem. The solution to many of
 these networking conundrums should rest with the application people, and NOT
 the network people.

You are wrong, there are lots of new ... and not so new ... protocols that 
*can* work via ALGs or other NAT traversal systems, but tend to work worse 
than if they'd had end to end visibility.  The various VoIP protocols are 
the perfect example.

The end to end principal is the lifeblood of innovation on the internet and
we need to do everything we can to allow anyone who wants it to have it.


Kind regards,
Andy Davidson

Re: One /22 Two ISP no BGP

[Andy Davidson]

On Fri, Feb 06, 2009 at 01:13:14PM -0500, Joe Maimon wrote:
 Perhaps ebgp-multihop with this ISP's upstream provider might offer you 
 an advantage combined with this approach.

This is quite neat, but the ISP may be multihomed and support BGP at
one edge (several transits, several peers), but not at their customer
facing edge.

Andy

Re: Anyone notice strange announcements for 174.128.31.0/24

[Andy Davidson]

On 14 Jan 2009, at 16:06, Jeroen Massar wrote:


Simon Lockhart wrote:
(Yes, I'm in the minority that thinks that Randy hasn't done  
anything bad)
Nah, I agree with Randy's experiment too. People should protect  
their networks better and this is clearly showing that there are a  
lot of vulnerable places in the core internet structure.


The end sometimes justifies the means, and someone in the research  
community discovering flaws in bgp implementation (software, protocol,  
or process - at the bgp stack, in my NOC tools, in the community's  
understanding) before hackers/spammers/fraudsters do, then I count  
that as a result.



Andy

Re: What to do when your ISP off-shores tech support

[Andy Davidson]

On 27 Dec 2008, at 05:59, JF Mezei wrote:

The problem with oursourced first level support is that they are  
totally disconnected from real time operations and wouldn't be aware  
of problems that network engineers are currently working on.


That's a problem with a lot of internal first line teams too..

Offshore and outsource are different things, and when done right are  
irrelevant to the quality of service delivered.  A willingness to  
offshore means you can deliver follow-the-sun NOC or support service,  
which can drive down delivery costs and health/safety risks for the  
organisation and drive up service quality by meaning that callers  
reach someone alert and awake ;-).  Outsourcing offshore service makes  
it cheap and easy to do that.


Doing this well relies on building a process, and actually a different  
process for each network being supported, though I don't want to give  
away all the hints that I learned the hard way !



Andy

Re: What is the most standard subnet length on internet

[Andy Davidson]

On 19 Dec 2008, at 04:43, 정치영 wrote:

It seems so simple. Currently annoucement of /24 seems to be okey,  
most upstream providers accept this.
However I wonder if there is any ground rule based on any standard  
or official recommandation.


The only rule is my network, my rules ;-)

But if general rules did exist, they might say 1) not to announce  
smaller than a /24 to external parties without agreement, and 2) not  
to carve up registry assigned address blocks into individual  
announcements.


1 - You might announce your registry assigned block, AND deaggregated  
blocks to upstreams or peers for traffic engineering purposes, but you  
need to work closely with them to make sure that they don't filter the  
deaggs from your session, and also to make sure they don't onwardly  
announce the deaggs).


2 - The default free routing table is 270,000 entries large, and this  
is too big for lots of kit, so networks ARE FILTERING TODAY on  
registry boundaries.  If you don't understand the implications of this  
do not deaggregate the addresses that the registry assign you.


Good luck with your project.  Drop me a note offlist if you need  
specific advice.


Andy

Re: Netblock reassigned from Chile to US ISP...

[Andy Davidson]

On 13 Dec 2008, at 12:39, Steven M. Bellovin wrote:

On Fri, 12 Dec 2008 16:33:51 -0800 Tomas L. Byrnes  
t...@byrneit.net wrote:
Because anyone with half a brain blocks proxies from their e- 
commerce site.
What is a proxy?  A garden-variety squid server, in the DMZ of a  
corporate firewall?  The nasty box in some hotels that helps  
guests surf the net?  A socks proxy installed by the RBN on  
unsuspecting desktops?


Hi,

We've all jumped on Tomas, but I suspect that the word 'open' was  
missing from his summary.  I've worked in e-commerce environments  
where we deployed tools that checked whether orders with high risk  
scores appeared to come through an open proxy, and unusual browsing  
patterns were detected and investigated for the same.


I wont give the game away, since some of the people on this list will  
be able to work out who I am talking about :-) but open proxies are a  
source of fraudulent orders, and also competitors spidering e-commerce  
sites for price and availability information.  Making it harder for  
both was an important job - both groups of troublemakers would look  
for a softer target elsewhere.



Andy

Re: TRIP deployment?

[Andy Davidson]

On 24 Nov 2008, at 15:55, Jeremy Jackson wrote:


On Mon, 2008-11-24 at 15:20 +, [EMAIL PROTECTED] wrote:
I'm not sure if this is the right mailing list for this question:  
how widely is TRIP (Telephone Routing over IP [RFC3219]) deployed /  
used in current networks?
http://xconnect.net/ is the big ENUM provider, I think that's the  
method that has gained popularity for VoIP Peering on the signaling  
end.  TRIP sounds like it would be useful for finding QoS routes for  
media streams.


Hi, Jeremy, Cayle, All --

I am regularly involved with SIP interconnect.  There are a number of  
providers of similar Federated/All-call-query-ENUM Multilateral  
Islands, but they do not befit the bilateral interconnect model which  
most people involved with voice interconnect need to follow, so that  
they can manage quality and the commercial properties of individual  
prefixes.  *Some* of the island methods I have seen, perform signaling  
arbitration and media transcoding so that all parties on the island  
can communicate with all other parties, which is worrying to me as one  
of the benefits of end-to-end VoIP is the preservation of wideband  
audio codecs and new signaling features across the call path, compared  
with lowest-common-denominator call routing (just like TDM paths in  
the middle).


I discussed this with Richard Shockey last year and proposed to him an  
out-of-band, trip-like gateway protocol that could express prefixes  
along with all relevant technical and commercial properties between  
telecoms peers.  If the commercial and technical properties fit the  
requirements of the peer, then the prefix is appended to the dialplan  
of the peer (be it via a local ENUM zone or some other prefix/call  
routing method).  The point is that the protocol to communicate  
prefixes and attributes needs to be call routing agnostic.  I did some  
work on this protocol, but don't feel ready to take the document to  
the relevant working groups at this stage, but would welcome feedback  
on it from anyone here who is involved with voice interconnect.


This is a bit layer 7ish, so the thread is possibly reaching a  
conclusion on list, but I really hope it continues off-list.


best wishes
Andy

Re: Peering - Benefits?

[Andy Davidson]

On 31 Oct 2008, at 16:56, Paul Stewart wrote:

Why does the controversy word keep coming up?  You're the third  
personnow to ask if I was trying to provide controversy and for the  
third time, NO I AM NOT.


Hi,

I have no intention of fanning the fire, but I can explain the  
controversy message pretty well.


Bringing a whole new methodology to how an organisation interconnects  
is hugely controversial for most organisations who are not already  
peering.


In my role as a consulting engineer in this field, I most recall  
introducing peering to two 'enterprise' organisations.  Both joined  
exchanges in Europe at a time when their network edge was redesigned  
to support 'better practice' IT.  Both were e-commerce organisations  
who traded directly with the general public, and ran open peering  
policies soliciting sessions with eyeball networks.  At the end of my  
involvement with both, each organisation was peering off a third or so  
of their traffic.


One is still peering and probably peers off more traffic.  The other  
withdrew from peering operations after around six months.  Wearing  
another hat as an IX operator, I can confirm that IXPs do not want  
organisations to join and leave, since most of the IXP costs are front- 
stacked and relate to setup.


So what went wrong ?  The organisation which is still peering has a  
more rich technical culture, willing to accept the so-called  
intangible benefits of peering.  The second asked are we a sales and  
marketing firm designed to shift widgets, or are we a fancy technical  
firm with a big network ?


The culture of many firms is to keep-it-simple-stupid, and if your  
proposal for peering reached C*O levels, then it would be met with  
significant controversy if you are not already peering.  Especially  
when the C*O responsible for legal hears about peering contracts...


Furthermore, to get and retain the peers you need, you need to make  
relationships with other peering co-ordinators.  Attending the peering  
conferences is hard work and all of your colleagues will think you're  
on a jolly !


If you can't get sponsorship for your idea outside the technology  
department, then the idea is probably dead.  Are there some PNIs you  
can run in the local area which will have a significant impact on your  
resiliency and traffic profile ?


Good luck.  I am happy to talk to you in more detail about this  
subject if you would like more advice, drop me a line off-list.


Best wishes
Andy Davidson.

Re: Peering - Benefits?

[Andy Davidson]

On 31 Oct 2008, at 16:56, Paul Stewart wrote:

Why does the controversy word keep coming up?  You're the third  
personnow to ask if I was trying to provide controversy and for the  
third time, NO I AM NOT.


Hi,

I have no intention of fanning the fire, but I can explain the  
controversy message pretty well.


Bringing a whole new methodology to how an organisation interconnects  
is hugely controversial for most organisations who are not already  
peering.


In my role as a consulting engineer in this field, I most recall  
introducing peering to two 'enterprise' organisations.  Both joined  
exchanges in Europe at a time when their network edge was redesigned  
to support 'better practice' IT.  Both were e-commerce organisations  
who traded directly with the general public, and ran open peering  
policies soliciting sessions with eyeball networks.  At the end of my  
involvement with both, each organisation was peering off a third or so  
of their traffic.


One is still peering and probably peers off more traffic.  The other  
withdrew from peering operations after around six months.  Wearing  
another hat as an IX operator, I can confirm that IXPs do not want  
organisations to join and leave, since most of the IXP costs are front- 
stacked and relate to setup.


So what went wrong ?  The organisation which is still peering has a  
more rich technical culture, willing to accept the so-called  
intangible benefits of peering.  The second asked are we a sales and  
marketing firm designed to shift widgets, or are we a fancy technical  
firm with a big network ?


The culture of many firms is to keep-it-simple-stupid, and if your  
proposal for peering reached C*O levels, then it would be met with  
significant controversy if you are not already peering.  Especially  
when the C*O responsible for legal hears about peering contracts...


Furthermore, to get and retain the peers you need, you need to make  
relationships with other peering co-ordinators.  Attending the peering  
conferences is hard work and all of your colleagues will think you're  
on a jolly !


If you can't get sponsorship for your idea outside the technology  
department, then the idea is probably dead.  Are there some PNIs you  
can run in the local area which will have a significant impact on your  
resiliency and traffic profile ?


Good luck.  I am happy to talk to you in more detail about this  
subject if you would like more advice, drop me a line off-list.


Best wishes
Andy Davidson.

Re: Peering - Benefits?

[Andy Davidson]

On 30 Oct 2008, at 13:03, HRH Sven Olaf Prinz von CyberBunker-Kamphuis  
MP wrote:



internet exchanges are not per-se redundant


Those networks who *choose* connect to peers via a single fabric, in a  
single location, will suffer a similar fate to those networks who  
single home to one transit provider.



(the amsix with their many outages and connected parties that rely
primarliy on it's functionality is a prime example here)


I run interconnection for three networks connected to the ams-ix and  
can't understand why you think that the ams-ix fabric has many  
outages - I have found it, to borrow a phrase from another stable  
European IXP, rock solid.



internet exchanges usually are some sort of hobby computer club, you
cannot rely on them to actually -work-,


You shouldn't bet the farm on a single one of anything.  My alarm  
clock failed once, this doesn't mean that all alarm clocks are  
hobbyist timekeeping devices.


Most internet exchanges are professional organisations run by a team  
of experts who care about the operational stability of the platform.   
Most in Europe are association based organisations, who's leaders are  
held accountable for the operational and commercial stability of the  
exchange, to all of the participants, at legally mandated meetings.


Its a shame if your experience at the local IXP has been less  
positive, perhaps look at the procedures and policies of a more sound  
exchange and encourage your local IXP to be run along those lines.


Andy

Re: Another driver for v6?

[Andy Davidson]

On 30 Oct 2008, at 15:47, David W. Hankins wrote:


If someone can't reach the hypothetical A/ www.google.com RRset,
you've just increased your support costs.  My network is slow.
Are you using IPv4 or IPv6? Netscape.


Do you think that industry should be working to some kind of well  
supported / worldwide flag day when lots of popular resources add v6  
records at the same time ?


In the same way that in the UK, appliance manufacturers have been  
educating people about the analogue terrestrial TV switchoff by 2012,  
do you think that we should be advocating a 'internet PLUS day' some  
time in (date plucked from the air) 2014 ?


-a

Re: Atrivo/Intercage: Now Only 1 Upstream

[Andy Davidson]

On 17 Sep 2008, at 18:32, David Ulevitch wrote:

At the end of the day, nobody is going to drop packets for amazon's  
IP space.


I have a customer that sells online, and is dropping stuff from ec2  
today due to abuse.


Andy

Re: Coop Peering Fabric??

[Andy Davidson]

On 12 Aug 2008, at 04:15, Deepak Jain wrote:

A coop, best-effort switch fabric colo'd at a few sites would  
allow participants to peer off traffic at a price of the order of a  
single cross-connect (~$500/month per 10G port is possible, maybe  
less)


Most of the Internet Exchanges in Europe that quickly spring to mind  
as successful, are run as co-operative entities, similar to what you  
describe.


Specifically, most (all?) of the larger ones over here run as  
independent bodies that are owned mutually -- that is to say, owned by  
all of the participators at the exchange.  The model is popular, and  
many hundreds of GB/s of traffic is exchanged on switches run by  
mutual organisations in Europe.


This works really well because it means there is no commercial/profit  
motivation to operate significantly above cost-recovery levels.  Here,  
costs mean the CapEx, OpEx, and any community/member sanctioned  
projects.


Where it breaks is when we have to tell a network with lots of traffic  
that in order to participate at the exchange, they have to become a  
member (part owner) of the organisation.  Due to organisational or  
even regulatory issues, it may not be legal to sell services (exchange  
ports) to non members/owners.  This doesn't frighten the engineer  
asking for a connection, but it causes some concern at C*O level  
(err, I might have to declare this to shareholders/regulators...)


I think my message to you would be that if you have a bunch of  
colleagues at other organisations near you that want to start  
peering ... configure a switch, peer, and take it from there as you  
grow !  I hope your new exchange is successful !



Best wishes
Andy Davidson
Declared hat - www.lonap.net (London, UK based mutual IX)

Re: [Nanog-futures] Bhutan discovers the NANOG Problem...

[Andy Davidson]

On 15 Jul 2008, at 16:45, Mike Hughes wrote:

 People with their laptop open aren't the problem.

My 2[c|p]

I agree with Mike, many engineering staff are only permitted to attend  
the meetings on the basis that operational emergencies can be covered  
during conferences.  Taking the conference wifi away is likely to be  
more disruptive than providing it, and people using it during the  
talks...


It's sad that some people are rude, but some people are.

Andy

___
Nanog-futures mailing list
Nanog-futures@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-futures