Re: sFlow vs netFlow/IPFIX

[Roland Dobbins]

On 29 Feb 2016, at 14:41, Pavel Odintsov wrote:


Could you describe they in details?


Inconsistent stats, lack of ifindex information.

But netflow __could__ delay telemetry up to 30 seconds (in case of 
huge syn/syn-ack flood for example) and you network will experience 
downtime.


This is incorrect, and reflects an inaccurate understanding of how 
NetFlow/IPFIX actually works, in practice.  It's often repeated by those 
with little or no operational experience with NetFlow/IPFIX.


---
Roland Dobbins 

Re: Media converter vendors - GFP/EoSDH

[Mark Tinka]

On 29/Feb/16 06:47, Ramy Hashish wrote:

> Hello Mark,
>
> Do you know anything about their MEF compliance? which of them is
> capable of working in carrier-grade large scale environment?

All the ones I've mentioned seem to have some kind of CE 2.0 compliance.

How true it is I'm not really sure. I only use Cisco and Juniper for my
Carrier Ethernet deployments.

All those vendors have Carrier Ethernet support in their transport gear,
but it will usually be based on simple 802.1Q or MPLS-TP at the most. If
you want an IP/MPLS control plane, you'd need to look at their router
offerings, for those that have.

Mark.

Re: sFlow vs netFlow/IPFIX

[Pavel Odintsov]

Sorry but I could not understand what issues you've found in sflow.
Could you describe they in details?

Recently I had speech at RIPE 71 and show pattern of real attack which
achieved 6 gbps in first 30 seconds (just check slide 6 here
http://www.slideshare.net/pavel_odintsov/ripe71-fastnetmon-open-source-dos-ddos-mitigation).

And sflow device could offer 3-4 seconds detection time from this
case. But netflow __could__ delay telemetry up to 30 seconds (in case
of huge syn/syn-ack flood for example) and you network will experience
downtime.

But with sflow you could detect and mitigate this attack in seconds.
Is it make sense?

On Mon, Feb 29, 2016 at 10:32 AM, Roland Dobbins  wrote:
> On 29 Feb 2016, at 14:26, Pavel Odintsov wrote:
>
>> From my own experience sflow should be selected if you are interested in
>> internal packet payload (for dpi / ddos detection) or you need fast reaction
>> time on some actions (ddos is best example).
>
>
> This does not match my experience.  In particular, the implied canard about
> flow telemetry being inadequate for timely DDoS
> detection/classification/traceback grows tiresome, as it's used for that
> purpose every day, and works quite well.
>
> If one is also using an IDMS-type device to mitigate DDoS traffic, the
> device sees the whole packet, anyways.
>
> ---
> Roland Dobbins 



-- 
Sincerely yours, Pavel Odintsov

Re: sFlow vs netFlow/IPFIX

[Avi Freedman]

> This maybe outside the scope of this list but I was wondering if anybody had 
> advice or lessons learned on the whole sFlow vs netFlow debate. We are 
> looking at using it for billing and influencing our sdn flows. It seems like 
> everything I have found is biased (articles by companies who have commercial 
> offerings for the "better" protocol)
> 
> Todd Crane

Most vendors that take "flow" take both so there tends not to be THAT much 
religion unless you talk to someone who hates being flooded with 1:1 flow, or 
debugging broken (usually NetFlow) implementations.

In our experience, they both basically work for ops use cases nowadays, for 
major vendors of routers, and most switches.

sFlow gives faster feedback and more accurate (adding things up, * sample 
rates, closer to SNMP counter data) than most NetFlow/IPFIX implementations.  
How much varies from slightly to extreme (if you're using Catalysts for 
NetFlow/IPFIX).

My thesis overall re: why sFlow 'just works' a bit better is that it's just so 
much easier to implement sFlow because there's no need to track flows (hash 
table or whatever data structure you need).  Just grab samples of headers, 
parse, fill structs, and send.  

That said, things are hugely less sucky than 10 or even 5 years ago in the 
NetFlow world, and for the right vendor and box and software it's possible to 
get NetFlow/IPFIX essentially as accurate.

And has been noted, it at least in theory some boxes that do tens to hundreds 
of gigabits (or low terabits) of traffic support 1:1, which you could in theory 
do with sFlow as a transport, but I haven't seen a switch or router that does 
that.  Re: 1-1 flow - the boxes supporting that are generally not the biggest 
purchase-able from Cisco or Juniper, but are used as the big-boy backbone and 
border routers by a good number of multi-terabit networks, and even some 
multi-tens-of-terabit networks.

Good luck in your flow journeys.

Avi Freedman
CEO, Kentik

Re: sFlow vs netFlow/IPFIX

[Roland Dobbins]

On 29 Feb 2016, at 14:26, Pavel Odintsov wrote:

From my own experience sflow should be selected if you are interested 
in internal packet payload (for dpi / ddos detection) or you need fast 
reaction time on some actions (ddos is best example).


This does not match my experience.  In particular, the implied canard 
about flow telemetry being inadequate for timely DDoS 
detection/classification/traceback grows tiresome, as it's used for that 
purpose every day, and works quite well.


If one is also using an IDMS-type device to mitigate DDoS traffic, the 
device sees the whole packet, anyways.


---
Roland Dobbins 

Re: sFlow vs netFlow/IPFIX

