On 15/10/2007, at 12:05 AM, Simon Lyall wrote:
As for where the Blackboxes will be used, It'll be where companies
want
servers in place in weeks or months and existing datacenters are
full or
in the wrong place. Think of a building full of people processing
insurance claims in India or
On 10/14/07, Iljitsch van Beijnum [EMAIL PROTECTED] wrote:
On 14-okt-2007, at 19:34, Martin Hannigan wrote:
Is this a configurable option for the inverse behavoir? Seems to me
that it should be since it affects the user experience and sets policy
for the network. It just may be, but I
On Fri, October 12, 2007 10:08 pm, Mark Foster wrote:
Its all very well for those that know better to carry on like this, but I
would suggest that those sortsa complaints only come from people who
don't know better. They don't know how to interpret their Firewall
warnings. And they don't
On 15-okt-2007, at 7:09, Bradley Urberg Carlson wrote:
There is a customer's customer who is advertising more-specifics at
the IX (and using a different source AS, to boot). I can think of
a couple ways to prevent hearing these, but thought I should ask
for suggestions first.
What
On 15/10/2007, at 8:24 PM, Martin Hannigan wrote:
[moresnip]
The way I read the portion of the thread related to resolver behavoir
was that the resolver behavior was being discussed. Not the client.
The resolver should have an attribute to select the preference between
A vs. . Otherwise,
Hi
first of all I kinda picked the thread mid stream so apologies if what
is here has been dealt with by others
As an ISP if I receive a complaint of what may be illegal activity
coming from a customer on my network I can respond to the complaint
and say I will look into it but what action
On 15-okt-2007, at 11:50, Nathan Ward wrote:
The way I read the portion of the thread related to resolver behavoir
was that the resolver behavior was being discussed. Not the client.
The resolver should have an attribute to select the preference
between
A vs. . Otherwise, it's setting
In article [EMAIL PROTECTED] you write:
On 15/10/2007, at 8:24 PM, Martin Hannigan wrote:
[moresnip]
The way I read the portion of the thread related to resolver behavoir
was that the resolver behavior was being discussed. Not the client.
The resolver should have an attribute to select
Am 15.10.2007 um 07:09 schrieb Bradley Urberg Carlson:
I have a few customers' customers, who appear at a local IX. Due
to the MLPA-like nature of the IX, I hear their prefixes both at
the IX and via my own transit customers. I normally use localpref
to prefer customer advertisements
On Oct 15, 2007, at 7:41, Wolfgang Tremmel [EMAIL PROTECTED]
cix.net wrote:
Am 15.10.2007 um 07:09 schrieb Bradley Urberg Carlson:
I have a few customers' customers, who appear at a local IX. Due
to the MLPA-like nature of the IX, I hear their prefixes both at
the IX and via my
The problem is you're announcing the aggregate prefixes of your customer's
customers to your upstream providers and the traffic from your upstreams to
those networks will be routed through the IX (instead of your customer
connection) because of the longer prefix effect and so you're not charging
On 15 Oct 2007, at 13:33, John Payne wrote:
To answer the OP's question I'd be looking at manually filtering
the more specifics if they are also sending the aggregates through
the IX.
The customer's customer is still going to see *your* routes via the
MLP, unless (without knowing what
On Mon, Oct 15, 2007, Wolfgang Tremmel wrote:
I have a few customers' customers, who appear at a local IX. Due
to the MLPA-like nature of the IX, I hear their prefixes both at
the IX and via my own transit customers. I normally use localpref
to prefer customer advertisements over
On Mon, 15 Oct 2007, Bradley Urberg Carlson wrote:
I have a few customers' customers, who appear at a local IX. Due to
the MLPA-like nature of the IX, I hear their prefixes both at the IX
and via my own transit customers. I normally use localpref to prefer
customer advertisements over
On Oct 15, 2007, at 9:48 AM, Mike Leber wrote:
On Mon, 15 Oct 2007, Bradley Urberg Carlson wrote:
I have a few customers' customers, who appear at a local IX. Due to
the MLPA-like nature of the IX, I hear their prefixes both at the IX
and via my own transit customers. I normally use
* Steve Bertrand:
Anyway, if you've got a customer account that was created with a stolen
credit card, and you get complaints about activity on that account from
various parties, and you still don't act, this shows a rather
significant level of carelessness.
Further to carelessness, this
On 10/15/07, Mark Andrews [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you write:
On 15/10/2007, at 8:24 PM, Martin Hannigan wrote:
[moresnip]
The way I read the portion of the thread related to resolver behavoir
was that the resolver behavior was being discussed. Not
I don't believe it is, it may be, sorry if it is ;-)
Does anyone have any real world experience with IDS gear from TopLayer? If so
could you contact me off-list with your comments/suggestions?
We're looking at some IDS / DDOS mitigation gear. Any suggestions from folks
who have already
In article [EMAIL PROTECTED] you write:
On 10/15/07, Mark Andrews [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you write:
On 15/10/2007, at 8:24 PM, Martin Hannigan wrote:
[moresnip]
The way I read the portion of the thread related to resolver behavoir
was that the
at nanog san jose, steve bellovin presented a simple proposal for bgp
tcp/md5 re-keying. it is now rfc 4808 Key Change Strategies for
TCP-MD5. this allows us to install and/or roll keys without disturbing
the bgp session. and it is trivial for vendors to implement and for
operators to use.
It's hard to believe that it has already been 9 years.
http://www.postel.org/postel.html
http://www.isoc.org/postel/index.shtml
indeed
and abha is saturday
randy
I think the better approach is to not purchase one but to do a lease so
that the hardware stays refreshed and keeps up with technology. I'm not
sure if they've got a service model for doing the leases but would be a
great way to go for large organizations where you can pay a fee to have them
on
23 matches
Mail list logo
