Re: sFlow vs netFlow/IPFIX

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

Re: Media converter vendors - GFP/EoSDH

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

Re: sFlow vs netFlow/IPFIX

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

Re: 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

Re: sFlow vs netFlow/IPFIX

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

Re: sFlow vs netFlow/IPFIX

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

Re: sFlow vs netFlow/IPFIX

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

Re: Media converter vendors - GFP/EoSDH

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

Re: Media converter vendors - GFP/EoSDH

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

Re: sFlow vs netFlow/IPFIX

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

Re: sFlow vs netFlow/IPFIX

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.

Re: mrtg alternative

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: > >

Re: sFlow vs netFlow/IPFIX

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

RE: sFlow vs netFlow/IPFIX

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

Re: sFlow vs netFlow/IPFIX

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 >

RE: Packet loss on XO's network

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

Re: mrtg alternative

Le 2016-02-27 20:42, B a écrit : > Graphite/grafana. I strongly recommend Graphite to all my competitors! :) Simon

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

RE: Packet loss on XO's network

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

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

Re: Media converter vendors - GFP/EoSDH

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? >

Re: Media converter vendors - GFP/EoSDH

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

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.

Media converter vendors - GFP/EoSDH

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

Re: mrtg alternative

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

Re: BGP MVPN RFC6513, Section 10

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

RE: mrtg alternative

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:

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: >>

Re: Cisco ASR9010 vs Juniper MX960

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

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

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

Re: Cisco ASR9010 vs Juniper MX960

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

Re: Low density Juniper (or alternative) Edge

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