[Avi Freedman]

Re: limits -

For Cisco/Juniper it's in the low hundreds of thousands of flows/sec
per chipset/linecard for 1:1 NetFlow/IPFIX, I think.

Then of course, as has been mentioned, you'll need to be able to send
it and receive it to something - and store+query.

Avi Freedman
CEO, Kentik

> On 28 February 2016 at 23:40, Nick Hilliard  wrote:



> Around here they are currently voting on a law that will require unsampled
> 1:1 netflow on all data in an ISP network with more than 100 users. Then
> store that data for 1 year, so the police and other parties can request a
> copy (with a warrant but you are never allowed to tell anyone that they
> came for the data and the judges will never say no).
> 
> My routers can apparently actually do 1:1 netflow and the documentation
> does not state any limits on that. So maybe I am lucky?
> 
> To the original question: in this country sFlow only is apparently about to
> become illegal.
> 
> Regards,
> 
> Baldur

Re: sFlow vs netFlow/IPFIX

[Pavel Odintsov]

Hello, folks!

I've huge experience for battle sflow vs netflow because in my free
DDoS detection toolkit fastnetmon we support both capture methods.

You could look at this comparison table:
https://github.com/pavel-odintsov/fastnetmon/blob/master/docs/CAPTURE_BACKENDS.md

>From my own experience sflow should be selected if you are interested
in internal packet payload (for dpi / ddos detection) or you need fast
reaction time on some actions (ddos is best example).

If you just need to count traffic and you accept pretty long reaction
time and not enough accurate traffic bandwidth data you could select
netflow.

>From hardware point of view almost all brand new switches support
sflow free of charge (no additional licenses or modules). But be
aware, Cisco do not support this protocol at all (that's pretty weird,
really). Also keep in mind sflow implemented in hardware ASIC with
small help from CPU and it's pretty fast and suitable for really any
traffic bandwidth.

I have experience with sflow analytics for 1.5 Tb+ network and it's
working really well!

For netflow sometimes you need additional modules / software licenses
and sometime devices completely haven't support for it. And if you
have software devices (for example small SRX routers from Juniper)
netflow generation will be pretty expensive from CPU point of view
because netflow need pretty big amount of CPU resources for
aggregation.


On Mon, Feb 29, 2016 at 5:41 AM,   wrote:
> On Mon, 29 Feb 2016 09:24:42 +0700, "Roland Dobbins" said:
>> On 29 Feb 2016, at 6:26, Baldur Norddahl wrote:
>>
>> > Around here they are currently voting on a law that will require unsampled
>> > 1:1 netflow on all data in an ISP network with more than 100 users.
>>
>> That's interesting, given that most larger routers don't support 1:1.
>
> In the war between reality and governmental paranoia, reality usually loses.



-- 
Sincerely yours, Pavel Odintsov

Re: Media converter vendors - GFP/EoSDH

[Ramy Hashish]

Hello Mark,

Do you know anything about their MEF compliance? which of them is capable
of working in carrier-grade large scale environment?

Ramy

On Sun, Feb 28, 2016 at 5:49 PM, Mark Tinka  wrote:

>
>
> On 28/Feb/16 15:10, Ramy Hashish wrote:
>
> > Hello there,
> >
> > Any recommendations for Ethernet-SDH/SONET media converter vendors?
>
> Huawei, Tejas, BTI, ECI, Tejas, all come to mind on the lower price scale.
>
> Mark.
>

Re: Media converter vendors - GFP/EoSDH

[Ramy Hashish]

Hello Clayton,

We are mainly looking for OC3, however OC12 and OC48 support -on multirate
ports- will be a plus of course...


On Sun, Feb 28, 2016 at 4:50 PM, Clayton Zekelman  wrote:

>
> What speeds SONET are you looking to map your Ethernet on to?
>
> RAD makes some products.
>
>  http://www.rad.com/10/Ethernet-over-SDH-SONET-ADM/2833/
>
> We use BIT Systems 2.5G Muxponders to map 2xGE to  OC48.  Works well.
>
>
> http://www.btisystems.com/Portals/0/Documents/Data-Sheets/Muxponder-Family-DS0022.pdf
>
> We also have some ADTRAN Opti-6100 units using Ethernet mappers.
>
>
>
>
>
> At 08:10 AM 28/02/2016, Ramy Hashish wrote:
>
>> Hello there,
>>
>> Any recommendations for Ethernet-SDH/SONET media converter vendors?
>>
>> Thanks,
>>
>> Ramy
>>
>
> --
>
> Clayton Zekelman
> Managed Network Systems Inc. (MNSi)
> 3363 Tecumseh Rd. E
> Windsor, Ontario
> N8W 1H4
>
> tel. 519-985-8410
> fax. 519-985-8409
>

Re: sFlow vs netFlow/IPFIX

[Valdis . Kletnieks]

On Mon, 29 Feb 2016 09:24:42 +0700, "Roland Dobbins" said:
> On 29 Feb 2016, at 6:26, Baldur Norddahl wrote:
>
> > Around here they are currently voting on a law that will require unsampled
> > 1:1 netflow on all data in an ISP network with more than 100 users.
>
> That's interesting, given that most larger routers don't support 1:1.

In the war between reality and governmental paranoia, reality usually loses.


pgpaKGYA30QPh.pgp
Description: PGP signature

