Re: BCP 38 addendum

Hey, > This is exactly my idea : why should I allowed uRPF passing traffic from > routes not learned on this port ?? Why if I have Cogent + Level3 and I > denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should get > spoofed traffic from Level3 ranges over Cogent peering port ?

Re: BCP 38 addendum

Hey, How would this work? ISP1--ISP2---ISP3 || +---ISP4-+ In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects to ISP2, ISP4 - ISP3 receives ISP1 prefixes via ISP[24] - ISP3 advertises its prefix out via ISP4 ISP1 will receive traffic from ISP3

Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

Enno et al ULA fans I could not agree more. Either you provide your enterprise customers transportable address or ULA. If you assign and promote them to use your 'PA' address, they will take your PA address with them when they change operator 10 years from now, and if you reuse it, these two

Re: Console Servers & Cellular Providers

On 8 February 2018 at 06:48, Michael Rave wrote: > At all my sites I use Air Console with an OOB IP connection from another ISP. > Sometimes this is free since it is barely being used or I’m being charged a > very small amount . Other times I exchange an OOB IP

Re: evil ipv6 bit?

On 26 January 2018 at 03:50, Baldur Norddahl wrote: > I just now discovered this: > > google.com: 2a00:1450:400e:807::200e > > That address works fine. But then I changed that one bit in the address: > 2a00:1450:400e:8807::200e and voila, the router drops the packet.

Re: Blockchain and Networking

On 11 January 2018 at 00:54, Filip Hruska wrote: > You can't just run normal software on ASICs. It's not a computer. They're > literally hard-wired to do one thing - and do it well. > Switch ASICs, for example, are good for switching network packets around. > Though (I would

Re: Spectre/Meltdown impact on network devices

On 8 January 2018 at 12:41, Stephane Bortzmeyer wrote: > the best solution, for the attacker, is probably to exploit a bug in > the BGP parser (as we have seen with attribute 99, BGP parsers have > bugs): with a buffer overflow, you may be able to run code you > choose. Purely

Re: Waste will kill ipv6 too

On 20 December 2017 at 21:01, Aaron Gould wrote: > I wonder if the 20 bit mpls label will be re-thought down the road also ? No comment to the IPv6 discussion. But size of MPLS label is consideration, and we do spend two labels for one thing, partly due to size limit, partly

Re: Bandwidth distribution per ip

On 20 December 2017 at 20:34, Denys Fedoryshchenko wrote: > As you can see max single ip takes is 4.48% of bandwidth. > Also i cannot waste ipv4 for larger pools, just because of some deadly > flawed equipment/configuration. This indeed sounds unacceptable. I would suspect

Re: Bandwidth distribution per ip

On 20 December 2017 at 19:04, Denys Fedoryshchenko wrote: > As person who is in love with embedded systems development, i just watched > today beautiful 10s of meters long 199x machine, where multi kW VFDs manage > huge motors(not steppers), dragging synchronously and printing

Re: Bandwidth distribution per ip

On 20 December 2017 at 16:55, Denys Fedoryshchenko wrote: > And for me, it sounds like faulty aggregation + shaping setup, for example, > i heard once if i do policing on some models of Cisco switch, on an > aggregated interface, if it has 4 interfaces it will install 25%

Re: Small full BGP table capable router with low power consumption

Hey Adam, Review also: Nokia IXR-R6 (not IXR-6) Huawei NE20E-S2E On 4 December 2017 at 21:19, Adam Lawson wrote: > Hi, > > > > I'm looking for suggestions on 1U-2U sized router with 1G interface > > which can handle both IPv4 and IPv6 full BGP table and doesn't consume > >

Re: BGP next-hop self benefits

I'd like to add that one major advantage is limiting next-hops, thus labels in your network. This is not just theoretical concern but there are plenty of practical networks using practical hardware where you simply cannot expose all next-hops to every node. On 1 December 2017 at 17:30, Ken

Re: IPv6 first hop security on a budget?

Not suggesting there is no use case of RA Guard, DHCP6 Snooping, ICMP6 snooping, as I deployed IPv4 equivalent pretty much the day they were available on 3560. You might want to consider de-perimeterisation. Do you offer way to connect to intranet from Internet? If so, why not use same method in

