And at the end of the day it's commercial, vendors pay, I don't trust much.
I am looking for hands-on experience
Ramy
>
> Message: 8
> Date: Thu, 27 Aug 2015 16:00:10 +
> From: Steve Mikulasik
> To: "nanog@nanog.org"
> Subject: RE: DDoS appliances reviews needed
> Message-ID:
>
Hi,
Diverse-path will only send the second best path, and in my case I have
three routes not two. In addition to that, every PE will have to peer
with the RR via a second session (on the same RR, as I will not deploy a
new standalone shadow RR) and this will increase the BGP sessions to the
d
Hello,
For those than run Internet connected routers, how do you get your NetFlow data
from the routers to your collectors? Do you let the flow export traffic use the
same links as your customer traffic to route back to central collectors? Or do
you send this traffic over private network manage
On 1 Sep 2015, at 22:33, Serge Vautour wrote:
Or do you send this traffic over private network management type path?
This is how to do it.
So in case of a network partition event, you don't end up losing
visibility into your network traffic when you need it the most.
You should already hav
On 1/Sep/15 17:33, Serge Vautour wrote:
> Hello,
>
> For those than run Internet connected routers, how do you get your NetFlow
> data from the routers to your collectors? Do you let the flow export traffic
> use the same links as your customer traffic to route back to central
> collectors? O
On 1 Sep 2015, at 22:39, Mark Tinka wrote:
> Have been doing so for years, no major drama.
Until there is.
;>
---
Roland Dobbins
Roland is correct. With the caveat that your Internet customer traffic may flow
over the fibers as your separate management circuits. You should aim for end to
end physical diversity. This is all common sense, but laziness some times takes
precedence.
Roderick Beck
Sales - Europe and the Amer
It's usually not laziness, it's most often related to cost.
On Sep 1, 2015 12:00 PM, "Rod Beck" wrote:
> Roland is correct. With the caveat that your Internet customer traffic may
> flow over the fibers as your separate management circuits. You should aim
> for end to end physical diversity. This
On Tue, Sep 01, 2015 at 08:33:42AM -0700, Serge Vautour wrote:
> For those than run Internet connected routers, how do you get your
> NetFlow data from the routers to your collectors? Do you let the flow
> export traffic use the same links as your customer traffic to route
> back to central collect
On 1 Sep 2015, at 23:10, Job Snijders wrote:
> To answer your first question: i see no issue in transporting flow
> export traffic over the same backbone used to serve customer traffic.
This is not good advice, for the reasons I stated previously in this thread.
-
Zero rating is not a new concept. It has existed in the mobile world since the
days of the dumb phone. Got a reference to why this was killed by the
regulator in Canada?
Mobile networks typically use their packet core (and prior iterations of the
same termination, rating, billing, management
On Tue, Sep 1, 2015 at 12:14 PM, Roland Dobbins wrote:
> On 1 Sep 2015, at 23:10, Job Snijders wrote:
>
> > To answer your first question: i see no issue in transporting flow
> > export traffic over the same backbone used to serve customer traffic.
>
> This is not good advice, for the reasons I s
On 2 Sep 2015, at 0:08, Steve Meuse wrote:
Your advice is not "one size fits all".
Actually, it is.
Large backbone networks have DCNs/OOBs, and that's where they export
their NDE.
I've done netflow over production links for two very large backbone
networks.
Did you manage your routers an
On 15-09-01 12:36, Christian Kuhtz wrote:
> Zero rating is not a new concept. It has existed in the mobile world since
> the days of the dumb phone.
Yes, but is now in a different scale and when you start to zero rate
content that comes from CDN (aka: many IPs which may also serve non zero
rated
Roland,
While your way may be best practice, sometimes real life gets in the way
of best practice.
Shane
On 9/1/15 1:12 PM, Roland Dobbins wrote:
On 2 Sep 2015, at 0:08, Steve Meuse wrote:
Your advice is not "one size fits all".
Actually, it is.
Large backbone networks have DCNs/OOBs,
* rdobb...@arbor.net (Roland Dobbins) [Tue 01 Sep 2015, 19:13 CEST]:
Running flow telemetry in-band is penny-wise and pound-foolish, for
networks of any size, in any circumstances.
You're just wrong here.
-- Niels.
On 2 Sep 2015, at 0:18, Niels Bakker wrote:
You're just wrong here.
Sorry, I'm not. I've seen what happens when flow telemetry is 'squeezed
out' by pipe-filling DDoS attacks, interrupted by fat-fingers, etc.
It'll happen to you, one day. And then you'll understand.
--
So in your world, the money always exists for a separate flow telemetry
network?
On 9/1/15 1:29 PM, Roland Dobbins wrote:
On 2 Sep 2015, at 0:18, Niels Bakker wrote:
You're just wrong here.
Sorry, I'm not. I've seen what happens when flow telemetry is
'squeezed out' by pipe-filling DDoS a
Inline..
On Sep 1, 2015, at 10:13 AM, Jean-Francois Mezei
mailto:jfmezei_na...@vaxination.ca>> wrote:
On 15-09-01 12:36, Christian Kuhtz wrote:
Zero rating is not a new concept. It has existed in the mobile world since the
days of the dumb phone.
Yes, but is now in a different scale and whe
On 2 Sep 2015, at 0:32, Shane Ronan wrote:
So in your world, the money always exists for a separate flow
telemetry network?
It should've already been spent for an OOB/DCN network, which should've
been provisioned with flow telemetry in mind.
---
Roland Dobbin
I think the key here is that Roland isn't often constrained by
these financial considerations.
I would respectfully disagree with Roland here and agree with
Job, Niels, etc.
A few networks have robust out of band networks, but most
I've seen have an interesting mixture of
* rdobb...@arbor.net (Roland Dobbins) [Tue 01 Sep 2015, 19:30 CEST]:
On 2 Sep 2015, at 0:18, Niels Bakker wrote:
You're just wrong here.
Sorry, I'm not. I've seen what happens when flow telemetry is
'squeezed out' by pipe-filling DDoS attacks, interrupted by
fat-fingers, etc.
This is the
On 15-09-01 13:35, Christian Kuhtz wrote:
> There is no red flag from a regulatory perspective based on the technology
> itself in my opinion.
There are other sections in the Canadian Telecommunicatiosn Act about
controlling content. And there was a reference to the supreme court on
whether ISP
Looking at probably 100 networks' flow paths over the last year,
I'd say 1 or 2 have OOB for flow.
Maybe another 10-20 have interest in taking simpler time series
data of top talkers over their OOB networks, but not the flow
itself.
Agree w Roland that it can cause problems with telemetry if
the
The regulatory killing of that was probably unrelated to implementation.
The regulators probably objected to the mobile provider creating an advantage
(no data charges) for their own service against competing video services that
would incur data charges.
Perhaps that will help you understand wh
On 15-09-01 14:19, Owen DeLong wrote:
> The regulatory killing of that was probably unrelated to implementation.
Demonstrating that the Mobile TV packets traveled in exactly the same
way as any other packets over the Bell Mobility network was a large part
of the decision. When packets travel undif
On 9/1/15, 1:36 PM, "NANOG on behalf of Roland Dobbins"
wrote:
>It should've already been spent for an OOB/DCN network, which should've
>been provisioned with flow telemetry in mind.
I'm going to interpret that "should" in the same way as the MUST in
RFC6919. :-)
Yes, it's a good practice, but
hey,
It should've already been spent for an OOB/DCN network, which should've
been provisioned with flow telemetry in mind.
Bad advice. No amount of money will fix major platforms that are not
happy to export flow telemetry via router management ports. Sometimes it
can be done via nasty vrf l
On Tue, 01 Sep 2015 22:47:09 +0300, Tarko Tikan said:
> hey,
>
> > It should've already been spent for an OOB/DCN network, which should've
> > been provisioned with flow telemetry in mind.
>
> Bad advice. No amount of money will fix major platforms that are not
> happy to export flow telemetry via
In a message written on Wed, Sep 02, 2015 at 12:29:25AM +0700, Roland Dobbins
wrote:
> On 2 Sep 2015, at 0:18, Niels Bakker wrote:
> > You're just wrong here.
>
> Sorry, I'm not. I've seen what happens when flow telemetry is 'squeezed
> out' by pipe-filling DDoS attacks, interrupted by fat-fing
On Tue, 01 Sep 2015 22:47:09 +0300, Tarko Tikan said:
Bad advice. No amount of money will fix major platforms that are
not happy to export flow telemetry via router management ports.
Correct. And for a proper network you may not wish to have those
connections from in-band ports to your OOB/ma
I’m looking for some advice/input from people either public or private about
woes building fiber to reach people outside the footprints of the existing
incumbents.
There is a group of people looking to organize private fiber to reach areas
that are unserved.
There’s been recent local people do
On 01/09/2015 21:13, valdis.kletni...@vt.edu wrote:
> On Tue, 01 Sep 2015 22:47:09 +0300, Tarko Tikan said:
>> Bad advice. No amount of money will fix major platforms that are not
>> happy to export flow telemetry via router management ports.
>
> And that box ended up in your rack, why exactly?
>
Agree. Most OOB is lacking redundancy too, so a single failure can really take
the shine off an OOB deployment. Especially when you've put your management
traffic on it, including radius traffic, and you're using 802.1X. Found that
out the hard way a few years ago.
Chuck
-Original Mes
On Tue, Sep 1, 2015 at 4:27 PM, Jared Mauch wrote:
> I’m looking for some advice/input from people either public or private
> about woes building fiber to reach people outside the footprints of the
> existing incumbents.
I worked on one such project, indirectly, years ago. Fiber in a small
town.
On 2 Sep 2015, at 2:47, Tarko Tikan wrote:
In-band netflow works on all platforms without such issues.
There's no law that says that you must only plug designated management
ports into OOB/DCN management networks.
---
Roland Dobbins
On 2 Sep 2015, at 3:24, Niels Bakker wrote:
Because variety of flow telemetry delivery options isn't the #1 ranked
purchasing decider.
Actually, it is more often than you think. No use routing packets if
you can't see what they do.
Otherwise no Cisco would ever have been sold.
Which is
On 2 Sep 2015, at 3:34, Nick Hilliard wrote:
> If you want to handle netflow data export for large amounts of traffic, it
> would be pretty dumb to push it through the management plane of the router.
Concur 100%. You must use a port capable of doing so.
---
Roland
> On Sep 1, 2015, at 6:36 PM, Roland Dobbins wrote:
>
> On 2 Sep 2015, at 3:24, Niels Bakker wrote:
>
>> Because variety of flow telemetry delivery options isn't the #1 ranked
>> purchasing decider.
>
> Actually, it is more often than you think. No use routing packets if you
> can't see wha
> On Sep 1, 2015, at 5:38 PM, William Herrin wrote:
>
> On Tue, Sep 1, 2015 at 4:27 PM, Jared Mauch wrote:
>> I’m looking for some advice/input from people either public or private
>> about woes building fiber to reach people outside the footprints of the
>> existing incumbents.
>
> I worked o
On 2 Sep 2015, at 3:45, Chuck Church wrote:
Most OOB is lacking redundancy too, so a single failure can really
take the shine off an OOB deployment.
Even if you're using old, grandfathered equipment for it, there's no
reason why your OOB/DCN can't have a reasonable degree of redundancy.
Sin
> On Sep 1, 2015, at 6:37 PM, Roland Dobbins wrote:
>
> On 2 Sep 2015, at 3:34, Nick Hilliard wrote:
>
>> If you want to handle netflow data export for large amounts of traffic, it
>> would be pretty dumb to push it through the management plane of the router.
>
> Concur 100%. You must use a po
On 2 Sep 2015, at 5:38, Jared Mauch wrote:
Please stop digging,
Since I'm not digging, I've no reason to stop. I see and deal with the
various quirks of more different platforms exporting flow telemetry than
most folks, all day, every day, so I know just a little bit about this
topic.
Jared;
What you are trying to do is quite achievable, but a huge topic worthy of a
book, not an email post. Also, situations vary significantly between states
due to incumbents, regulatory regimes, and level of state support. NANOG is
a bad place to get advice about this topic. There are many othe
> On Sep 1, 2015, at 6:39 PM, Roland Dobbins wrote:
>
> On 2 Sep 2015, at 3:45, Chuck Church wrote:
>
>> Most OOB is lacking redundancy too, so a single failure can really take the
>> shine off an OOB deployment.
>
> Even if you're using old, grandfathered equipment for it, there's no reason
On 2 Sep 2015, at 2:38, George, Wes wrote:
Often there is a separate management network that can deal with
ethernet
speeds, but it's separate for security reasons and not always as
rigidly
independent from the in band network for connectivity, i.e. It might
be a
VPN riding over the regular net
> On Sep 1, 2015, at 6:51 PM, Roland Dobbins wrote:
>
>
> On 2 Sep 2015, at 5:38, Jared Mauch wrote:
>
>> Please stop digging,
>
> Since I'm not digging, I've no reason to stop. I see and deal with the
> various quirks of more different platforms exporting flow telemetry than most
> folks,
On 2 Sep 2015, at 0:55, Avi Freedman wrote:
Looking at probably 100 networks' flow paths over the last year, I'd
say 1 or 2 have OOB for flow.
Far fewer have it than should, agreed. A reasonable compromise is
VLANs, VRFs, and so on to at least keep it out of the data-plane of the
production
On 2 Sep 2015, at 0:46, Niels Bakker wrote:
This is the dumbest thing I've read on this mailing list in a while.
It happens. You can deny it all you like, but I've seen it happen, and
the resultant confusion and additional time to resolve problems it
causes.
--
On 2 Sep 2015, at 0:44, Jared Mauch wrote:
I think the key here is that Roland isn't often constrained by these
financial considerations.
That's entirely true. I deal every day with customers who are, though.
I would respectfully disagree with Roland here and agree with Job,
Niels, etc.
On 2 Sep 2015, at 6:06, Jared Mauch wrote:
You are, Avi has said that the number of people with a network is
outnumbered about 50:1 using his most favorable numbers.
Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band
to handle flow telemetry on a reasonable basis without
On 2 Sep 2015, at 5:49, Jared Mauch wrote:
Other platforms (e.g.: IOS-XR based) have issues with the MgmtEther
interfaces which make them inoperable for many use-cases.
I'm agreeing with you. Dedicated management ports on many boxes don't
actually support important management-plane functions
(Said Roland:)
> Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band
> to handle flow telemetry on a reasonable basis without mixing it in with
> customer traffic.
>
> That changes the ratio.
> I agree with you, Avi, and others that a dedicated OOB network *just for
> f
(Jared wrote):
> Most people I've seen have little data or insight into their
> networks, or don't have the level that they would desire as
> tools are expensive or impossible to justify due to capital costs.
> Tossing in a recurring opex cost of DC XC fee + transport + XC fee +
> redundan
On 2 Sep 2015, at 7:27, Avi Freedman wrote:
We see well under 20% doing logical separation but definitely folks
doing it...
~20% matches our subjective observations, as well.
We're doing our best to increase that number.
---
Roland Dobbins
I've not read every reply, but let me add my voice as some who has worked
on and ran SEVERAL large networks, in no case in the last long number of
years have I had access to an OOB network that was sized to carry anything
in large volume, and in fact like many others replied on a robust number of
p
--- rdobb...@arbor.net wrote:
Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band
to handle flow telemetry on a reasonable basis without mixing it in with
customer traffic.
---
Glad you clarified that. Now, I understand your stance. L
On 2 Sep 2015, at 7:38, jim deleskie wrote:
These networks survived many "large" DDoS attacks and far more fat
finger incidents then I like to think
about.
What I'm saying is that keeping flow telemetry and other
management-plane traffic from mixing with customer data-plane traffic is
impor
There's no such thing as free lunch right :). If BGP Add-Path or
Diverse-Path isn't option for you then as you mentioned Internet VRF with
different RD is the third option but you have to understand the
implications here as well around increase in % of memory. Another option
could be to bypass the
Agreed, we are as well :)
VLAN, VRF, whatever.
+ optimal tweaks include local flow proxy that can also rate
limit / re-sample, and send topk talkers over 'true' OOB.
Avi Freedman
CEO, Kentik
avi at kentik dot com
> On 2 Sep 2015, at 7:27, Avi Freedman wrote:
>
> > We see well under 20% doing
On 1/Sep/15 17:43, Roland Dobbins wrote:
> Until there is.
As with everything in life...
Mark.
On 1/Sep/15 17:59, Rod Beck wrote:
> Roland is correct. With the caveat that your Internet customer traffic may
> flow over the fibers as your separate management circuits. You should aim for
> end to end physical diversity. This is all common sense, but laziness some
> times takes precedence.
On 1/Sep/15 19:12, Roland Dobbins wrote:
>
>
>
> Running flow telemetry in-band is penny-wise and pound-foolish, for
> networks of any size, in any circumstances. All management-plane
> traffic (and that's what flow telemetry is) should be segregated from
> the production network data plane.
> "Roland" == Roland Dobbins writes:
Roland> On 2 Sep 2015, at 0:08, Steve Meuse wrote:
>> Your advice is not "one size fits all".
Roland> Actually, it is.
Roland> Large backbone networks have DCNs/OOBs, and that's where they export
Roland> their NDE.
2 out of 2 larg
64 matches
Mail list logo