Re: sFlow vs netFlow/IPFIX

[Roland Dobbins]

On 29 Feb 2016, at 6:26, Baldur Norddahl wrote:

> Around here they are currently voting on a law that will require unsampled
> 1:1 netflow on all data in an ISP network with more than 100 users.

That's interesting, given that most larger routers don't support 1:1.

---
Roland Dobbins 

Re: mrtg alternative

[Baldur Norddahl]

I went with InfluxDB and Grafana. It was exactly what I wanted.

Thanks for all the suggestions.

Regards,

Baldur


On 28 February 2016 at 00:20, Peter Phaal  wrote:

> InfluxDB + Grafana are a modern alternative from the DevOps space:
>
> http://lkhill.com/using-influxdb-grafana-to-display-network-statistics/
>
> On Fri, Feb 26, 2016 at 3:18 PM, Baldur Norddahl
>  wrote:
> > Hi
> >
> > I am currently using MRTG and RRD to make traffic graphs. I am searching
> > for more modern alternatives that allows the user to dynamically zoom and
> > scroll the timeline.
> >
> > Bonus points if the user can customize the graphs directly in the
> > webbrowse. For example he might be able to add or remove individual peers
> > from the graph by simply clicking a checkbox.
> >
> > What is the 2016 tool for this?
> >
> > Regards,
> >
> > Baldur
>

Re: sFlow vs netFlow/IPFIX

[Baldur Norddahl]

On 28 February 2016 at 23:40, Nick Hilliard  wrote:

> Netflow was designed to measure flows, and it turned out that the design
> was robust enough for it to be more-or-less good enough for billing
> purposes. It's "more or less" because on larger routers, you can't do
> 1:1 data export and you end up needing to do traffic sampling, at which
> point you're billing based on realistic estimates rather than exact
> data.  That's fine if your contract with your customer says it's ok.
>


Around here they are currently voting on a law that will require unsampled
1:1 netflow on all data in an ISP network with more than 100 users. Then
store that data for 1 year, so the police and other parties can request a
copy (with a warrant but you are never allowed to tell anyone that they
came for the data and the judges will never say no).

My routers can apparently actually do 1:1 netflow and the documentation
does not state any limits on that. So maybe I am lucky?

To the original question: in this country sFlow only is apparently about to
become illegal.

Regards,

Baldur

RE: sFlow vs netFlow/IPFIX

[Phil Bedard]

What HW are your looking at our are you rolling your own probes?  Router/switch 
HW almost never does both.   Netflow/IPFIX puts the flow intelligence in the 
router, but with that comes more limitations.

 Sflow typically uses more BW because you are sending headers for each packet.  
The sflow collector also needs more intelligence since it's doing flow 
correlation, AS matching, etc. instead of the router doing it.  However it is 
more flexible since adding a new header, like vxlan or NSH is much easier to 
implement in some analysis SW than router SW.  

Phil



From: Todd Crane
Sent: Sunday, February 28, 2016 3:09 PM
To: nanog@nanog.org
Subject: sFlow vs netFlow/IPFIX

This maybe outside the scope of this list but I was wondering if anybody had 
advice or lessons learned on the whole sFlow vs netFlow debate. We are looking 
at using it for billing and influencing our sdn flows. It seems like everything 
I have found is biased (articles by companies who have commercial offerings for 
the "better" protocol)

Todd Crane

Re: sFlow vs netFlow/IPFIX

[Nick Hilliard]

Todd Crane wrote:
> This maybe outside the scope of this list but I was wondering if
> anybody had advice or lessons learned on the whole sFlow vs netFlow
> debate. We are looking at using it for billing and influencing our
> sdn flows. It seems like everything I have found is biased (articles
> by companies who have commercial offerings for the "better"
> protocol)

There is a lot of religion floating around about this subject.

Netflow was designed to measure flows, and it turned out that the design
was robust enough for it to be more-or-less good enough for billing
purposes. It's "more or less" because on larger routers, you can't do
1:1 data export and you end up needing to do traffic sampling, at which
point you're billing based on realistic estimates rather than exact
data.  That's fine if your contract with your customer says it's ok.

Netflow works by tracking individual flows in the data plane.  This is
pretty complicated in practice and requires dedicated hardware to handle
it at line rate.  You generally end up with two packet forwarding
engines on a hardware-forwarded router: one to handle the forwarding,
and the other to categorise and handle the flow data.  This means that
netflow is expensive to design, build and run.

Sflow is a simple packet header sampling mechanism.  The only thing it
does is to pick out every 1 in N packets, and to try to figure out where
the headers stop and the data begins.  The header is then forwarded to
the sflow collector, which is where all the smart stuff is done.

