Re: Flowspec IPv6
Hi Eric, with no v6 fs rules, the table inet6flow.0 stay hidden. Try to make any. -- S pozdravem/Best Regards, Zbyněk Dne 21.05.21 v 20:10 Eric Dugas via NANOG napsal(a): > Hello, > > I've been fiddling with JunOS to enable Flowspec IPv6. According to the > docs, it was implemented in 16.x. I've tried to set it up in vRR and vMX > in the 20.x train. Everything commit just fine, I get the inetflow.0 for > IPv4 but inet6flow.0 is not appearing. > > I already have a JTAC case (now escalated to ATAC) but I am looking for > plan B. > > Has anyone implemented Flowspec v6? I was thinking about FRRouting but I > wanted to get some feedback from the community before spending more > hours into this. > > Thanks > Eric
Re: BFD for routes learned trough Route-servers in IXPs
Hi, In some IXPs, getting a BFD protected BGP sessions with their route-servers is possible. However, it is usualy optional, so there is no way how to discover know who of your MLPA peering partners has their sessions protected the same way and who don't. You can also ask peers you have a session with to enable BFD there. If they run carrier-grade border routes connected to IXP switches just with fibers, it works pretty well. So just try to talk with your peers about BFD. -- S pozdravem/Best Regards, Zbyněk Pospíchal Dne 16.09.20 v 2:55 Douglas Fischer napsal(a): > Time-to-time, in some IXP in the world some issue on the forwarding > plane occurs. > When it occurs, this topic comes back. > > The failures are not big enough to drop the BGP sessions between IXP > participants and route-servers. > > But are enough to prejudice traffic between participants. > > And then the problem comes: > "How can I check if my communication against the NextHop of the routes > that I learn from the route-servers are OK? > If it is not OK, how can I remove it from my FIB?" > > Some other possible causes of this feeling are: > - ARP Resolution issues > (CPU protection and lunatic Mikrotiks with 30 seconds ARP timeout is a > bombastic recipe) > - MAC-Address Learning limitations on the transport link of the > participants can be a pain in the a..rm. > > > So, I was searching on how to solve that and I found a draft (8th > release) with the intention to solve that... > https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08 > > If understood correctly, the effective implementation of it will depend > on new code on any BGP engine that will want to do that check. > It is kind of frustrating... At least 10 years after the release of RFC > until the refresh os every router involved in IXPs in the world. > > > Some questions come: > A) There is anything that we can do to rush this? > B) There is any other alternative to that? > > > P.S.1: I gave up of inventing crazy BGP filter polices to test > reachability of NextHop. The effectiveness of it can't even be compared > to BFD, and almost kill de processing capacity of my router. > > P.S.2: IMHO, the biggest downside of those problems is the evasion of > route-servers from some participants when issues described above occurs.
Whois vs GDPR, latest news
Dne 17/05/2018 v 15:03 Niels Bakker napsal(a): > * na...@ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]: >> Agreed. This is garbage, un-needed legislation. > > Disagreed. These are great and necessary regulations.> > I'm loving the flood of convoluted unsubscribe notices this month from > companies that had stored PII for no reason. Those who would give up essential liberty, to purchase a little temporary safety(*), deserve neither liberty nor safety(*). (*) you can replace this word with comfort in this case without loosing the point This is what all the regulation fans still not understood. Regards, Zbynek
Re: OSPF vs ISIS - Which do you prefer & why?
Dne 10.11.16 v 11:17 James Bensley wrote: >> * Integrated IPv4/IPv6 protocol support in a single IGP implementation. > > This is in OSPv3. In theory, yes. In the real world operators need MPLS label distribution, which is still not supported in many implementations. Regards, Zbynek
Re: BCP38 adoption "incentives"?
Dne 27.09.16 v 16:30 Mikael Abrahamsson napsal(a): > The first page was completely devoid of any real technical information > until I found the PDF (which from the color choice doesn't even look > like a link). (https://www.nix.cz/cs/file/NIX_RULES_FENIX) > > It's still not obvious what the FENIX connection is used for from that > PDF. It's called "last resort connection". What does that mean? It means that a network suffering massive DDoS can switch off their transit and peering links and turn itself to anything like "island mode" operation, still keeping access to some of root and local TLD DNS servers, local content and/or local users. Fortunately, it has been never used except tests, but it is still an option when a network is in such kind of trouble. > Apart from that, it looks more like https://www.routingmanifesto.org/ in > that organisations that have joined are stating that they will follow > some operational guidelines (which make a lot of sense), but it's not > that much more technical when it comes to inter-provider traffic Routing manifesto cannot provide you anything in the oposite if you comply it, except, maybe, good feeling. Fenix (or Dutch Trusted Network Initiative) project can. Best Regards, Zbynek
Re: BCP38 adoption "incentives"?
Dne 27.09.16 v 15:17 Mikael Abrahamsson napsal(a): > Hm, so the IX operator looks at packets at the IX (sFlow perhaps), see > who is sending attack packets, and if they're spoofed, this ISP is then > put in "quarantine", ie their IX port is basically now useless. Definitely not. Try to read first instead of speculations. Regards, Zbynek
Re: BCP38 adoption "incentives"?
The implementation of BCP38 over local market strongly increased after massive DDoS attacks in 2013 affecting major part of the industry thanks to an initiative of the most important local IXP. There is a special separate last-resort "island mode" network, which is intended to be activated in case of really major attacks to keep an accessibility of (at least) local services for local users. Implementation of BCP38 is one of the (lot of) requirements. Positive motivation is definitely better than asking politicians for regulations. More: https://fe.nix.cz/en/ Regards, Zbynek Dne 27.09.16 v 14:46 Mikael Abrahamsson napsal(a): > On Tue, 27 Sep 2016, Stephen Satchell wrote: > >> You have to make their ignorance SUBTRACT from the bottom line. > > I'd say there is no way to actually achieve this. BCP38 non-compliance > doesn't hurt the one not in compliance in any significant amount, it > hurts everybody else. > > The only way I can imagine BCP38 ever happening widely is by means of > legislation, which of course is really hard because Internet spans > countries/continents. > > Doing anti-spoofing should be done at the edge, the further up into the > core you try to do it, the bigger risk you're breaking lots of users' > connectivity, causing customer complaints. > re > In some countries I'm sure BCP38 compliance could be increased by means > of legislation and fining companies that do not do BCP38 filtering. But > before we do that, we need to agree that BCP38 compliance is a must. I > don't think we're there. I have heard people say that if they don't > allow some of their customers to spoof, they're losing business, because > some customers have built complete (deployed) solutions that are built > on the fact that they can spoof packets. These people will have to be > convinced that they're doing it wrong and re-design their solutions. > This is going to cost them dearly, so they're going to be upset. > > With all the IoT devices out there, do people even need to spoof anymore? >
Re: NANOG67 - Tipping point of community and sponsor bashing?
Dne 16.06.16 v 17:17 Niels Bakker napsal(a): > * zby...@dialtelecom.cz (Zbyněk Pospíchal) [Thu 16 Jun 2016, 14:23 CEST]: >> Are you sure they still want them if they have to pay for these >> features separately? >> >> Currently, such luxury functions are increasing costs also for >> networks who don't need/want it. > > sFlow statistics isn't a luxury function. Anything more than plain L2 in an IXP is a kind of luxury. An IXP member with it's own flow collection (or at least mac accounting) can feel they don't need sFlow statistics in an exchange. It's also proven it's possible to run an IXP, including a big one, without sFlow stats. We can say the same about route servers, SLA, customer portals etc. (ok, remote peering is a different case). If IXP members think they have to pay such functionality in their port fees, ok, it's their own decision, but member's opinion "we don't need it and we don't want to pay for it" is rational and plausible. Best Regards, Zbynek
Re: NANOG67 - Tipping point of community and sponsor bashing?
Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a): > Well, the customers also wanted more functions and features. They wanted > sFLOW statistics to show traffic, customer portals, better SLAs, > distributed IXes, remote peering, more hand-holding when connecting etc. Are you sure they still want them if they have to pay for these features separately? Currently, such luxury functions are increasing costs also for networks who don't need/want it. Best Regards, Zbynek