Re: IPv6 Loopback/Point-to-Point address allocation

On 12 September 2017 at 01:08, Lee Howard wrote: >>Are any of you currently running IPv6 and wished you had done something >>differently during the planning phase that may have prevented headaches >>down the road? > > I always tell people: you’re going to rewrite your address

Re: IPv6 Loopback/Point-to-Point address allocation

On 10 September 2017 at 13:56, Thomas Bellman wrote: > An alternative is to just have link-local addresses on your point-to- > point links. At least on your internal links where you run your IGP. > On external links, where you run eBGP or static routes, it's probably > more

Re: Cogent BCP-38

On 29 August 2017 at 03:38, Robert Blayzor wrote: > Well not completely useless. BCP will still drop BOGONs at the edge before > they leak into your network. Assuming you don't use them in your own infra. And cost of RPF is lot higher than cost of ACL. Them being

Re: Cogent BCP-38

On 17 August 2017 at 16:11, William Herrin wrote: > Doesn't loose mode URPF allow packets from anything that exists in the > routing table regardless of source? Seems just about worthless. You're > allowing the site to spoof anything in the routing table which is NOT > BCP38.

Re: DevOps workflow for networking

On 11 August 2017 at 19:34, Leo Bicknell wrote: Hey, > For a lot of the devices with a Cisco-IOS like interface it's not even > hard. Generate a code snippet: > > config terminal > interface e0 > description bar > end > write mem > > Then tftp the config to a server, have the

Re: Long AS Path

Hey, Uou're saying, you drop long AS_PATH, to improve customer observed latency? Implication being, because you dropped the long AS_PATH prefixes, you're now selecting shorter AS_PATH prefixes to the FIB? Absent of this policy, in which scenario would you have inserted the filtered longer

Re: RFC2544 Testing Equipment

Cool. Seems you're using AF_PACKET, which makes it actually unique. iperf/netperf etc use UDP or TCP socket, so UDP performance is just abysmal, you can't saturate 1GE link with any reliability. So measuring for example packet loss is not possible at all. I've been meaning to write AF_PACKET

Re: Cisco NCS5501 as a P Router

On 18 May 2017 at 16:21, Erik Sundberg wrote: Hey, > We're at the growing point where we need a dedicated P router for a core > device. We are taking a serious look at the NCS5501. Is there anyone else > using a NCS5501 as P Router or just general feedback on the

Re: BCP for securing IPv6 Linux end node in AWS

On 14 May 2017 at 16:49, Eric Germann wrote: Hey, > For example, on the IPv4 side, there arguably is no value to timestamp > requests and address mask requests externally, so dump them. It's very dangerous proposal when we start considering everything 0 value which

Re: Need recommendation on an affordable internet edge router

On 5 May 2017 at 01:04, c b wrote: Hey, > The ASR9k is certainly up to the task and it's one of the few we looked at > initially, but the pricing is nowhere near commodity even if we got a > minimal build. What is commodity? Where are you comparing it to which

Re: Need recommendation on an affordable internet edge router

On 4 May 2017 at 23:39, c b wrote: > * Affordable. I know that's subjective, but we need a solution that is as > close as possible to commodity-pricing if this modernization effort balloons > to include all of our data centers. How many? For any non-trivial volume

Re: SLA Monitoring

On 12 April 2017 at 01:57, Mike Hammett wrote: Hey, > What do you guys use for monitoring of SLAs, be it an upstream or a > downstream SLA? I know of a couple services, just looking to see who's doing > what and how they like it. It might be useful to understand what type

Re: BGP Route Reflector - Route Server, Router, etc

On 20 March 2017 at 18:59, James Bensley wrote: >> Mark is spot on, this is an important point. We just added ORR to SR OS >> 15.0.R1 on the 7x50/VSR. > > Yes, which means we all know what we have do to. Everyone needs to > join in to increase the pressure. When talking to

Re: External BGP Controller for L3 Switch BGP routing