If your netflow / sflow packet sampling mechanism is accurate and your
router is configured appropriate for the quantity of flow data being
exported (i.e. it isn't dropping data samples due to overload), then for
the most part, there will be no substantial difference between using
sflow and sampled netflow (depending on the data flow type), assuming
that each protocol provides the data you're looking for.

Obviously, if your sampling mechanism is broken or your exporter is
overloaded, then both sflow and netflow will produce trash.

If you're using unsampled netflow, then netflow will be more accurate,
assuming you don't end up overflowing the netflow data export mechanism.

Anything which uses sampling - regardless of whether it's for netflow or
sflow - needs to be profiled before being pushed into production,
because you need to understand the limits of the sampling mechanism.
Hardware sampling often doesn't work properly or plateaus off at a
certain stage, dropping packets in the process.  This can cause
unwelcome surprises.

Without knowing anything more about your requirements or your choice of
equipment, I'd suggest that sflow would probably be a better choice for
SDN tuning and probably netflow would be better for billing, but YMMV.

Nick

RE: Packet loss on XO's network

[Frank Bulk]

Terri,

 

Except the initial traces show that hop 6 is clean.  If the problem really
started at hop 4 then the issue would likely show up in hop 6 (unless there
was a hashing on the return path based on the far end router's source IP
that caused just some traffic to be thrown away).

 

Hop 4 and 5 always have packet loss - I believe it's due to ICMPv6 rate
limiters protecting their CPU:

 



 

Frank

 

From: Fullenkamp, Terri L [mailto:terri.l.fullenk...@xo.com] 
Sent: Sunday, February 28, 2016 2:59 PM
To: Frank Bulk ; nanog@nanog.org
Cc: # SUP - NCC Level 1 Data 
Subject: RE: Packet loss on XO's network

 

 

>From the traces provided the packet loss starts accruing at hop 4 and 5 and
that is before it gets into the XO network,  If you are a customer of XO
please contact care @ 888-575-6398 with any other questions

 

Trace from hop 6

 

 

tfullenk@MCR2.Minneapolis-MN  >
traceroute enterprise.com 

traceroute6 to enterprise.com (2620:103:e049:31a7::b4) from 2610:18::30bc,
64 hops max, 12 byte packets

1  mcr1.minneapolis-mn.us.xo.net (2610:18::30b8)  29.325 ms  28.950 ms
31.327 ms

 MPLS Label=318081 CoS=0 TTL=1 S=0

 MPLS Label=2 CoS=0 TTL=1 S=1

2  2610:18::5802 (2610:18::5802)  32.680 ms  29.684 ms  32.643 ms

 MPLS Label=19268 CoS=0 TTL=255 S=0

 MPLS Label=2 CoS=0 TTL=255 S=1

3  2610:18::5804 (2610:18::5804)  30.629 ms  33.384 ms  81.985 ms

 MPLS Label=757571 CoS=0 TTL=1 S=0

 MPLS Label=2 CoS=0 TTL=3 S=1

4  2610:18::5803 (2610:18::5803)  65.305 ms  28.876 ms  39.141 ms

 MPLS Label=419427 CoS=0 TTL=1 S=0

 MPLS Label=2 CoS=0 TTL=4 S=1

5  2610:18::5201 (2610:18::5201)  36.762 ms  28.776 ms  28.718 ms

 MPLS Label=694064 CoS=0 TTL=1 S=0

 MPLS Label=2 CoS=0 TTL=5 S=1

6  2610:18::2070 (2610:18::2070)  29.487 ms  28.920 ms  42.500 ms

7  2610:18:16::32 (2610:18:16::32)  28.619 ms 2600:803:2::9 (2600:803:2::9)
28.706 ms  28.692 ms

8  2600:807:21f::22 (2600:807:21f::22)  47.997 ms  48.042 ms  50.504 ms

9  2600:807:21f::22 (2600:807:21f::22)  48.026 ms  48.084 ms  49.172 ms




Terri Fullenkamp  
NCC Specialist V / IP Data /   XO Communications / 2020
Westport Center Drive, Maryland Heights, MO 63146
T: 866-966-8975 F: 314-787- 7799 E: terri.l.fullenk...@xo.com
 

 

 

From: Frank Bulk [mailto:frnk...@iname.com] 
Sent: Sunday, February 28, 2016 12:25
To: nanog@nanog.org  
Subject: Packet loss on XO's network

 

Since ~11:08 am Central our monitoring system has been reporting
intermittent HTTPv6 timeouts to www.sprint.net  ,
www.qwest.com  , enterprise.com, and enterprise.ca.
It goes bad for a while and then clears.

 

Using mtr, these all have XO's network in common, and the packet loss to the
endpoint sustains over 40%.  Seems to be between 2610:18:18b:c000::11 and
mcr1.minneapolis-mn.us.xo.net [2610:18::30b8]

 

Frank

 

 

To enterprise.com:

 

Host
Loss%   Snt   Last   Avg  Best  Wrst StDev

1. router-core.mtcnet.net
0.0%   9290.3   0.6   0.2  37.6   2.5

2. sxct.sxcy.mtcnet.net
0.0%   9290.3   0.3   0.2  11.2   0.6

3. v6-premier.sxcy-mlx.fbnt.netins.net
0.0%   9291.6   1.5   1.5  12.6   0.9

4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net
52.4%   9298.1   8.0   7.8  10.5   0.3

5. v6-ins-dc1-te-7-4.desm.netins.net
52.4%   9297.9   8.0   7.6  10.9   0.5

6. 2610:18:18b:c000::11
0.0%   929   13.9  13.2  12.8  46.8   3.0

7. mcr1.minneapolis-mn.us.xo.net
50.3%   929   54.7  71.2  54.6  86.7   7.7

8. 2610:18::5802
50.8%   929   55.7  72.8  54.6  84.3   7.8

9. 2610:18::5202
51.4%   929   54.4  72.9  54.4  85.0   8.0

2610:18::5804

10. 2610:18::2070
52.3%   928   54.4  71.5  54.4  90.7   7.9

2610:18::5304

11. 2600:803:2::9
41.6%   928   54.5  56.8  47.8  96.7   3.4

2610:18::5303

12. 2610:18::5200
96.0%   928   54.5  55.8  54.4  75.6   3.7

13. 2610:18::5202
96.0%   928   55.5  56.6  54.6  58.5   1.2

14. 2610:18::2070
96.0%   928   61.8  55.1  54.6  61.8   1.2

15. 2600:803:2::9
95.9%   928   45.0  45.1  45.0  48.0   0.5

16. ???

 

To www.sprint.net  :

 
Packets   Pings

Host
Loss%   Snt   Last   Avg  Best  Wrst StDev

1. router-core.mtcnet.net
0.0%   8460.4   0.8   0.2  91.5   3.9

2. sxct.sxcy.mtcnet.net
0.0%   8460.9   0.3   0.2  10.3   0.4

3. v6-premier.sxcy-mlx.fbnt.netins.net
0.0%   8461.5   1.6   1.5  12.0   0.8

4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net
55.4%   8467.9   8.1   7.8  14.8   0.4

5. v6-ins-dc1-te-7-4.desm.netins.net
54.3%   8467.8   8.2   7.6  19.2   1.0

6. 2610:18:18b:c000::11
0.0%   846   12.9  14.0  12.8  73.0   5.4

7. mcr1.minneapolis-mn.us.xo.net
49.8%   846   54.7  70.0  54.6 100.1   8.1

8. 2610:18::5802
47.4%   846   58.3  71.9  54.6  82.9   8.2

9. 2610:18::5202
45.0%   846   54.4  72.1  54.4  83.3   8.4

2610:18::5804

10. 2610:18::2070
50.6%   845   54.4 

Re: mrtg alternative

[Simon Perreault]

Le 2016-02-27 20:42, B a écrit :
> Graphite/grafana.

I strongly recommend Graphite to all my competitors! :)

