Hello,
We've a lot of customers with Cisco 6500 routers (mostly with SUP720
supervisors) in operation. They are very popular with smaller ISPs in
Africa/middle east due to their cheap price on the used marked and
their fully sufficient routing performance for the given tasks. In
practice the bigge
On Wednesday, April 1, 2015, Frederik Kriewitz wrote:
> Hello,
>
> We've a lot of customers with Cisco 6500 routers (mostly with SUP720
> supervisors) in operation. They are very popular with smaller ISPs in
> Africa/middle east due to their cheap price on the used marked and
> their fully suffic
On 1/Apr/15 19:01, Frederik Kriewitz wrote:
>
> We're wondering if anyone has experience with such a setup?
Cisco have a feature called BGP-SD (BGP Selective Download).
With BGP-SD, you can hold millions of entries in RAM, but decide what
gets downloaded into the FIB. By doing this, you can sti
or ignore/block russia and north korea and china network blocks
takes away 5% of network ranges for memory headroom, especially the large
number of smaller china blocks.
Some may say this is harsh but is the network contacts refuse to co-operate
with abuse and 100% of the traffic is bad then why
Do you have data on '100% of the traffic' being bad?
I happen to have a large Chinese clientbase, and this is not the case on
my network.
On 4/2/2015 午後 04:35, Colin Johnston wrote:
or ignore/block russia and north korea and china network blocks
takes away 5% of network ranges for memory head
On 2/Apr/15 09:35, Colin Johnston wrote:
> or ignore/block russia and north korea and china network blocks
> takes away 5% of network ranges for memory headroom, especially the large
> number of smaller china blocks.
> Some may say this is harsh but is the network contacts refuse to co-operate
Of course it's not something you should generalise about all people or
all traffic from certain countries. But it's obvious that there are some
countries which seem to care almost not at all about abuse or maybe even
are sources for planned hack-attempts. And at least some large ISPs
there seem to
On 2/Apr/15 09:52, Stefan Neufeind wrote:
> Of course it's not something you should generalise about all people or
> all traffic from certain countries. But it's obvious that there are some
> countries which seem to care almost not at all about abuse or maybe even
> are sources for planned hack-a
customers are paying for good traffic to generate eye balls and revenue, not
bad traffic which clouds the good work done.
I know we are getting into filtering traffic wars here but if the source admins
refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then
why not put up
> On 2 Apr 2015, at 08:40, Paul S. wrote:
>
> Do you have data on '100% of the traffic' being bad?
>
as a example anything in 163data.com.cn is bad
Colin
> I happen to have a large Chinese clientbase, and this is not the case on my
> network.
>
> On 4/2/2015 午後 04:35, Colin Johnston wrote:
163data is announced as Chinanet, a China Telecom brand.
Dropping 4134 (http://bgp.he.net/AS4134) globally will get my customers
up at my doors with pitchforks fairly fast, I dunno about yours
Simply too big to do anything that drastic against.
On 4/2/2015 午後 05:04, Colin Johnston wrote:
> On 2 Apr 2015, at 08:57, Mark Tinka wrote:
>
>
>
> On 2/Apr/15 09:52, Stefan Neufeind wrote:
>> Of course it's not something you should generalise about all people or
>> all traffic from certain countries. But it's obvious that there are some
>> countries which seem to care almost not at all
On 2/Apr/15 10:00, Colin Johnston wrote:
> customers are paying for good traffic to generate eye balls and revenue, not
> bad traffic which clouds the good work done.
> I know we are getting into filtering traffic wars here but if the source
> admins refuse to respond, refuse to cooperate, then
You would be surprised at the good effect and bandwidth incoming/outgoing
gained.
allow blocks on exception and document and check.
drastic action done due to unresponsive contacts and 100% bad traffic
Colin
> On 2 Apr 2015, at 09:06, Paul S. wrote:
>
> 163data is announced as Chinanet, a Ch
On 2/Apr/15 10:07, Colin Johnston wrote:
> Open ranges as necessary and mention will will reblock if bad traffic seen.
Might be a bit too much work for a customer to figure out when access
will be granted or taken away. Would be for me, if I was your customer.
>
> It is called protect what you
On 04/02/2015 09:57 AM, Mark Tinka wrote:
>
>
> On 2/Apr/15 09:52, Stefan Neufeind wrote:
>> Of course it's not something you should generalise about all people or
>> all traffic from certain countries. But it's obvious that there are some
>> countries which seem to care almost not at all about a
Filtering countries is a bad idea, but it is probably possible to create
filters so 99% of your actual traffic is handled by a relatively small
subset of global routes and the remaining 1% routed via a default route or
via a Linux box.
Anyone know of tools and methods to do this? How effective is
On 2/Apr/15 12:34, Stefan Neufeind wrote:
> Not fully block / null-route of course. You might however consider to
> not allow ssh-logins from certain countries (if you know what you're
> doing) to avoid noise in the logs, might monitor incoming emails with
> smtp-auth for suspicious activity base
>
> Most of the spam I get comes from North America. Go figure. I'm not
> about to cut access to that continent off.
>
> I'd have to consider all other options really exhausted about fixing
> this for myself before I have to go and fix it in the network in a way
> that impacts other customers who
On 2/Apr/15 13:06, Colin Johnston wrote:
> It is not spam we are talking about,...
I'm aware - but someone mentioned it, so it deserved it's on post.
But having said that...
> it is bad invalid network packets, bad web traffic probing exploits, bad
> port traffic looking for open network por
David Barroso's (Spotify) SDN Internet Router [0] comes to mind.
0 - https://github.com/dbarrosop/sir
On 4/2/2015 午後 07:47, Baldur Norddahl wrote:
Filtering countries is a bad idea, but it is probably possible to create
filters so 99% of your actual traffic is handled by a relatively small
subs
Hi Freddy,
As Paul has mentioned, you could check the David's project - SIR, look
at his presentation:
https://www.youtube.com/watch?v=o1njanXhQqM
We've also developed a platform for the BGP monitoring and routing
optimization which could solve your problem. It would inject to the
border routers
Hello!
Very good idea is to sell that and change it to softrouter based on
PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than
$1k.
On 04/01/15 20:01, Frederik Kriewitz wrote:
> We're wondering if anyone has experience with such a setup?
As a network consumer and network provider. The traffic seen by the
customer should not be censored. It should be up to the consumer to protect
their services.
I accept the risk and want uncensored internet access and provide such to
our customers.
On Apr 2, 2015 11:26 AM, "Max Tulyev" wrote:
>
On Thu, 2 Apr 2015, Mark Tinka wrote:
Most of the spam I get comes from North America. Go figure. I'm not
about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse
notifications and sometimes has LEO who will listen.
china is neither.
-Da
yes, china ignores everything said beit by phone,email,chat
at least if you call a us provider you can at least communicate
its not a english language issue either
chinatelcom,chinanet contact info might as well not be documented
colin
Sent from my iPhone
> On 2 Apr 2015, at 19:05, goe...@ani
ng"
> To: "Max Tulyev"
> Cc: nanog@nanog.org
> Sent: Thursday, April 2, 2015 2:01:30 PM
> Subject: Re: BGP offloading (fixing legacy router BGP scalability issues)
>
> As a network consumer and network provider. The traffic seen by the
> customer should not be ce
it is not censorship to check traffic follows correct standards and does not
deliberately constantly try to exploit.
it could easily be solved if china abuse departments co-operate and acknowledge
reports and fix
if not then country bans are in place and will remain in place until culture
change
The essence of this discussion is IMHO a little...um...trite.
Be that as it may how many of you have attempted to contact these
providers in Chinese?
Or do you all have good reason to believe that is never the problem?
On April 2, 2015 at 11:05 goe...@anime.net (goe...@anime.net) wrote:
> On
yes have tried chinese language communication as well.
none of it works, they dont believe bad traffic is a big issue where it has
been proved 100% is bad
we do belive this is due to bad abuse practice not informing customers and also
deliberately sending bad traffic to test exploits on a large s
Sounds there's a need for a higher level of dialogue. Hey, if it can
be done with Iran...
These are identifiable companies not sub-rosa criminal gangs (as we
get with spam) so there ought to be some hope.
On April 2, 2015 at 21:10 col...@gt86car.org.uk (Colin Johnston) wrote:
> yes have tried c
net, nanog@nanog.org
Sent: Thursday, April 2, 2015 3:34:26 PM
Subject: Re: BGP offloading (fixing legacy router BGP scalability issues)
Sounds there's a need for a higher level of dialogue. Hey, if it can
be done with Iran...
These are identifiable companies not sub-rosa criminal gangs
emails to the registered contacts bounce, for one, undeliverable.
which is a bit of a change from the old chinanet auto-responder which
auto-responded to every email with
"i cannot find that IP or that IP not by my Control. Please send the correct
IP".
a number of years back i did have someo
On Wed, Apr 1, 2015 at 1:01 PM, Frederik Kriewitz wrote:
> In
> practice the biggest problem with [Cisco 6500s] is their poor BGP scalability
> due to the CPU/memory limitations.
Hi Frederik:
Are you sure about that? I would expect you to hit the wall on the
TCAM long before CPU/RAM limitations.
I, for one, wouldn't mind seeing more dialog regarding the original poster's
query ...
> On Apr 2, 2015, at 14:53, Barry Shein wrote:
>
>
> The essence of this discussion is IMHO a little...um...trite.
>
> Be that as it may how many of you have attempted to contact these
> providers in Chine
customers are paying for good traffic to generate eye balls and revenue, not
bad traffic which clouds the good work done.
I know we are getting into filtering traffic wars here but if the source admins
refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then
why not put up
On April 2, 2015 at 14:19 goe...@anime.net (goe...@anime.net) wrote:
> a number of years back i did have someone contact in chinese and the
> response was that the customer was doing nothing wrong.
Ok, that's progress of a sort, what's the authoritative source of
right and wrong, something bey
Is port scanning illegal in China?
If not the there is no reason for then to do anything about it.
On 3 Apr 2015 19:00, "Barry Shein" wrote:
>
> On April 2, 2015 at 14:19 goe...@anime.net (goe...@anime.net) wrote:
> > a number of years back i did have someone contact in chinese and the
> > res
On April 3, 2015 at 20:22 baconzom...@gmail.com (Bacon Zombie) wrote:
> Is port scanning illegal in China?
>
> If not the there is no reason for then to do anything about it.
I don't think that's a minimal standard one has to use, illegal or
not.
Management of the internet infrastructure is
portscanning on mass scale where unable to get knowledgable network/sysadmins
to fix gets to the point of every part of large network ranges are affected.
then country blocks make sense to protect countries from armies of exploited
machines and protect valuable costly network resource
colin
Se
china says not a problem since they have head in sand and ignore cooperation
phone contact with chinse folks does not help either
colin
Sent from my iPhone
> On 3 Apr 2015, at 19:51, Barry Shein wrote:
>
>
>> On April 3, 2015 at 20:22 baconzom...@gmail.com (Bacon Zombie) wrote:
>> Is port sca
Gentlemen, be happy
Roderick Beck
Sales Director/Europe and the Americas
Hibernia Networks
http://www.hibernianetworks.com
Budapest and New York
36-30-859-5144
rod.b...@hibernianetworks.com
This e-mail and any attachments thereto is intended only for use by the
addressee(s) named herein and
Can we please get back to the original topic?
So far we have had one interesting and useful suggestion that I've seen -- Paul
S. mentioned SIR https://github.com/dbarrosop/sir
Have I missed any other solutions other than the prefix length filtering?
--Chris
On Fri, 3 Apr 2015, Barry Shein wrote:
On April 2, 2015 at 14:19 goe...@anime.net (goe...@anime.net) wrote:
> a number of years back i did have someone contact in chinese and the
> response was that the customer was doing nothing wrong.
Ok, that's progress of a sort, what's the authoritative sour
On Fri, 03 Apr 2015 13:08:40 -0700, goe...@anime.net said:
> On Fri, 3 Apr 2015, Barry Shein wrote:
> > On April 2, 2015 at 14:19 goe...@anime.net (goe...@anime.net) wrote:
> > > a number of years back i did have someone contact in chinese and the
> > > response was that the customer was doing noth
> ...if not then country bans are in place and will
> remain in place until culture change is done
: I would like country trade talks to get down to the
: technical point that there are some fundamental
: problems being seen with bad traffic usage and it is
: significant percentage of waste
On 04/03/2015 12:18 PM, Chris Boyd wrote:
Can we please get back to the original topic?
Also interested in the original topic.
So far we have had one interesting and useful suggestion that I've
seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir
>
Have I missed any other solution
The SIR approach might not work if your switch does not support selective
installing routes. Also the switch might have a very slow CPU and be memory
constrained, making downloading a large number of routes impractical even
if you do not install all.
IX and transit providers are making this harder
On 2015-04-03 14:18, Chris Boyd wrote:
Can we please get back to the original topic?
So far we have had one interesting and useful suggestion that I've
seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir
Have I missed any other solutions other than the prefix length
filtering?
I
On Fri, 3 Apr 2015, valdis.kletni...@vt.edu wrote:
We've been down this road before - we've had our own problems on this
side of the puddle with transit providers who refused to deal with problem
customers because the provider billed by the packet, and the customers were
good about paying their b
In article you write:
>On Fri, 3 Apr 2015, valdis.kletni...@vt.edu wrote:
>> We've been down this road before - we've had our own problems on this
>> side of the puddle with transit providers who refused to deal with problem
>> customers because the provider billed by the packet, and the customers
On Mon, 6 Apr 2015, John Levine wrote:
In article you write:
On Fri, 3 Apr 2015, valdis.kletni...@vt.edu wrote:
We've been down this road before - we've had our own problems on this
side of the puddle with transit providers who refused to deal with problem
customers because the provider billed
On Mon, Apr 6, 2015 at 2:51 PM, John Levine wrote:
> In article you write:
>>At least in the US the provider could be charged with willful negligence
>>and face liability.
>
> Please provide legal citations.
http://www.americanbar.org/newsletter/publications/gp_solo_magazine_home/gp_solo_magazin
http://www.americanbar.org/newsletter/publications/gp_solo_magazine_home/gp_solo_magazine_index/civilliability.html
Nothing there about ISP liability other than noting the third-party
immunity from the CDA.
https://www.ftc.gov/news-events/press-releases/2009/06/ftc-shuts-down-notorious-rogue
Please provide legal citations.
ignore a dmca takedown request, see what happens.
I know people who have ignored lots of DMCA notices. Of course, it was
pretty clear that the notices were bogus.
R's,
John
Hi Frederik,
> On 09 Apr 2015, at 13:24, Frederik Kriewitz wrote:
>
> Thank you very much for all your responses.
>
> First of all, the problems we see are really RIB (Processor memory)
> and CPU related.
> The TCAM/FIB limits are properly configured. From the FIB capacity
> view they should la
Thank you very much for all your responses.
First of all, the problems we see are really RIB (Processor memory)
and CPU related.
The TCAM/FIB limits are properly configured. From the FIB capacity
view they should last a couple of more years. Software routing doesn't
cause the problem.
The most ext
Freddy, did you get your test up ?
I too am facing the same BGP scalability constraints as you are, and the only
real viable solution seems to be filtering.
I'll probably will setup a small test environment to see if this
actually works as expected.
Best Regards,
Freddy
On Mon, May 11, 2015 at 8:38 PM, Chaim Rieger wrote:
> Freddy, did you get your test up ?
Finally had some time to setup a lab environment and do some basic
testing regarding the fully transparent approach mentioned in the
initial email.
My biggest concern was that the cisco wouldn't like packets
59 matches
Mail list logo