On 16 January 2017 at 16:53, Tore Anderson wrote: Hey, > (Server) --10GE--> (T2 leaf X) --40GE--> (T2 spine) --40GE--> > (T2 leaf Y) --10GE--> (IP-transit/"the Internet") --10GE--> (Client) > > If I understand you correctly you're saying this is a "suspect" topology > that cannot

Re: External BGP Controller for L3 Switch BGP routing

On 16 January 2017 at 14:36, Tore Anderson wrote: > But here you're talking about the RTT of each individual link, right, > not the RTT of the entire path through the Internet for any given flow? I'm talking about RTT of end-to-end, which will determine window-size, which will

Re: External BGP Controller for L3 Switch BGP routing

On 16 January 2017 at 08:40, Tore Anderson wrote: Hey, > Do you know of any traditional «Internet scale» router that can do ~720 > Gbps of throughput for less than 10x the price of a Trident II box? Or > even <100kUSD? (Disregarding any volume discounts.) It's really hard to talk

Re: External BGP Controller for L3 Switch BGP routing

On 14 January 2017 at 07:32, Jeremy Austin wrote: Hey, > https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html --- As described in a prevous post, we’re testing a HPE Altoline 6920 in our lab. The Altoline 6920 is, like other switches based on the

Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

On 12 January 2017 at 21:53, Fernando Gont wrote: > besides, becaude of ipv6 ehs, you're not really guaranteed to receive e.g. > the tcp header in the embedded payload (the embedded payload could easily be > fixed ipv6 header + ehs). If the CoPP drops what has not been

Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

On 12 January 2017 at 17:02, Fernando Gont wrote: > That's the point: If you don't allow fragments, but your peer honors > ICMPv6 PTB<1280, then dropping fragments creates the attack vector. Thanks. I think I got it now. Best I can offer is that B could try to verify the

Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

On 12 January 2017 at 13:19, Fernando Gont wrote: Hey, > I'm curious about whether folks are normally filtering ICMPv6 PTB<1280 > and/or IPv6 fragments targeted to BGP routers (off-list datapoints are > welcome). Generally may be understood differently by different

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

On 6 December 2016 at 14:28, Job Snijders wrote: > Liberal translation below. The big take-away for operators is that > service providers need to make it part of the MPLS Psuedo-wire > troubleshooting procedure to ask the customer which MACs are involved > and raise the red

Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

On 2 December 2016 at 18:16, Alia Atlas wrote: > This sounds related to the well-known (at least 10+ years) issues around > guessing the > type of IP packet by looking at the first nibble of the encapsulated packet. > Take a quick look at RFC 7325, section 2.4.5.1 bullet 6. >

Re: BFD on back-to-back connected BGP-speakers

On 29 November 2016 at 20:23, Hugo Slabbert wrote: Hey, > - eBGP with peering to interface addresses (not loopback) > - no multi-hop > - direct back-to-back connections (no intermediate devices except patch > panels) > > Possible failure scenarios where I could see this

Re: 10G tester recommendations?

On 5 October 2016 at 15:54, Bryan Holloway wrote: > Mainly RFC2544 and physical media. QoS could be handy, but it's not as > important as proving that the circuit is meeting our expectations from the > carrier(s). Then then EXFO is fine and much more affordable than Spirent or

Re: 10G tester recommendations?

On 3 October 2016 at 22:09, Bryan Holloway wrote: > We're in the market for a hand-held 10G ethernet tester, and I was curious > if the NANOG community had any recommendations or experiences they would be > willing to share, negative or positive. What are you looking to test?

Re: nexus N3K-C3064PQ vs juniper ex4500 in order to protect against ddos

On 1 October 2016 at 18:12, James Jun wrote: > We also want support contracts from our vendors. EOL boxes get removed from > support availability within few years of the announcement. Support, particularly software maintenance is indeed the key deadline, after that

Re: nexus N3K-C3064PQ vs juniper ex4500 in order to protect against ddos

On 1 October 2016 at 10:03, Pedro wrote: > We had situations, that we lost all our bgp sessions, not even only on ports > where flood was coming. Just cpu overloaded. I don't care about support too > much, there are cheap enough to have spare. What is the device you're

Re: nexus N3K-C3064PQ vs juniper ex4500 in order to protect against ddos