Simon

sFlow vs netFlow/IPFIX

[Todd Crane]

This maybe outside the scope of this list but I was wondering if anybody had 
advice or lessons learned on the whole sFlow vs netFlow debate. We are looking 
at using it for billing and influencing our sdn flows. It seems like everything 
I have found is biased (articles by companies who have commercial offerings for 
the "better" protocol)

Todd Crane

RE: Packet loss on XO's network

[Frank Bulk]

XO contacted me offline.  Things have bene stable since ~12:15 pm Central.

Frank

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Frank Bulk
Sent: Sunday, February 28, 2016 12:25 PM
To: nanog@nanog.org
Subject: Packet loss on XO's network

Since ~11:08 am Central our monitoring system has been reporting
intermittent HTTPv6 timeouts to www.sprint.net, www.qwest.com
 , enterprise.com, and enterprise.ca.  It goes bad for
a while and then clears.

 

Using mtr, these all have XO's network in common, and the packet loss to the
endpoint sustains over 40%.  Seems to be between 2610:18:18b:c000::11 and
mcr1.minneapolis-mn.us.xo.net [2610:18::30b8]

 

Frank

 

 

To enterprise.com:

 

Host
Loss%   Snt   Last   Avg  Best  Wrst StDev

1. router-core.mtcnet.net
0.0%   9290.3   0.6   0.2  37.6   2.5

2. sxct.sxcy.mtcnet.net
0.0%   9290.3   0.3   0.2  11.2   0.6

3. v6-premier.sxcy-mlx.fbnt.netins.net
0.0%   9291.6   1.5   1.5  12.6   0.9

4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net
52.4%   9298.1   8.0   7.8  10.5   0.3

5. v6-ins-dc1-te-7-4.desm.netins.net
52.4%   9297.9   8.0   7.6  10.9   0.5

6. 2610:18:18b:c000::11
0.0%   929   13.9  13.2  12.8  46.8   3.0

7. mcr1.minneapolis-mn.us.xo.net
50.3%   929   54.7  71.2  54.6  86.7   7.7

8. 2610:18::5802
50.8%   929   55.7  72.8  54.6  84.3   7.8

9. 2610:18::5202
51.4%   929   54.4  72.9  54.4  85.0   8.0

2610:18::5804

10. 2610:18::2070
52.3%   928   54.4  71.5  54.4  90.7   7.9

2610:18::5304

11. 2600:803:2::9
41.6%   928   54.5  56.8  47.8  96.7   3.4

2610:18::5303

12. 2610:18::5200
96.0%   928   54.5  55.8  54.4  75.6   3.7

13. 2610:18::5202
96.0%   928   55.5  56.6  54.6  58.5   1.2

14. 2610:18::2070
96.0%   928   61.8  55.1  54.6  61.8   1.2

15. 2600:803:2::9
95.9%   928   45.0  45.1  45.0  48.0   0.5

16. ???

 

To www.sprint.net:

 
Packets   Pings

Host
Loss%   Snt   Last   Avg  Best  Wrst StDev

1. router-core.mtcnet.net
0.0%   8460.4   0.8   0.2  91.5   3.9

2. sxct.sxcy.mtcnet.net
0.0%   8460.9   0.3   0.2  10.3   0.4

