Re: WKBI #586, Redploying most of 127/8 as unicast public
On Thu, 2021-11-18 at 10:51 +, Nick Hilliard wrote: > The ask is to update every ip stack in the world (including > validation, > equipment retirement, reconfiguration, etc) and the gain is 4 weeks > of > extra ip address space in terms of estimated consumption. (Not to mention the static 127.in-addr.arpa zone that pretty much every resolver has configured by default these days.) The burn rate is the best argument I've seen against the idea so far. -- Steven signature.asc Description: This is a digitally signed message part
Re: Announcing Peering-LAN prefixes to customers
Hi Dominic, On Thu, 2018-12-20 at 19:15 +0100, Dominic Schallert wrote: > Dear Job, Michael, Ross, > thank you very much for sharing your opinion, the detailed info and > references. That’s pretty much what I excpected. > Just wondered because I couldn’t find any IXP Conection Agreement > stating this „issue“ explicitly yet. > > Maybe MANRS IXP actions has some recommendations regarding this, > checking that now. We don't have it in our connection agreement as such, but it is in section 3.2 of our (admittedly aged) Configuration Guide: https://ams-ix.net/technical/specifications-descriptions/config-guide#3.2 3.2. Peering LAN Prefix The IPv4 prefix for the AMS-IX peering LAN (80.249.208.0/21) is part of AS1200, and is not supposed to be globally routable. This means the following: 1. Do not configure "network 80.249.208.0/21" in your router's BGP configuration (seriously, we have seen this happen!). 2. Do not redistribute the route, a supernet, or a more specific outside of your AS. We (AS1200) announce it with a no-export attribute, please honour it. In short, you can take the view that the Peering LAN is a link-local address range and you may decide to not even redistribute it internally (but in that case you may want to set a static route for management access so you can troubleshoot peering, etc.). AFAIK, pretty much all IXP operators take this view. Cheers, Steven > Best wishes and happy holidays > > Cheers > Dominic > > > > Am 20.12.2018 um 19:06 schrieb Michael Still > > : > > > > IXP LANs should not be announced via BGP (or your IGP either). See > > section 3.1: > > http://nabcop.org/index.php/BCOP-Exchange_Points_v2 > > > > > > > > On Thu, Dec 20, 2018 at 12:50 PM Dominic Schallert < > > d...@schallert.com> wrote: > > > Hi all, > > > > > > this might be a stupid question but today I was discussing with a > > > colleague if Peering-LAN prefixes should be re- > > > distributed/announced to direct customers/peers. My standpoint is > > > that in any case, Peering-LAN prefixes should be filtered and not > > > announced to peers/customers because a Peering-LAN represents > > > some sort of DMZ and there is simply no need for them to be > > > reachable by third-parties not being physically connected to an > > > IXP themselves. Also from a security point of view, a lot of new > > > issues might occur in this situation. > > > > > > I’ve been seeing a few transit providers lately announcing (even > > > reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) > > > to their customers. I’m wondering if there is any document or RFC > > > particularly describing this matter? > > > > > > Thanks > > > Dominic > > > > > > -- > > [stillwa...@gmail.com ~]$ cat .signature > > cat: .signature: No such file or directory > > [stillwa...@gmail.com ~]$ signature.asc Description: This is a digitally signed message part
Re: Open source Netflow analysis for monitoring AS-to-AS traffic
On Fri, 2024-03-29 at 00:15 +, Nick Hilliard wrote: > Overall, sflow has one major advantage over netflow/ipfix, namely > that > it's a stateless sampling mechanism. Precisely. From my corner of the industry, my use case for flow data is extremely limited: I need (sampled) frame information: src-mac, dst- mac, qtag, ethernet protocol, framesize, sample rate. sFlow provides that in every sample, in a straighforward manner. (Never mind that the vendor we use does interesting things with the way they sample.) IPFIX, by comparison, is a nightmare: to understand the data records, you need to have seen (and stored) the corresponding data template first. Those records will contain most of the information I need, *except* the sampling rate, which comes from an options data record... which you first have to match to an options template. Then, the sampling rate may not be present, but the sampling probability can be. Slightly different semantics. So that's four types of records your collector may receive. There is also at least one vendor that believes it's perfectly fine to export those over different transport sessions (read: different UDP source ports), which makes it really hard to do load balancing on the receiving side. To top it off, both the sFlow and IPFIX specs are sufficiently vague about the meaning of the "frame size", so vendors can implement whatever they want (include/exclude padding, include/exclude FCS). This implies that you shouldn't trust these fields. Ah, well. -- Steven signature.asc Description: This is a digitally signed message part
Re: Open source Netflow analysis for monitoring AS-to-AS traffic
Hi Peter, Thanks for that link. I did read the spec, and while the definition itself is clear, the escape clause gives a lot of wiggle room: "Hardware limitations may prevent an exact reporting of the underlying frame length, but an agent should attempt to be as accurate as possible." I read that as, "the vendor will do whatever it pleases, and you should be grateful to receive a non-negative integer at all." I could be too cynical, though. Anyway, this particular vendor does other funny things (such as sometimes stripping the q-tag headers from the sampled frame; throttling the frame sampling on the box, but not adjusting the sampling interval in the sFlow exports) that make it a true joy to work with this gear. ;-) Cheers, -- Steven
Re: What Eyeballs Did During The Facebook Nap
Hi Mark, On Fri, 2021-10-08 at 16:18 +0200, Mark Tinka wrote: Could Netflix, perhaps, play a part in mitigating the increasing impact of social media addiction in teenagers, whose young brains aren't developed enough to have sufficient executive control, impulse control and good judgement? My inner cynic is interpreting this data a bit differently. Instead of going out for a walk or just engage in the gentle art of doing nothing, the social media users need something to keep their minds distracted from the here and now. Anything to avoid having to do any kind of self-reflection or, heaven forbid, live in the moment. And I fear that it doesn't apply to adolescents only... Best, Steven