On 30 September 2016 at 22:42, Pedro wrote: Hey Pedro, > I have some idea to put switch before bgp router in order to terminate isp > 10G uplinks on switch, not router. Main reason is that could be some kind of > 1st level of defence against ddos, second reason, less

Re: Operations task management software?

On 27 July 2016 at 21:16, David Hubbard wrote: Hey, > Hi all, curious if anyone has recommendations on software that helps manage > routine duties assigned to operations staff? I'd solicit opinions as well. There are few features I'd like to see: 1) ability to

Re: EVERYTHING about Booters (and CloudFlare)

On 28 July 2016 at 19:27, chris wrote: > They don't discriminate, anyone can be a customer > https://www.youtube.com/watch?v=T4GfoSZ_sDc > > great quote from the reporter "why do you need a court order to do the > right thing?" Only failure here is accepting interview request

Re: Leap Second planned for 2016

On 10 July 2016 at 00:12, wrote: > It doesn't help that the POSIX standard doesn't represent leap seconds > anyplace, so any elapsed time calculation that crosses a leap second > is guaranteed to be wrong So how can we solve the problem? Immediately and long term?

Re: Leap Second planned for 2016

On 9 July 2016 at 22:09, wrote: > well, we've gone through a few of these now...so if it was all okay before > its likely to be again... exception: any NEW code that > you are running since last time - THAT hasnt been tested ;-) In most cases the bugs are not

Re: Leap Second planned for 2016

On 9 July 2016 at 04:39, Patrick W. Gilmore wrote: Hey, > But time _DOES_ flow. The seconds count > 58, 59, 60, 00, 01, … > If you can’t keep up, that’s not UTC’s fault. Check the implementation on your PC. This is why code is broken and people don't even know it's

Re: Leap Second planned for 2016

On 9 July 2016 at 02:27, Jared Mauch wrote: > Time is actually harder than it seems. Many bits of software break in > unexpected ways. Expect the unexpected. Aye. How many have written code like this: start = time(); do_something(); elapsed = time() - start; Virtually

Re: IPv6 deployment excuses

On 4 July 2016 at 17:33, Matt Hoppes wrote: > The simple fact that there is/are IP broker exchanges now simply proves there > are surplus IPs to go around. I'm unsure of the message. Is the statement that if commodity is tradable, there is surplus to go

Re: 1GE L3 aggregation

On 18 June 2016 at 18:37, James Jun wrote: Hey, > One issue with pushing IP transit (L3-wise) with small boxes down to the > metro is that if a particular customer comes under attack, any DDoS in > excess of 10-30 Gbps is going to totally destroy the remote site down to

Re: 1GE L3 aggregation

On 17 June 2016 at 16:25, Colton Conor wrote: > Thats some extreme level of unheard discount to get a full MX80 for 3K. Yeah it's best I've seen. 8-10k isn't anything special. -- ++ytti

Re: 1GE L3 aggregation

On 17 June 2016 at 16:17, Colton Conor wrote: > Whats the price piont though? Is that the router he was saying in 15K range? I'm all Shania Twain on 15k. I've seen people buy MX80 for bit over 3k, this isn't that much denser. 5k would impress me much. -- ++ytti

Re: 1GE L3 aggregation

On 17 June 2016 at 15:58, Colton Conor wrote: > What size FIB/RIB table does that Huawei have? It has 25M RIB and 4M FIB. Same Solar NPU as their largest kit. -- ++ytti

Re: 1GE L3 aggregation

On 17 June 2016 at 13:10, Harald F. Karlsen wrote: > What about the Huawei NE20E-S2F/NE40E-M2F? > 4 * SFP+ and 40 * SFP fixed ports and two PICs with either 4*SFP+ or 1*QSFP > each. Decent FIB. Not really sure about the IPFIX/sflow thought. Pricing > seems very aggresive on

Re: 1GE L3 aggregation

On 16 June 2016 at 22:36, Baldur Norddahl wrote: Hey, > If I need to speak BGP with a customer that only has 1G I will simply make > a MPLS L2VPN to one of my edge routers. We use the ZTE 5952E switch with > 48x 1G plus 4x 10G for the L2VPN end point. If that is not