3. v6-premier.sxcy-mlx.fbnt.netins.net
0.0%   8461.5   1.6   1.5  12.0   0.8

4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net
55.4%   8467.9   8.1   7.8  14.8   0.4

5. v6-ins-dc1-te-7-4.desm.netins.net
54.3%   8467.8   8.2   7.6  19.2   1.0

6. 2610:18:18b:c000::11
0.0%   846   12.9  14.0  12.8  73.0   5.4

7. mcr1.minneapolis-mn.us.xo.net
49.8%   846   54.7  70.0  54.6 100.1   8.1

8. 2610:18::5802
47.4%   846   58.3  71.9  54.6  82.9   8.2

9. 2610:18::5202
45.0%   846   54.4  72.1  54.4  83.3   8.4

2610:18::5804

10. 2610:18::2070
50.6%   845   54.4  70.4  54.3  88.8   8.1

2610:18::5304

11. sl-st31-ash-te0-15-2-0.v6.sprintlink.net
43.4%   845   57.5  59.1  53.1  80.5   2.3

2610:18::5303

12. sl-crs3-dc-be13.v6.sprintlink.net
46.7%   845   54.6  64.7  54.4  69.1   3.7

2610:18::5200

13. sl-crs1-ffx-be2.v6.sprintlink.net
44.1%   844   55.0  71.8  55.0  79.7   5.3

2610:18::5202

14. sl-crs1-orl-bu-1.v6.sprintlink.net
41.7%   844   54.9  75.7  54.7  96.3   7.4

2610:18::2070

15. sl-lkdstr2-p1-0.v6.sprintlink.net
41.0%   844   46.4  73.5  45.8  81.7   7.0

sl-st31-ash-te0-15-2-0.v6.sprintlink.net

16. www.sprint.net
43.1%   844   54.5  74.6  53.5  81.6   5.0

sl-crs3-dc-be13.v6.sprintlink.net

 

 



 

Packet loss on XO's network

[Frank Bulk]

Since ~11:08 am Central our monitoring system has been reporting
intermittent HTTPv6 timeouts to www.sprint.net, www.qwest.com
 , enterprise.com, and enterprise.ca.  It goes bad for
a while and then clears.

 

Using mtr, these all have XO's network in common, and the packet loss to the
endpoint sustains over 40%.  Seems to be between 2610:18:18b:c000::11 and
mcr1.minneapolis-mn.us.xo.net [2610:18::30b8]

 

Frank

 

 

To enterprise.com:

 

Host
Loss%   Snt   Last   Avg  Best  Wrst StDev

1. router-core.mtcnet.net
0.0%   9290.3   0.6   0.2  37.6   2.5

2. sxct.sxcy.mtcnet.net
0.0%   9290.3   0.3   0.2  11.2   0.6

3. v6-premier.sxcy-mlx.fbnt.netins.net
0.0%   9291.6   1.5   1.5  12.6   0.9

4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net
52.4%   9298.1   8.0   7.8  10.5   0.3

5. v6-ins-dc1-te-7-4.desm.netins.net
52.4%   9297.9   8.0   7.6  10.9   0.5

6. 2610:18:18b:c000::11
0.0%   929   13.9  13.2  12.8  46.8   3.0

7. mcr1.minneapolis-mn.us.xo.net
50.3%   929   54.7  71.2  54.6  86.7   7.7

8. 2610:18::5802
50.8%   929   55.7  72.8  54.6  84.3   7.8

9. 2610:18::5202
51.4%   929   54.4  72.9  54.4  85.0   8.0

2610:18::5804

10. 2610:18::2070
52.3%   928   54.4  71.5  54.4  90.7   7.9

2610:18::5304

11. 2600:803:2::9
41.6%   928   54.5  56.8  47.8  96.7   3.4

2610:18::5303

12. 2610:18::5200
96.0%   928   54.5  55.8  54.4  75.6   3.7

13. 2610:18::5202
96.0%   928   55.5  56.6  54.6  58.5   1.2

14. 2610:18::2070
96.0%   928   61.8  55.1  54.6  61.8   1.2

15. 2600:803:2::9
95.9%   928   45.0  45.1  45.0  48.0   0.5

16. ???

 

To www.sprint.net:

 
Packets   Pings

Host
Loss%   Snt   Last   Avg  Best  Wrst StDev

1. router-core.mtcnet.net
0.0%   8460.4   0.8   0.2  91.5   3.9

2. sxct.sxcy.mtcnet.net
0.0%   8460.9   0.3   0.2  10.3   0.4

3. v6-premier.sxcy-mlx.fbnt.netins.net
0.0%   8461.5   1.6   1.5  12.0   0.8

4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net
55.4%   8467.9   8.1   7.8  14.8   0.4

5. v6-ins-dc1-te-7-4.desm.netins.net
54.3%   8467.8   8.2   7.6  19.2   1.0

6. 2610:18:18b:c000::11
0.0%   846   12.9  14.0  12.8  73.0   5.4

7. mcr1.minneapolis-mn.us.xo.net
49.8%   846   54.7  70.0  54.6 100.1   8.1

8. 2610:18::5802
47.4%   846   58.3  71.9  54.6  82.9   8.2

9. 2610:18::5202
45.0%   846   54.4  72.1  54.4  83.3   8.4

2610:18::5804

