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
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
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
On 2 Apr 2015, at 08:40, Paul S. cont...@winterei.se 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
It's close to Sydney, 203.18.241.0/24
What's the reason, there are some telecoms,isp that have paths
eastbound, southbound but in routing table they prefer longer path via US ?
regards,
Piotr
W dniu 2015-04-02 o 01:45, Matt Perkins pisze:
Some times you can get luck and go through
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So back in 2012 there was some discussion on DHCPv6 and the
challenge of using a DUID in a dual-stack environment where
MAC-based assignments are already happening though an IPAM.
Have a look at https://dhcpy6d.ifw-dresden.de, our MAC address
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
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
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:
piotr.1...@interia.pl (Piotr) wrote:
What's the reason, there are some telecoms,isp that have paths eastbound,
southbound but in routing table they prefer longer path via US ?
Come on - you do know that it's called policy routing for a reason?
Costs, reserved bw/s for high-rollers,
I've been trying to get an answer from Juniper on this for months. Most of the
responses have been something to the effect of I have no idea what you are
talking about.
I recently got an answer of Juniper has no plans to support that.
I am responsible for several small ISPs' networks, and if
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
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
On 2 Apr 2015, at 08:57, Mark Tinka mark.ti...@seacom.mu 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
Hi
Tried exactly same. Note: it's ae18 and ae20 on EX side and reth4 on SRX
side.
Initially worked but when I took down ae18, i.e ae18 is disabled, now on
ae20 I am getting:
show interfaces ae20
Physical interface: ae20, Enabled, Physical link is Up
Interface index: 533, SNMP ifIndex: 924
If you fix that, I think you deserve an award of some kind. You sir, will have
won the Internet.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
- Original Message -
From: Barry Shein b...@world.std.com
To: Colin Johnston col...@gt86car.org.uk
Cc:
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
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
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
Macsec use cases are valid when working with hop by hop encryption needs
between closets / buildings where structured wiring is not within control of
agency personnel, in the case of other states we provide consulting services
to, think multi tenant building with shared closet from other
On Wed, Apr 1, 2015 at 1:01 PM, Frederik Kriewitz frede...@kriewitz.eu 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
I, for one, wouldn't mind seeing more dialog regarding the original poster's
query ...
On Apr 2, 2015, at 14:53, Barry Shein b...@world.std.com 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
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
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 may
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 based
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
Due to the enterprise market demand on DDoS protection solutions - which
was initiated by a DDoS vendor, all operators in my country are trying to
deploy their solution as fast as they can.
As a result to the recent vendor's competition in DDoS protection, the
detection/mitigation time can be
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
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
Will take a lot of water to clear this up if gone into main tunnels :(
Colin
http://www.bbc.co.uk/news/uk-england-london-32157618
http://www.bbc.co.uk/news/uk-england-london-32157618
Holborn fire is still burning under the pavement
Local road closures are in place but Holborn Tube
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 abuse or
This reminds me that we have switches that will tag DHCPv6 packets with the
equallent to option 82 however ISC-DHCP has no support for it. The switch
will create a DHCP packet with two options, one being the user info and the
other is encapsulating the original packet. ISC-DHCP will pick the
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
I've started to get some message today from google claiming that my
computer or network was sending automated queries, and they are blocking me.
I'm not sending automated queries, Ive logged all of my outbound traffic
and there is only my browser traffic going to google.
I'm not responsible
Dumb question. So this is essentially physical or link layer encryption. That’s
fine out on the wire, but is decrypted in memory (if I understand what you
said), and requires point to point connectivity to be any better than that. Are
you aware of anyone at NIST or other places suggesting end
Putting the EXs in a VC and splitting your AEs across the 2x VC members
takes care of that.
EXVC (ae1) Two Patches to SRX0 (reth1)
EXVC (ae2) Two Patches to SRX1 (reth1)
...where EXVC is a VC composed of EX0 and EX1, and ae1 and ae2 both have
one member interface from each VC member.
On 4/2/15 10:08 AM, McDonald Richards wrote:
If you want a direct path then SMW3 remains the only cable for the final
leg from Singapore to Perth and it's capacity is only a few hundred
gigabits. There are at least 2 proposed new systems racing to get into
the water between Singapore and Perth
Does anyone have previous experience meeting IRS requirements for the encrypted
transmission of FTI across a LAN and WAN, specifically the requirements called
for in IRS Publication 1075?
The IRS tests for the following:
All FTI data in transit is encrypted when moving across a Wide Area Network
On Wed, 01 Apr 2015 19:51:54 +0300
Mohamed Kamal mka...@noor.net wrote:
The setup will be inline. So it would be great if anyone have done
this before and can help provide the appropriate tools, advices, or
the testing documents for efficient PoC.
Hi Mohamed,
We recently introduced a
Hi
I thought cross chassis lag is supposed by the use of reth bundled at SRX
end. I read this is basically the major difference in reth Vs ae bundle in
SRX.
Interesting factor here is that ae bundles can spread across multiple EX
chassis in a virtual chassis environment but this cannot be the
Hello Pavel,
I'm certainly biased to the open-source tools if they do the job
required, and I appreciate your effort exerted on this project. However,
based upon what I saw under the features list of your tool, I assume
that it can detect only volumetric DDoS attacks based upon anomalies
such as
In:
EX0 (ae1) Two Patches to SRX0 (reth1)
EX1 (ae2) Two Patches to SRX1 (reth1)
with:
that if one EX goes down then I cannot make use of other corresponding
SRX.
Do you mean that e.g. if SRX0 is the chassis cluster primary and EX0 goes
down, then you can't use SRX0, but you
You should include Radware on that list .
- Reply message -
From: Mohamed Kamal mka...@noor.net
To: NANOG nanog@nanog.org
Subject: PoC for shortlisted DDoS Vendors
Date: Wed, Apr 1, 2015 9:51 AM
In our effort to pick up a reasonably priced DDoS appliance with a
competitive features,
Handy Networks in Denver have a pretty decent footprint, good people too.
http://www.handynetworks.com/
On Mar 27, 2015, at 3:40 PM, Mike Hammett na...@ics-il.net wrote:
So in Denver Comfluent\CoreSite seems to be the place to be... except as
someone that predominately serves eyeball
You should include Radware on that list .
- Reply message -
From: Mohamed Kamal mka...@noor.net
To: NANOG nanog@nanog.org
Subject: PoC for shortlisted DDoS Vendors
Date: Wed, Apr 1, 2015 9:51 AM
In our effort to pick up a reasonably priced DDoS appliance with a
competitive features,
It's my understanding that a cross chassis LAG is not supported. If there is a
way, I'm not aware of it. I'm running the same set up as your working example
in my locations and for now, this suits my requirements.
Sent from my iPhone
On Apr 2, 2015, at 07:12, Anurag Bhatia
On 2/Apr/15 16:23, Jared Mauch wrote:
I think this stability is key, I’ve been watching a testing team go round and
round with a telco that seems to think that 1 second hits is acceptable
through
this area and they are unwilling to resolve it and seem to be begging “please
just accept the
On Apr 2, 2015, at 10:27 AM, Mark Tinka mark.ti...@seacom.mu wrote:
On 2/Apr/15 16:23, Jared Mauch wrote:
I think this stability is key, I’ve been watching a testing team go round and
round with a telco that seems to think that 1 second hits is acceptable
through
this area and they
On 2/Apr/15 16:32, Jared Mauch wrote:
Seeing multiple hit times within a 24h period isn’t really acceptable and
keeps
these paths from being viable.
Agreed.
They are claiming they are within 50ms.
Which makes sense if the end-to-end path is less than 50ms re: seeing
hitless failovers on
There's a new AAE-1 cable currently being laid (sunk!) that comes online
early 2016 that will help. But right now alot of traffic cuts across the US
as it's still the 'best' route for reasons other that latency as others
have already mentioned.
The new AAE-1 will have 40Tbps connections from
On Apr 2, 2015, at 10:15 AM, Martin Hepworth max...@gmail.com wrote:
The new AAE-1 will have 40Tbps connections from Europe to Hong Kong so
hopefully the routes will start to migrate in 2016 and give us an Easterly
route to APAC that has enough capacity to be stable in that direction
I
On Thu, Apr 02, 2015 at 10:43:25AM +0200, Elmar K. Bins wrote:
piotr.1...@interia.pl (Piotr) wrote:
What's the reason, there are some telecoms,isp that have paths eastbound,
southbound but in routing table they prefer longer path via US ?
Come on - you do know that it's called policy
Hello!
What about open source alternatives? Main part of commercial ddos filters
are simple high performace firewalls with detection logic (which much times
more stupid than well trained network engineer).
But attacks for ISP is not arrived so iften and detection part coukd be
executed manually
Hello everyone!
I have got two Juniper EX series switches (on virtual chassis) and two SRX
devices on native clustering.
I am trying to have a highly available redundancy between them with atleast
2Gbps capacity all the time but kind of failing. I followed Juniper's
official page here
If you want a direct path then SMW3 remains the only cable for the final
leg from Singapore to Perth and it's capacity is only a few hundred
gigabits. There are at least 2 proposed new systems racing to get into the
water between Singapore and Perth to try and address this gap in supply and
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?
Low latency routes like this would be very attractive to financial firms
trading in both Europe and Asia. My hunch is that most of these circuits are
linear - unprotected. And if you get damage in Siberia or Northern China
repairs could be mighty slow.
Roderick Beck
Sales Director/Europe and
Hi
Yes,
Since SRX0 connected to EX0 and SRX1 connected to EX1 (only). Thus either
pair - 0 will work or pair - 1 will work. I wish if criss crossing worked
then failure of one EX would have still made both SRX available.
In current worst case scenario - failure of EX0 and SRX1 can cause
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
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,
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.
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
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
I just want to confirm your setup.
The criss-cross setup you were describing is different from what I
described.
You listed:
EX0 (ae1) Two Patches to SRX0 (reth1)
EX0 (ae1) One patch to SRX1 (reth1)
EX1 (ae2) Two Patches to SRX1 (reth1)
EX1 (ae2) One patch to SRX0 (reth1)
64 matches
Mail list logo