Re: Barefoot "Tofino": 6.4 Tbps whitebox switch silicon?

On 16 June 2016 at 06:21, Eric Kuhnke wrote: > Based on their investors, could have interesting results for much lower > cost 100GbE whitebox switches. Why lower cost? The BOM isn't the expensive part, the code is the expensive part. Only way I see this happening, is if we

1GE L3 aggregation

Hey, I've been bit poking around trying to find reasonable option for 1GE L3 full BGP table aggregator. It seems vendors are mostly pushing Satellite/Fusion for this application. I don't really like the added complexity and tight coupling Satellite/Fusion forces me. I'd prefer standards based

Re: GRE on ASR9001

calculate this > using "BRKSPG-2904" or is this a result of your own testing? > > On Fri, May 27, 2016 at 11:40 AM, Saku Ytti <s...@ytti.fi> wrote: >> >> On 27 May 2016 at 11:28, Rukka Pal <rege...@gmail.com> wrote: >> >> > I believe this should pr

Re: GRE on ASR9001

On 27 May 2016 at 11:28, Rukka Pal wrote: > I believe this should present no significant problems to the ASR9001, just > wanted to get a confirmation. Thanks! Performance will be about 15Mpps per NPU. -- ++ytti

Re: LLDP via SNMP

On 26 May 2016 at 17:47, Avi Freedman wrote: > For those who are monitoring LLDP, how have you found the SNMP MIB support > support for it on Juniper, Cisco, Brocade, Arista, and others? I've written this to crawl network with CDP+LLDP+SNMP and produce JSON or dotty

Re: Network traffic simulator

On 25 May 2016 at 23:34, Sabri Berisha wrote: > This depends very much on which Ixia product you're using. In IxExplorer and > IxNetwork require a lot of manual labor when setting up a test. IxLoad has a > little less, but still. It is important to realize that most of

Re: Network traffic simulator

Ugh. In all cases below, where it says Agilent it should say IXIA. > Many times in QoS testing you'd have EF, AF, BE > traffic, and you have expectation how many percentage in given > situation should given class drop, doing this in Agilent is a chore. > > Agilent probably has best in the breed

Re: Network traffic simulator

On 24 May 2016 at 23:04, Spencer Ryan wrote: Hey, > We are heavily invested in Ixia, they are very expensive, but if you need > the kind of precision they provide they work very well. I've used all big three, Agilent (back in packets and protocols), IXIA and Spirent. And

Re: Friday's Random Comment - About: Arista and FIB/RIB's

On 29 April 2016 at 13:25, Nick Hilliard wrote: >> The more paths you receive from different sources, the more likely it >> is that this list of 120k "superfluous" prefixes will converge >> towards zero. > > Agreed that small numbers of paths are most unlikely to create the >

Re: NCS5K?

On 26 April 2016 at 07:02, Colton Conor wrote: > Do you actually think that Cisco would sell at NCS 5501 at the price point > that Arista is going to sell a 7280R for? Spec wise they are very similar > (except Arista has 8 more SFP+ ports and two more 100G ports). Arista

Re: Arista Routing Solutions

On 24 April 2016 at 09:08, Colton Conor wrote: Hey, > I guess you are right the QFX10002-36Q is probably a better comparison. But > let's be honest, Juniper is not going to sell a QFX10002-36Q for less than > $20k like Arista will do for a semi- similar box. Even with a

Re: Arista Routing Solutions

On 24 April 2016 at 05:14, Keith Medcalf wrote: > High Touch / Low Touch High touch means very general purpose NPU, with off-chip memory. Low touch means usually ASIC or otherwise simplified pipeline and on-chip memory. Granted Jericho can support off-chip memory too. L3

Re: Arista Routing Solutions

On 23 April 2016 at 10:52, Tom Hill wrote: > In broad strokes: for your money you're either getting port density, or > more features per port. The only difference here is that there's > suddenly more TCAM on the device, and I still don't see the above > changing too

Re: Internet Exchanges supporting jumbo frames?

On 10 March 2016 at 02:44, Niels Bakker

Re: Internet Exchanges supporting jumbo frames?

