On 20 Jun 2016, at 9:13, Mark Tinka wrote:
>> Telecity Manchester (UK), now Equinix Manchester, have charged MRC for
>> internal cabling since forever (in my case, forever being 2001 when I
>> first became customer).
>> They normally run their cables through their switches but when the
>>
http://exa.net.uk/about/contact-us
On 17 Jun 2016, at 17:50, Dave Temkin wrote:
And with Equinix buying Telecity, how long until we see US-style XCs
in
Europe?
Telecity Manchester (UK), now Equinix Manchester, have charged MRC for
internal cabling since forever (in my case, forever being
Hey!
New message, please read <http://akijukido.com/spite.php?eb6p6>
Thomas Mangin
Hello Randy,
The current configuration parser is currently progressive: what exists
when the neighbor is created (or in the neighbor group) is what will be
associated (which is not really ideal) hence why I have passed the last
three weeks totally rewriting it in view of version 4.0. This is
Hello Pavel,
Using ExaBGP as an SDN already has been done (and in a very large
scale). But I would agree with Nick; It is not something I would
recommend to everyone.
Once more to echo Nick, to add/remove route/fw entries on Linux please
do use netlink. The lastest ExaBGP master has some
Hello,
Because :
- Exa has been under attack way too much these last weeks
- We hate to have to deal with it
Because:
- Andrisoft seems cool but does not do FlowSpec
- Arbor is known for its price (and features)
- I am from Yorkshire (How much do you pay me to find bugs in your shinny
Fell free to contact me if you have any questions about ExaBGP as I am
painfully aware it's documentation is nowhere near what it should be.
Thomas
Sent from my iPad
On 23 Aug 2012, at 08:52, Andy Davidson a...@nosignal.org wrote:
On 22 Aug 2012, at 18:42, David Hubbard
On 23 Aug 2012, at 15:04, Raymond Burkholder r...@oneunified.net wrote:
To expand the opinion set, how do Quagga, Bird, exaBGP, OpenBGPd hold up for
handling Multi-Protocol BGP Route Reflector duties in a BGP/MPLS environment
for a smaller ISP?
I am using BIRD as a RR between a busy VRF and
On 16 May 2012, at 00:01, Tom Hill wrote:
I've been itching to try Freeswitch ever since I read this:
http://www.freeswitch.org/node/117
Using FreeSwitch to provide trunk services for nearly a year. Very happy with
it. Just does what it says on the tin.
Currently installing a CudaTel as our
I (in the UK) had the same letter from LLNW yesterday, word for word.
When the peering was established, I had transit providers with strict peering
policy (TATA/L3), now I have two with more open policy (HE/KPN). I assume LLNW
now sees me via what is for them a peer, and see no financial
Hi Fredy,
On 30 Mar 2012, at 22:48, Fredy Kuenzler wrote:
Now, obviously, the French regulator sees the trouble and trys to understand
and 'regulate' it the way they do it usually. From our perspective certainly
not a good way, but why blaming the regulator? Blame those which made it all
On Dec 8, 2010, at 10:10 PM, Thomas Mangin wrote:
Until this is sorted I believe flowspec will be a marginal solution.
We're seeing a significant uptick in flowspec interest, actually, and S/RTBH
has been around for ages.
Great to hear :)
But my point is still valid [...]
After
On 6 Dec 2010, at 15:34, David Ulevitch wrote:
On Mon, Dec 6, 2010 at 6:10 AM, Patrick W. Gilmore patr...@ianai.net wrote:
On Dec 6, 2010, at 4:07 AM, Jonas Frey (Probe Networks) wrote:
Besides having *alot* of bandwidth theres not really much you can do to
mitigate. Once you have the
A less common action is to use flowspec (if you have some Juniper gear) to drop
only the attack and hopefully not any legitimate traffic.
What is really missing atm is a way to filter flowspec announcements (limit the
number and make sure they are for routes the peer is announcing). Until this
On 8 Dec 2010, at 15:12, Dobbins, Roland wrote:
On Dec 8, 2010, at 10:10 PM, Thomas Mangin wrote:
Until this is sorted I believe flowspec will be a marginal solution.
We're seeing a significant uptick in flowspec interest, actually, and S/RTBH
has been around for ages.
Great to hear
On 8 Dec 2010, at 15:40, Dobbins, Roland wrote:
On Dec 8, 2010, at 10:36 PM, Thomas Mangin wrote:
If you are a smaller network, you need the filtering to be performed by your
transit provider, as your uplink will otherwise be congested.
Actually, most DDoS attacks aren't link-flooding
FYI
Begin forwarded message:
From: Pascal Gloor pascal.gl...@spale.com
Date: 8 September 2010 11:25:18 GMT+01:00
To: swi...@swinog.ch swi...@swinog.ch
Subject: [swinog] IP address are now personal data
Dear community,
something important for us happened today that may have some impact
Apart from one big vendor most BGP speaker only send KEEPALIVES when they
need to. So on my full feeds I see sessions running for more then 1 month
which received less then 300 KEEPALIVE packets.
The negociaged holdtime is always the lower value presented between two
routers. The default
On Mon, 2010-08-30 at 10:58 +0200, Thomas Mangin wrote:
http://www.faqs.org/rfcs/rfc4271.html section 4.2
So unless you know something I don't, I believe you are totally mistaken :)
updates serve as implicit keepalives.
Rule #1 do not post when you are not awake yet and quote the text
It seems that creating a worst case BGP test suite for all kinds of nastiness
(in light of the recent RIPE thing) might not be a bad idea - so that we can
all test the implementation ourselves before we deploy new code.
Normally those things are done by vendors - that what we pay them good
It would seem to me that there should actually be a better option, e.g.
recognizing the malformed update, and simply discarding it (and sending the
originator an error message) instead of resetting the session.
Resetting of BGP sessions should only be done in the most dire of
circumstances,
I'm assuming that they weren't really expecting this to cause issues... Where
does one draw the line? I'm planning on announcing x.y.z.0/20 later in the
week -- x, y and z are all prime and the sum of all 3 is also a prime. There
is a non-zero chance that something somewhere will go flooie,
On 28 Aug 2010, at 08:56, Randy Bush wrote:
imiho, researchers injecting data into the control plane are responsible
to have tested it at least against major bgp speakers. and, considering
its placement in the net (big core), i consider ios xr to be a major
speaker.
i suspect that these
Quagga is even worse that Cisco when it comes to packet validation but it
should not surprise anyone :p
To substantiate my claim, my mercurial log tells me that for MPRNLRI and
MPURNLRI having the flag set as Transitive instead of Optional did not cause
Quagga to complain. It just took the
Those tools are not suitable for regression testing ( I know I wrote exabgp )
not saying they could not be adapted though.
Fizzing may return crashes or issues with the daemon but it is unlikely. You
need predictable input for regression testing and in our particular case how do
you detect a
Ytti s...@ytti.fi wrote:
On (2010-08-28 13:23 +0200), Thomas Mangin wrote:
Those tools are not suitable for regression testing ( I know I wrote exabgp
) not saying they could not be adapted though.
Fizzing may return crashes or issues with the daemon but it is unlikely. You
need
We had ASN4, AS-PATH and this one. More or less we hit this session reset
problem once a year but nothing was done yet to change the RFC.
So I am to blame as much as every network engineer to not have pushed for a
change or at least a comprehensive explanation on the session teardown
behaviour
I agree correctly framed invalid packet should be discarded without tearing
the session down.
This statement is way to simplistic.
I would be interested if anyone has pointers toward any work which was done to
sort this issue.
Thanks.
Thomas
Looking at the graph of at least one of the european exchange where RIS
connect, it had an impact. Now saying it was nothing is like saying that the
YouTube incident was nothing as you were not affected as you do not use YouTube.
Some people did feel the pain - lucky it was not you :)
Thomas
On 27 Aug 2010, at 19:27, Grzegorz Janoszka wrote:
On 27-08-10 19:31, valdis.kletni...@vt.edu wrote:
On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said:
Havent seen a thread on this one so thought i'd start one.
Ripe tested a new attribute that crashed the internet, is that true?
If it
So much for better left off public mailing lists ! sigh !
Thomas
On 27 Aug 2010, at 19:42, Lucy Lynch wrote:
FYI:
--
Dear Colleagues,
On Friday 27 August, from 08:41 to 09:08 UTC, the RIPE NCC Routing
Information
On 27 Aug 2010, at 20:03, Grzegorz Janoszka wrote:
On 27-08-10 20:41, Thomas Mangin wrote:
I think most of the impact was limited to Europe, especially Amsterdam area.
Yes, It had an effect on ISPs which are connected to RIS.
http://www.ripe.net/ris/
AFAIK this mean ASes at LINX and AMS-IX
During the discussion, a developers of Bird said that their filtering code
_may_ still have bugs (when performing community based filtering).
Someone rightly pointed to me that the commenter was not a BIRD developer .. my
mistake sorry.
I will recall my statement until I can watch to the
Quagga does not really behave well with lots of peers (lots 200), but
there will be an optimized route server version soon.
This was discussed today at Linx 68. Linx is very pleased with Bird - they
could not get Quagga working due to load issues.
With large numbers of peers, the update
http://www.uknof.org.uk/uknof15/
Has quite a few talk about Quagga/Bird as they are used as route servers in
Europe.
For a route server use, BGP under very high number of peers, it seems bird now
behave better than anything else.
so for normal use, it would seems that whatever you pick will
Hi,
I juste added some preliminary support for FlowSpec (RFC5575) to my BGP route
injector http://bgp.exa.org.uk/
As I am not aware of any other project allowing to inject flow route into a
network, I am taking the liberty to plug it here.
You can access the SVN repository at:
36 matches
Mail list logo