10. 2610:18::2070
50.6%   845   54.4  70.4  54.3  88.8   8.1

2610:18::5304

11. sl-st31-ash-te0-15-2-0.v6.sprintlink.net
43.4%   845   57.5  59.1  53.1  80.5   2.3

2610:18::5303

12. sl-crs3-dc-be13.v6.sprintlink.net
46.7%   845   54.6  64.7  54.4  69.1   3.7

2610:18::5200

13. sl-crs1-ffx-be2.v6.sprintlink.net
44.1%   844   55.0  71.8  55.0  79.7   5.3

2610:18::5202

14. sl-crs1-orl-bu-1.v6.sprintlink.net
41.7%   844   54.9  75.7  54.7  96.3   7.4

2610:18::2070

15. sl-lkdstr2-p1-0.v6.sprintlink.net
41.0%   844   46.4  73.5  45.8  81.7   7.0

sl-st31-ash-te0-15-2-0.v6.sprintlink.net

16. www.sprint.net
43.1%   844   54.5  74.6  53.5  81.6   5.0

sl-crs3-dc-be13.v6.sprintlink.net

 

 



 

Re: Media converter vendors - GFP/EoSDH

[Jon Swanson]

MRV makes some nicely priced options.  I have used them for years with no
issues.

On Sunday, February 28, 2016, Mark Tinka  wrote:

>
>
> On 28/Feb/16 15:10, Ramy Hashish wrote:
>
> > Hello there,
> >
> > Any recommendations for Ethernet-SDH/SONET media converter vendors?
>
> Huawei, Tejas, BTI, ECI, Tejas, all come to mind on the lower price scale.
>
> Mark.
>

Re: Media converter vendors - GFP/EoSDH

[Mark Tinka]

On 28/Feb/16 15:10, Ramy Hashish wrote:

> Hello there,
>
> Any recommendations for Ethernet-SDH/SONET media converter vendors?

Huawei, Tejas, BTI, ECI, Tejas, all come to mind on the lower price scale.

Mark.

Re: Media converter vendors - GFP/EoSDH

[Clayton Zekelman]

What speeds SONET are you looking to map your Ethernet on to?

RAD makes some products.

 http://www.rad.com/10/Ethernet-over-SDH-SONET-ADM/2833/

We use BIT Systems 2.5G Muxponders to map 2xGE to  OC48.  Works well.

http://www.btisystems.com/Portals/0/Documents/Data-Sheets/Muxponder-Family-DS0022.pdf

We also have some ADTRAN Opti-6100 units using Ethernet mappers.




At 08:10 AM 28/02/2016, Ramy Hashish wrote:

Hello there,

Any recommendations for Ethernet-SDH/SONET media converter vendors?

Thanks,

Ramy


--

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409

Media converter vendors - GFP/EoSDH

[Ramy Hashish]

Hello there,

Any recommendations for Ethernet-SDH/SONET media converter vendors?

Thanks,

Ramy

Re: mrtg alternative

[Job Snijders]

On Sat, Feb 27, 2016 at 12:18:16AM +0100, Baldur Norddahl wrote:
> I am currently using MRTG and RRD to make traffic graphs. I am
> searching for more modern alternatives that allows the user to
> dynamically zoom and scroll the timeline.
> 
> Bonus points if the user can customize the graphs directly in the
> webbrowse. For example he might be able to add or remove individual peers
> from the graph by simply clicking a checkbox.

You might want to check out http://www.librenms.org/

Kind regards,

Job

Re: BGP MVPN RFC6513, Section 10

[Mark Tinka]

On 26/Feb/16 11:33, Yann Lejeune wrote:

>
> It's up to you to choose what mode you want to use:
> - spt-only: is quite "simple". We only have (s,g) in the core. To validate
> an os, it's faster.
> - rpt-spt. We have both (*,g) and (s,g) in the core. the validation is more
> complex, the protocol is more dynamic...

I've ran both modes, and found SPT-only mode to be a fair compromise
between speed and scale.

When operating SPT-only modes, we did not witness a noticeable
difference in channel-changing times. In SPT-only mode, the (S,G) state
is already present on the Receiver PE router even though there is no
downstream interest for that state. So when an IGMP Join request comes
into the router, it does not have to travel the RPT tree like it would
if you ran RPT-SPT mode (which is traditional Multicast).

In our case, we had Multicast probes connected to every Receiver PE
router to track performance for each channel. So if you have that,
you're going to need all the channels present on the router anyway, even
though downstream interest is not present. In this case, avoiding the
extra steps associated with RPT-SPT mode is what compelled us to run
SPT-only mode.

But as Yann has mentioned, even in SPT-only mode, the Type 6 routes will
exit in the router, but won't really be used. Type 5 routes are more
important when operating in SPT-only mode, and those are always present
in such a state.

My next NG-MVPN operation will be SSM-based, so this should be simpler
still.

Mark.

RE: mrtg alternative

[Jürgen Jaritsch]

PRTG since years ... And smokeping for special things ...

Best regards


Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601


-Original Message-
From: Guillaume Tournat [guilla...@ironie.org]
Received: Sonntag, 28 Feb. 2016, 11:39
To: Roberto Alvarado [ralvar...@anycast.cl]; nanog@nanog.org [nanog@nanog.org]
Subject: Re: mrtg alternative