On 10 March 2016 at 00:01, Nick Hilliard wrote: > Other people would be fine with 1522 core because that suits both their > needs and equipment limitations. So what do you do? Go with 9100 > because it suits you, or 9000 because that's what lots of other people > use? Or 4470

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 22:56, Nick Hilliard wrote: > - hardware problems If we build everything on LCD, we'll have Internet where just HTTP/80 works on 576B. You can certainly find platform which has problems doing else. > - lack of interest among ixp participants outside

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 22:28, Nick Hilliard wrote: > iirc, we had problems with a bunch of ios based platforms. It worked > fine on junos / xr platforms. I share your surprise that this could > even have caused a problem, but it did. This is very poor reason to kill it for

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 21:46, Nick Hilliard wrote: > I've spent a good deal of time and effort trying to get a jumbo peering > vlan to work and it didn't work for the reasons that I've mentioned, and > others. It works and has worked 2 decades in real IXP. -- ++ytti, boy who

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 20:59, Nick Hilliard wrote: > There is a critical difference between these two situations. In the case of > an arp sponge, the ixp operator has control of both the polling and the > workaround. In the case of mtu management they would only have control of

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 20:25, Nick Hilliard wrote: > any ixp configuration which requires active polling to ensure correct > configuration is doomed to failure. You are completely overestimating > human nature if you believe that the IXP operator can make this work by > harassing

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 20:14, Nick Hilliard wrote: > you're recommending that routers at IXPs do inflight fragmentation? I'm suggesting IXP has active poller which detects customer MTU misconfigs. -- ++ytti

Re: Internet Exchanges supporting jumbo frames?

On 9 March 2016 at 16:34, Job Snijders wrote: > > https://www.nanog.org/sites/default/files/wednesday.general.steenbergen.antijumbo.pdf IXP can verify if MTU is too large or too small with active poller. Poller in the IXP has too large MTU, it tries to send ping packets

Re: remote serial console (IP to Serial)

On 9 March 2016 at 07:36, Doug McIntyre wrote: Hey, > I'd get something like a 1U ATOM server ($120 eBay) with small SSD > ($18). Runup your favorite FOSS OS, and conserver. For more than the > single real serialport, you can most likely fit a USB hub inside > the case

Re: IPV6 planning

On 6 March 2016 at 03:08, Karl Auer wrote: > To support SLAAC with prefix lengths other than 64 you would have to > break numerous standards. RFC2464 is very clear on the matter, at least > for Ethernet interfaces, though RFC 4862 is carefully non-committal. Yes, SLAAC,

Re: IPV6 planning

On 6 March 2016 at 00:59, Karl Auer wrote: > Other thing with SLAAC is that you get 64-bit subnets and only 64-bit > subnets. This should not be any kind of problem with a flat /48, but if > you will have more complicated subnetting you should keep an eye on it. Technically

Re: Juniper PTX1000

On 2 March 2016 at 19:59, Peter Kranz wrote: > Anyone played with the newish Juniper PTX1000 platform? Seems quite > interesting for compact deployments, but I've not been able to find much > pricing information to see just how interesting.. I would expect it to be priced

Re: sFlow vs netFlow/IPFIX

On 29 February 2016 at 17:40, Phil Bedard wrote: > It would be interesting to get some data from vendors on what the actual > limitation is. I know with some new platforms like the NCS 55XX from Cisco > (BRCM Jericho) it has limited space for counters, but I don’t know

Re: sFlow vs netFlow/IPFIX

On 29 February 2016 at 15:05, Nick Hilliard wrote: > depends on what you define by "cheap". Netflow requires separate packet > forwarding lookup and ACL handling silicon. That's not inherently so, it depends how specialised your hardware is. If it's very specialised like

Re: sFlow vs netFlow/IPFIX

On 29 February 2016 at 14:17, wrote: > A relevant question might be if the Trio hardware can do 1:1 while > handling multiple ports of line rate DDoS traffic consisting of small > packets with different port numbers (i.e. high pps traffic resulting > in basically 1 flow per

Re: sFlow vs netFlow/IPFIX

On 28 February 2016 at 22:06, 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

Re: sFlow vs netFlow/IPFIX

On 29 February 2016 at 04:24, Roland Dobbins 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. I

Re: Cisco ASR9010 vs Juniper MX960

On 18 February 2016 at 15:45, Colton Conor wrote: Hey, > I would like opinions of the differences between these two platforms if > possible. Summary, I think MX is better HW and SW right now. Warning, rant incoming. I liked ASR9k lot more before I needed to

Re: Dear Windstream engineers

On 1 February 2016 at 08:17, joel jaeggli wrote: Hey, > source based RTBH requires urpf, which while generally available may > have practical limitations on implementation. I'd say uRPF/loose is one way to do it on some platforms. In JunOS for longest time it was not

Re: IX ARP Timeout

Hey, > So I'm looking at the policies, recommended configurations, etc. of other > IXes. We try to model a lot of ourselves on what the Europeans do (even if we > come up short in some areas). I was reading through the AMS-IX guide. > >

Re: IGP choice

On 23 October 2015 at 08:31, Mark Tinka wrote: Hey, > Quagga is an example of a case where IS-IS is seriously lagging behind > OSPF to the point of not being useable at all. I believe this is because you need 802.3 (as opposed to EthernetII) and rudimentary CLNS

Re: IGP choice

On 23 October 2015 at 11:54, Mark Tinka wrote: Hey, > Well, on the basis that an attack is made easier if you are running > IS-IS on a vulnerable interface, in theory, an attack would be highly > difficult if a vulnerable interface were not running IS-IS to begin with.

Re: sfp "computer"?

On 21 October 2015 at 21:01, Dave Taht wrote: Hey Dave, > These have been around for a while and looked awesome. > > http://www.rad.com/10/Ethernet-Demarcation-SFP/24944/ > > There was a great ad for it to, not sure if it was this one: > >

Re: Recent trouble with QUIC?

On 25 September 2015 at 16:20, Ca By wrote: Hey, > I remained very disappointed in how google has gone about quic. > > They are dismissive of network operators concerns (quic protocol list and > ietf), cause substantial outages, and have lost a lot of good will in the >

Re: Recent trouble with QUIC?

On 27 September 2015 at 18:38, Lyle Giese wrote: > Part of freedom is to minimize the harm and I think that is where the > parties replying to this thread diverge. A broken change that causes harm > should have/could have been tested better before releasing it to the

Re: buffer bloat and packet pacing

Hey Brett, > Here's a paper that shows you don't need buffers equal to > bandwidth*delay to get near capacity: > http://www.cs.bu.edu/~matta/Papers/hstcp-globecom04.pdf > (I'm not endorsing it. Just pointing out it out as a datapoint.) Quick glance makes me believe the S and D nodes are equal

buffer bloat and packet pacing

Hey, In past few years there's been lot of talk about reducing buffer depths, and many seem to think vendors are throwing memory on the chips for the fun of it. If we look at some particularly pathological case. Let's assume sender is CDN network with 40GE connected server and receiver is 10GE

Re: buffer bloat and packet pacing

> only serialise them 10GE out, causing majority of that 375MB ending up > in the sender side switch/router buffers. s/sender/receiver/ -- ++ytti

Re: buffer bloat and packet pacing

On 3 September 2015 at 15:04, Nick Hilliard wrote: > optimally, but tcp slow start will generally stop this from happening on > well behaved sending-side stacks so you send up ramping up quickly to path > rate rather than egress line rate from the sender side. This assumes

Re: How long will it take to completely get rid of IPv4 or will it happen at all?

On (2015-06-27 07:38 -0700), Bob Evans wrote: Hey Bob, What will come first ? A) the earths future core rotation changes altering the ionosphere in such a way that we are all exposed to continuous x-rays that shorten our lifespan As a firm believer of sustainable development I furiously

Re: REMINDER: LEAP SECOND

On (2015-06-22 14:44 +0200), Stephane Bortzmeyer wrote: Or simply use TAI which is the obvious time reference for Internet devices. Using UTC in routers is madness. Routers and Internet servers should use TAI internally and use UTC only when communicating with humans (the inferior life form

<    1   2   3   4   5   6   7   8   9   >