Zabbix for monitoring/graphing/alerting
Can be used for maps and SLA measurements too


> Le 28 févr. 2016 à 00:27, Roberto Alvarado  a écrit :
>
> Zabbix works for me
>
>
>
>> On 27-02-2016, at 18:12, Rafael Ganascim  wrote:
>>
>> I like cacti:
>>
>> http://www.cacti.net
>>
>>
>>
>> 2016-02-26 20:18 GMT-03:00 Baldur Norddahl :
>>
>>> Hi
>>>
>>> I am currently using MRTG and RRD to make traffic graphs. I am searching
>>> for more modern alternatives that allows the user to dynamically zoom and
>>> scroll the timeline.
>>>
>>> Bonus points if the user can customize the graphs directly in the
>>> webbrowse. For example he might be able to add or remove individual peers
>>> from the graph by simply clicking a checkbox.
>>>
>>> What is the 2016 tool for this?
>>>
>>> Regards,
>>>
>>> Baldur
>>>

Re: mrtg alternative

[Guillaume Tournat]

Zabbix for monitoring/graphing/alerting
Can be used for maps and SLA measurements too 


> Le 28 févr. 2016 à 00:27, Roberto Alvarado  a écrit :
> 
> Zabbix works for me
> 
> 
> 
>> On 27-02-2016, at 18:12, Rafael Ganascim  wrote:
>> 
>> I like cacti:
>> 
>> http://www.cacti.net
>> 
>> 
>> 
>> 2016-02-26 20:18 GMT-03:00 Baldur Norddahl :
>> 
>>> Hi
>>> 
>>> I am currently using MRTG and RRD to make traffic graphs. I am searching
>>> for more modern alternatives that allows the user to dynamically zoom and
>>> scroll the timeline.
>>> 
>>> Bonus points if the user can customize the graphs directly in the
>>> webbrowse. For example he might be able to add or remove individual peers
>>> from the graph by simply clicking a checkbox.
>>> 
>>> What is the 2016 tool for this?
>>> 
>>> Regards,
>>> 
>>> Baldur
>>> 

Re: Cisco ASR9010 vs Juniper MX960

[Mark Tinka]

On 18/Feb/16 16:46, Saku Ytti wrote:

> If I could get classicIOS with commit and RPL, I'd run that rather
> than XR right now.

+1.

Mark.

Re: Cisco ASR9010 vs Juniper MX960

[Mark Tinka]

On 18/Feb/16 15:59, Josh Reynolds wrote:

> With GRES, can't you simply set the master RE as backup, apply firmware,
> then switch back to master and upgrade the backup RE?

Not always.

Multicast, for example, tends to not survive upgrades in GRES conditions
as a matter of protocol.

Mark.

Re: Cisco ASR9010 vs Juniper MX960

[Mark Tinka]

On 18/Feb/16 15:55, Jason Bothe wrote:

> We have both and they’re both great boxes, however it’s sort of embarrassing 
> that the ASR9k still can’t do virtualized routing, ie. logical-systems.  Not 
> sure if thats a deal breaker for you but just thought you’d like to beware.  
> We also find OS configurations on the Juniper much easier than the cumbersome 
>  XR OS that the Cisco runs.  The 9k does however get a huge win with the 
> ability to apply a ‘pie’ or software patch while staying in service vs 
> requiring a reload.   Either way, I don’t think you’ll go wrong.
It can be hit & miss with the PIE's and SMU's.

We've been in situations where in-service updates (not ISSU) were
documented as being hitless, but ooops...

Mark.

Re: Cisco ASR9010 vs Juniper MX960

[Mark Tinka]

On 18/Feb/16 15:45, Colton Conor wrote:

> I would like opinions of the differences between these two platforms if
> possible.
>
> I was going to buy a used Juniper MX960 Router MX960-PREMIUM2-AC-ECM with
>  2 x RE-S-1800X4-16G  and 3 x SCBE-MX-S. Then I was going to load this up
> with a couple of older DPCE-R-4XGE-XFP 4x10GE DPC Enhanced cards.
>
> Now Cisco has offered me a new ASR9010 with dual ASR9K Route Switch
> Processor with 440G/slot Fabric and 6GB, and two 4X10GE / 16X1G Combo
> Linecard, Packet Transport Optimized for about the same price as the used
> Juniper. The only catch is the Cisco's support and warranty looks
> very expensive per year, but that's hard to compare since a used Juniper
> has zero support and warranty included.

If DPC's are your only option on the MX960, then the ASR9010 will be a
better option with those line cards.

If you are able to run the newer MIC/MPC line cards on the Juniper,
capabilities will not vary much; but IMHO, the MX960 will have a slight
edge over the ASR9010.

Mark.

Re: Low density Juniper (or alternative) Edge

[Mark Tinka]

On 6/Feb/16 23:41, Josh Reynolds wrote:

> Newer, more expensive, more bugs. 4500 is cheap on the secondary market.

The EX4600 is actually just a shy cheaper than the EX4550. We are
looking at it not because the EX4550 is a bad box, but because Juniper
are focusing development on the EX4600 instead (much like Cisco are
doing between the ME3600X and ASR920).

You lose 8x ports on the EX4600, though, if coming from the EX4550. May
or may not be an issue for you.

I wouldn't look at the EX4500. Too big and old now.

Mark.