Re: Open source Netflow analysis for monitoring AS-to-AS traffic

[Vincent Bernat]

Without much information, I think this is more likely that you are 
running out of disk space.


On 2024-06-05 23:15, Javier Gutierrez wrote:

Hi everyone,
I've been trying to get Akvorado to work on my environmnet but I keep 
getting the flows to stop collecting, it seems like the issue is related 
to the number of exporters I have sending data, can someone please share 
the max number they have gotten to work and the flows/s rate without the 
system crashing?


Thanks in advance for your answers.

*From:* NANOG  on 
behalf of Steven Bakker 

*Sent:* Sunday, March 31, 2024 4:53 AM
*To:* Peter Phaal 
*Cc:* nanog@nanog.org 
*Subject:* Re: Open source Netflow analysis for monitoring AS-to-AS traffic

*CAUTION: *This email is from an external source. Do not click links or 
open attachments unless you recognize the sender and know the content is 
safe.


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: Open source Netflow analysis for monitoring AS-to-AS traffic

[Vincent Bernat]

On 2024-03-27 09:09, Marinos Dimolianis wrote:
My only "concern" was that it did not provide an API for consuming data 
externally.


This is very high on my todo list, notably because I don't want to 
reimplement Grafana. The API already exists (the current web interface 
uses it) but it is not "stable" (it may change in future versions).

Re: Akvorado Resource Requirements

[Vincent Bernat]

On 2023-03-24 15:01, Graham Johnston via NANOG wrote:

For anyone running Akvorado, can you please comment on resource requirements. 
I'm most concerned with CPU and memory, with the assumption that resources are 
somewhat linear to flow rate, but also curious about disk usage secondarily.



A VM with 64 GB, 24 vCPU can sustain about 100k flows/s.

1 TB seems enough to keep data for about 5 years at 30k flows/s with the 
default setup. This is however highly dependent on how well your flows 
can be compressed. The main table with the default retention can use 
around 600 GB by itself. The data compresses well outside of the main table.


You should test on your setup and let it run for a few days. You can 
check how much space each table uses and extrapolate depending on the 
TTL set on each table.

Re: rsync CVE-2022-29154 and RPKI Validation

[Vincent Bernat]

On 2022-09-09 19:36, Matt Corallo wrote:

The attacker is still limited to the target directory. The attacker 
can send files that were excluded or not requested, but they still end 
up in the target directory. RPKI validators download stuff in a 
dedicated download directory


Ah, okay, thanks, its a shame that wasn't included in any of the 
disclosure posts I managed to find :(


It's explained in the manual page: 
https://manpages.debian.org/unstable/rsync/rsync.1.en.html#MULTI-HOST_SECURITY



(but it may be shared with several peers)


I assume I'm mis-reading this - RPKI servers aren't able to overwrite 
output from other RPKI servers, so it shouldn't be shared, no?


Yes, it shouldn't, but maybe RPKI servers are still downloading all of 
them in a single directory. Looking at cfrpki, it looks like it works 
this way (didn't test).

Re: rsync CVE-2022-29154 and RPKI Validation

[Vincent Bernat]

On 2022-09-09 04:56, Matt Corallo wrote:
Has anyone done an analysis of the rsync CVE-2022-29154 (which "allows 
malicious remote servers to write arbitrary files inside the directories 
of connecting peers") and its potential impact on RPKI validators? It 
looks like both Debian [1] and Ubuntu [2] opted *not* to patch rsync in 
their release/security package streams.


Are rsync-based (or rsync-fallback, which I believe is still required 
for all RPKI validators?) RPKI validators all vulnerable to takeover 
from this, or is there some reason why this doesn't apply to RPKI 
validation?


The attacker is still limited to the target directory. The attacker can 
send files that were excluded or not requested, but they still end up in 
the target directory. RPKI validators download stuff in a dedicated 
download directory (but it may be shared with several peers), so they 
should be safe.

Re: dump of NOS config examples

[Vincent Bernat]

Here are some real word configurations: 
https://github.com/jerikan-network/cmdb/tree/generated-public/output 
(including IOS, JunOS and IOS-XR, but no NX-OS).


On 2022-08-20 18:25, guardian.wheel9...@fastmail.com wrote:

Hi,

I am looking for a large dump of example, real but scrubbed, whatever, 
nx-os, junos, panos, ios, eos, hell any common NOS, configs. (Right now 
I really need nx-os but I'll get to the rest soon)


To be clear, I am not looking for anyone's private config or network 
info. I just need a large sample of configs to test some config parsing 
code I have. Looking for every random ugly feature / config option out 
there. The bigger and uglier the better. (Files that still even have the 
horrid control chars ^M, \r\n and worse that come out of network devices 
are the best!!)


Once again, not looking for hack dump of random company X(though I'll 
take anything legal). Hoping to not going fishing in malware infested 
waters for questionable zip files. While I cannot really think of what 
kind of source would give me what I am looking for on the up and up, 
that's what I am hoping for.


Thanx for any help anyone can provide.

Re: 40G QSFP+ to 4 SFP+ on MX960

[Vincent Bernat]

 ❦ 25 February 2022 00:46 +03, Paschal Masha:

> Has anyone managed to get the 40G QSFP+ to 4 SFP+ breakout cable to work on 
> the 2X40GE QSFPP Juniper MICs? 
>
> Which commands did you use to channelize the port under the "chassis
> fpc" mode to get it to channelize to 4x10g at least for one 40G port
> on that MIC?

That's explained here:
https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet/topics/topic-map/port-speed-configuration.html

"set chassis fpc 0 pic 0 port 0 speed 10g" enables the split to 4x10G.
You should get xe-0/0/0:0, xe-0/0/0:1, xe-0/0/0:2 and xe-0/0/0:3. The
"number-of-sub-ports" is not mandatory (at least on MX10003, never tried
on MX960).
-- 
If you tell the truth you don't have to remember anything.
-- Mark Twain

Re: SRv6 Capable NOS and Devices

[Vincent Bernat]

 ❦ 11 January 2022 09:16 -06, Colton Conor:

> I know the SRv6 is a fairly new technology. I am wondering which
> vendors and network operating systems fully support SRv6 today? Has
> anyone deployed this new technology?

Cisco on NCS devices have full support of SRv6 F1 (End, End.X, End.T,
End.DX4, End.DT4, End.DX6, End.DT6, End.DX2, with PSP/USD or USP,
H.Encaps.*), without any EVPN (so not End.DT2U AFAIK), from 7.2,
depending on hardware (Jericho 2-based platforms need 7.5). There may be
hardware restriction on the smaller NCS (NCS540). However, Cisco is
switching to SRv6 F3216, aka microsegments. The same behaviours are
supported. Beware there is a gap between being on the datasheet and not
running into various bugs. Staying close to what Cisco promotes will
help avoiding some bugs. With ISIS as an IGP, there is also support for
TI-LFA and FlexAlgo.

Juniper supports SRv6 F1 on MX, with the same feature set. Nokia
supports it too on the 7750 SR. No support from Arista yet.

Iliad deployed SRv6 in Italy (and partly in France), with Cisco.

> If building a greenfield regional ISP network, would SRv6 be a
> requirement?

Dunno. This is still super young and you restrict the number of vendors
you can select and interoperate with. Also note that SRv6 F3216 RFC is
not out yet and Cisco is already asking customers to move away from SRv6
F1. AFAIK, other vendors are still on F1. Starting with SRv6 now may be
a bit of a gamble because of that. Latest draft is here:

https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-12

> My understanding is that because it's using IPv6 in the dataplane, not
> all devices have to have SRv6 enabled. The in-between core devices
> just have to support IPv6, but not necessarily support SRv6. This is
> much different than traditional MPLS networks today where all devices
> have to support MPLS/LDP correct?

That's correct.
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)

Re: ROA mirror to IRR?

[Vincent Bernat]

 ❦ 26 October 2021 10:17 -10, Shawn:

> Curious if any IRR databases are mirroring/importing ROA data - creating
> route|6 objects from ROA?

This is a feature of IRRd 4: https://irrd.readthedocs.io/en/stable/admins/rpki/

> IRR questions:
> How do most large networks maintain (automate) their IRR records?
> Is it standard practice to accept more specifics (append IPv4 "le /24" and
> IPv6 "le /48")?
>  Or is it expected to have one IRR route per BGP announcement?

IMO, many accept more specifics, but you shouldn't rely on this under
normal circumnstance.
-- 
Make sure input cannot violate the limits of the program.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Juniper hardware recommendation

[Vincent Bernat]

In addition to the QSA, note that 40G LR optics are using CWDM. You can
therefore get 1270, 1290, 1310 and 1330 out of the optic. Not the
favorites channels, but if that's OK for you, configure it as a 4x10G on
the Juniper side.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

-Original Message-
From: Adam Thompson 
Sent: 14 mai 2021 13:30 GMT
Subject: RE: Juniper hardware recommendation
To: Bjørn Mork
Cc: nanog@nanog.org

> OK, enough people have pointed it out :-).
>
> Clearly I was wrong about the MX 2K family, I missed the SFP+ MIC completely. 
>  That is good to know.
>
> However, the MX 10k family still only shows as being compatible with
> two QSFP cards. And yes, you can get a QSFP-SFP+ breakout cable, but
> those don't let you use SFP+ CWDM/DWDM transceivers.
>
> -Adam
>
> Adam Thompson
> Consultant, Infrastructure Services
> MERLIN
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>
>> -Original Message-
>> From: Bjørn Mork 
>> Sent: Saturday, May 8, 2021 6:32 AM
>> To: Adam Thompson 
>> Cc: Javier Gutierrez Guerra ; nanog@nanog.org
>> Subject: Re: Juniper hardware recommendation
>> 
>> Adam Thompson  writes:
>> 
>> 
>> >   * Skip the MX 2k/10k series – they don’t support SFP+ interfaces!
>> 
>> https://apps.juniper.net/hct/model/?component=MX2K-MPC6E
>> https://apps.juniper.net/hct/model/?component=MIC6-10G
>> 
>> 
>> Bjørn

Re: Juniper hardware recommendation

[Vincent Bernat]

 ❦  7 mai 2021 21:14 GMT, Adam Thompson:

>   * Skip the MX 2k/10k series – they don’t support SFP+ interfaces!
> (“No 10G WDM for you!”) Also no 1G, you need a separate step-down
> switch for that. I don’t know what SP Juniper thinks they’re targeting
> with these.

The 10k can take 10G SFP+ using an adapter. It works fine, but this can
feel like a waste. Something like that:

https://www.fs.com/fr/products/72582.html?attribute=2692=80750

This is seen as a 4x breakout cable.

>   * 1U/2U EX/QFX are reasonable edge devices as long as you’ve
> verified they can do what you need. Not core-router class IMHO.

QFX10k is different from the others. From my experience, it is very
capable and the "Q" versions are quite versatile (many port
configurations, cheap), but Juniper is trying to push the new PTXs with
the same hardware, but not the same price tag, this is a bit confusing.
I don't do MPLS, so I may not see its limitations, but it supports
several full views and is the flagship for BGP EVPN VXLAN implementation
for Juniper.
-- 
The devil can cite Scripture for his purpose.
-- William Shakespeare, "The Merchant of Venice"

Re: Trident3 vs Jericho2

[Vincent Bernat]

 ❦  9 avril 2021 17:20 +03, Saku Ytti:

> If we'd change TCP sender to bandwidth estimation, and newly created window
> space would be serialised at estimated receiver rate then we would need
> dramatically less buffers. However this less aggressive TCP algorithm would
> be outcompeted by new reno reducing bandwidth estimation to approach zero.
>
> Luckily almost all traffic is handled by few players, if they agree to
> change to well behaved TCP (or QUIC) algorithm, it doesn't matter much if
> the long tail is badly behaving TCP.

I think many of them are now using BBR or BBR v2. It would be
interesting to know how it impacted switch buffering.
-- 
As flies to wanton boys are we to the gods; they kill us for their sport.
-- Shakespeare, "King Lear"

Re: Linux router network cards

[Vincent Bernat]

 ❦ 24 octobre 2020 09:55 -06, Keith Medcalf:

> And do not use an Intel CPU.  
>
> Intel only has 4x PCIe lanes that are shared out into whatever
> configuration they claim to have and are totally unsuitable for use in
> a computer that actually has to be able to do high-speed I/O.

That's likely to be incorrect. Intel CPU usually have 48 lanes for the
Skylake generation. The 4 lanes limitation only applies to what is
connected over DMI to the PCH, which is usually used for low-bandwidth
stuff (1G NIC, SATA, 1x PCIe slots). Look at your motherboard manual to
check how many lanes are affected to each component.
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Gaming Consoles and IPv4

[Vincent Bernat]

 ❦ 30 septembre 2020 09:45 -07, Owen DeLong:

> Games want to go peer-to-peer.

Not sure about that. To avoid cheaters, multiplayer games are likely to
be mediated by a server running the same game engine to manage state of
each player.
-- 
Noise proves nothing.  Often a hen who has merely laid an egg cackles
as if she laid an asteroid.
-- Mark Twain

Re: AS16509 Peering Contact

[Vincent Bernat]

 ❦ 18 septembre 2020 21:03 +03, Paschal Masha:

> Any Techie from AS16509 (Amazon) in here that can help with a peering
> request for Denver and LA Any2 IXs that was sent to peering@amazon for days
> now without a response :)

It takes some time to get an answer from Amazon, but they eventually
answer. Give them a few weeks.
-- 
Avoid multiple exits from loops.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [outages] Major Level3 (CenturyLink) Issues

[Vincent Bernat]

 ❦  2 septembre 2020 16:35 +03, Saku Ytti:

>> I am not buying it. No normal implementation of BGP stays online,
>> replying to heart beat and accepting updates from ebgp peers, yet
>> after 5 hours failed to process withdrawal from customers.
>
> I can imagine writing BGP implementation like this
>
>  a) own queue for keepalives, which i always serve first fully
>  b) own queue for update, which i serve second
>  c) own queue for withdraw, which i serve last

Or maybe, graceful restart configured without a timeout on IPv4/IPv6?
The flowspec rule severed the BGP session abruptly, stale routes are
kept due to graceful restart (except flowspec rules), BGP sessions are
reestablished but the flowspec rules is handled before before reaching
EoR and we loop from there.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [outages] Major Level3 (CenturyLink) Issues

[Vincent Bernat]

 ❦  2 septembre 2020 10:15 +03, Saku Ytti:

> RFC7313 might show us way to reduce amount of useless work. You might
> want to add signal that initial convergence is done, you might want to
> add signal that no installation or best path algo happens until all
> route are loaded, this would massively improve scaled convergence as
> you wouldn't do that throwaway work, which ultimately inflates your
> work queue and pushes your useful work far to the future.

It seems BIRD contains an implementation for RFC7313. From the source
code, it delays removal of stale route until EoRR, but it doesn't seem
to delay the work on updating the kernel. Juniper doesn't seem to
implement it. Cisco seems to implement it, but only on refresh, not on
the initial connection. Is there some survey around this RFC?
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Vincent Bernat]

 ❦ 29 juillet 2020 12:13 +03, Saku Ytti:

>> This is the solution Cumulus is advocating to its users, so I suppose
>> they have some real users behind that. Juniper also supports RFC 5549
>> but, from the documentation, the forwarding part is done using
>> lightweight tunnels.
>
> I'm not sure if you claim otherwise, but no real 'tunneling' takes
> place, as far as I know, it's internal implementation detail having
> IPV6 next-hop for IPV4. I don't think there is any additional headers
> or any additional lookup or cost.

I didn't test, but the documentation states:

> Starting in Release 17.3R1, Junos OS devices can forward IPv4 traffic
> over an IPv6-only network, which generally cannot forward IPv4
> traffic. As described in RFC 5549, IPv4 traffic is tunneled from CPE
> devices to IPv4-over-IPv6 gateways. These gateways are announced to
> CPE devices through anycast addresses. The gateway devices then create
> dynamic IPv4-over-IPv6 tunnels to remote customer premises equipment
> and advertise IPv4 aggregate routes to steer traffic. Route reflectors
> with programmable interfaces inject the tunnel information into the
> network. The route reflectors are connected through IBGP to gateway
> routers, which advertise the IPv4 addresses of host routes with IPv6
> addresses as the next hop.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/multiprotocol-bgp.html#id-configuring-bgp-to-redistribute-ipv4-routes-with-ipv6-next-hop-addresses

If you have a pointer around the subject on Juniper, I would be quite
interested!

Thanks.
-- 
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan & Plauger)

Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?

[Vincent Bernat]

Hello,

This is implemented in FRR and will also be available in BIRD 2.0.8.
Linux accepts IPv6 next-hop for IPv4 natively since 5.3 (no tunnels).
This is the solution Cumulus is advocating to its users, so I suppose
they have some real users behind that. Juniper also supports RFC 5549
but, from the documentation, the forwarding part is done using
lightweight tunnels.

Maybe David Ahern is reading this list and could comment more. I don't
use this solution myself as the vendor support is still quite limited
but if I were to start a network from scratch, I would definitively go
for it.
-- 
Let the machine do the dirty work.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Douglas Fischer 
 Sent: 29 juillet 2020 02:51 -03
 Subject: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?
 To: nanog@nanog.org

> Let's just jump all the arguing about lack of IPv4, the need of IPv6, and
> etc...
>
> I must confess that I don't know all the RFCs.
> I would like it, but I don't!
>
> And today, I reached on https://tools.ietf.org/html/rfc5549
>
> I knew that was possible to transfer v4 routes over v6 BGP sessions, or v6
> routes over v4 BGP sessions.
> But I got surprised when I saw this youtube vídeo of AMS-IX guys
> considering use a v6 only Lan, and doing v6 next-hops to v4 routes.
> https://www.youtube.com/watch?v=uJOtfiHDCMw
>
> Well... I guess that idea didn't go to production.
>
>
>
> But the questions are:
> There is any network that really implements RFC5549?
> Can anyone share some information about it?

Re: looking for operator validation for regexes that extract ASNs

[Vincent Bernat]

 ❦ 11 mai 2020 20:03 +12, Matthew Luckie:

> To support Internet topology analysis efforts, we have been working on
> an algorithm to detect AS numbers inside hostnames (PTR records) for
> router interfaces, and automatically build regular expressions
> (regexes) to extract them.

Hello Matthew,

This work is quite interesting. I see you have also a page to build
regex from router names for each operator. Did you already work on
extracting city names/US states? This would be quite helpful as well.
-- 
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Arista Switches rebooting

[Vincent Bernat]

 ❦  5 mai 2020 09:09 +03, Saku Ytti:

>> We found a bug on the 64 port x 100gig model that if you insert a quad
>> twinax 10gig fanout cable in many of the ports it will trigger a reboot.I
>
> I've seen a similar issue in another vendor, where specific SFP
> inserted would reload the linecard. This was because the SFP didn't
> answer fast enough to I2C queries and the polling code couldn't handle
> the error so it crashed the whole linecard. Vendor didn't fix the
> code, because it didn't happen on vendor optic, while obviously they
> must have understood they can't guarantee vendor optic answers in a
> timely manner in I2C.

We had a similar issue, but vendor fixed the issue (despite it only
happened with cheap third-party optics). If we talk about the same
vendor, it was fixed in 17.3R4, 17.4R3, 17.3R3-S4 and 18.1R3-S4. It's PR
1425893 (not public).
-- 
Man is the only animal that blushes -- or needs to.
-- Mark Twain

Re: "Is BGP safe yet?" test

[Vincent Bernat]

 ❦ 22 avril 2020 12:51 -04, Andrey Kostin:

> BTW, has anybody yet thought/looked into extending RPKI-RTR protocol
> for validation of prefixes received from peer-as to make ingress
> filtering more dynamic and move away prefix filters from the routers?

It could be used as is if the client implementations were a bit more
flexible.

With BIRD, you decide which AS to match. So you can match on the
neighbor AS instead of the origin AS. Then, you can use something like
GoRTR which accepts using JSON files instead of the RPKI as source. BIRD
also allows you to have several ROA tables. So, you can check against
the "real" RPKI as well as against your custom IRR-based RPKI.
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)

Re: FRR as Route-Reflector & Scaling stats

[Vincent Bernat]

 ❦ 15 novembre 2019 09:33 +00, ERCIN TORUN :

> Generally chipset is what limits the scale (e.g. trident2 is 128k ipv4
> lpm https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Routing/ ).
> If you disable "zebra" daemon, FRR works only in control-plane then
> you would most likely have a limitation with memory/RAM only. (speed
> is another issue).

To avoid disabling Zebra daemon, you can use "table-map" to choose the
routes to send to Zebra:


For example:

route-map DENY_ALL deny 10
router bgp 65000 vrf private
 address-family ipv4 unicast
  table-map DENY_ALL
 exit-address-family
-- 
Avoid unnecessary branches.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Request comment: list of IPs to block outbound

[Vincent Bernat]

 ❦ 14 octobre 2019 09:14 +03, Saku Ytti :

>> I think you should seriously re-consider using rp_filter on a router.
>
> rp_filter is one of the most expensive features in modern routers, you
> should only use it, if PPS performance is not important. If PPS
> performance is important, ACL is much faster. ACL is also applicable
> to more scenarios, such as BGP customers.

How much performance impact should we expect with uRPF?

Thanks.
-- 
Make input easy to proofread.
- The Elements of Programming Style (Kernighan & Plauger)

Re: MAP-E

[Vincent Bernat]

 ❦  8 août 2019 16:18 -04, Lee Howard :

> NAT64. IPv6-only to users. DNS resolver given in provisioning
> information is a DNS64 server. When it does a lookup but there's no
> , it invents one based on the A record (e.g., 2001:db8:64:: address>). The IPv6 prefix in the invented  is actually a NAT64
> translator. Pro: no CPE support required, well understood. Con: No
> support for IPv4-only stuff in the prem, breaks DNSSEC.

Is there a known deployment for a medium/large ISP?

Thanks.
-- 
Wrinkles should merely indicate where smiles have been.
-- Mark Twain

Re: NTP for ASBRs?

[Vincent Bernat]

 ❦  8 mai 2019 09:56 +02, Lars Prehn :

> do you NTP sync your AS boundary routers? If so, what are incentives
> for doing so? Are there incentives, e.g. security considerations, not
> to do it?

Ensure you have a firewall rule in place to prevent people to use your
router for NTP amplification. NTP clients are also servers. On Juniper
devices:

policy-options {
prefix-list ntp-servers {
apply-path "system ntp server <*>";
}
}
firewall {
/* ... */
   term accept-ntp {
from {
source-prefix-list {
ntp-servers;
}
protocol udp;
port ntp;
}
then {
policer management-1m;
accept;
}
}
}

(see

for more details).
-- 
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [EXTERNAL] Re: RTBH no_export

[Vincent Bernat]

 ❦  4 février 2019 09:01 +00, i3D.net - Martijn Schmidt 
:

> Cogent does let you use RTBH, but on a separate BGP session to a
> blackhole server. So it's a bit more hassle to set it up policy-wise,
> because it deviates from the standard. Same story for "former
> GlobalCrossing", now CenturyLink's AS3549, which is still used for LATAM
> and Asia.

Cogent will "soon" support a blackhole community on regular BGP
sessions. I've got this information a few months ago, so maybe just ask
for it to make it happen sooner.
-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)

Re: YANG daemeon for Linux

[Vincent Bernat]

 ❦ 27 juillet 2018 12:23 -0700, Karl Jørn  :

> Looking for an agent on Linux that will render YANG models, so I can
> provision networking on Linux.

Maybe looking at this one:
 http://yuma123.org/wiki/index.php/Yuma_netconfd_Manual
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Juniper BGP Convergence Time

[Vincent Bernat]

 ❦ 24 mai 2018 12:36 +0200, Olivier Benghozi  :

> I wonder if this convergence time issue wouldn't be a typical mission for 
> «BGP PIC Edge for MPLS Layer 3 VPNs».
> But it would be necessary to migrate the DFZ to a VPN MPLS (and
> configure composite nexthop and BGP PIC / «Provider Edge Link
> Protection»).

BGP PIC is also available with IP now:
 
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/bgp-configuring-bgp-pic-for-inet.html

I've asked the question two years ago on j-nsp. Here is the thread:
 https://lists.gt.net/nsp/juniper/57149

There is a step by step guide about in the middle of the guide. I didn't
have the right version to test at the time. I didn't try again since
then.
-- 
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Juniper BGP Convergence Time

[Vincent Bernat]

Hey!

This feature is already enabled on MX with MPC cards.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: Adam Kajtar 
 Sent: 23 mai 2018 23:21 -0400
 Subject: Re: Juniper BGP Convergence Time
 To: Mark Tinka
 Cc: nanog@nanog.org

> Hello again:
>
> I've tried using the default route, adjusting bgp timers, and mutlipath.
> Unfortunately, these changes haven't helped much. Juniper support hasn't
> been very helpful also. Although, I think I might have found the solution.
>
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/forwarding-indirect-next-hop.html
>
> Let me know what you think.
>
> On Tue, May 22, 2018, 4:03 AM Mark Tinka  wrote:
>
>>
>>
>> On 16/May/18 18:59, Phil Lavin wrote:
>>
>> Ask if they will configure BFD for you. I’ve not found many transit
>> providers that will, but it’s worth a shot and it will lower failure
>> detection to circa 1 second.
>>
>> We've tended to shy away from it, but we have 2 customers we've done it
>> for.
>>
>> Mark.
>>

Re: Open Souce Network Operating Systems

[Vincent Bernat]

 ❦  3 mai 2018 13:39 -0700, Andrey Khomyakov  :

> 1st is Linux inherently doesn't program the hardware. So if you install
> Ubuntu on some Quanta switch, you still need a way to program the ASIC.
> Cumulus Linux is open source with the exception of switchd, which is what
> they use to take network state from the kernel and program the silicone
> with it. switchd can only program "supported" silicon.

Since a few years, Linux has an offload framework for L2/L3
(switchdev). There is a toy driver (Rocker, supported by QEMU) and
several silicons supported (at least Mellanox Spectrum, but it seems
there are a few others).
-- 
The mind is its own place, and in itself
Can make a Heav'n of Hell, a Hell of Heav'n.
-- John Milton

Re: IPv4 and IPv6 hijacking by AS 6

[Vincent Bernat]

 ❦ 12 avril 2018 13:51 -0500, Matt Harris  :

>> Have you tried their IRR entries? Bull appears to redirect to Atos now
>> (site-wise).
>>
>> notify: ed.gie...@atos.net
>> notify: charlie.mol...@atos.net
>> changed:christophe.fra...@atos.net 20180117  #18:47:40Z
>>
>
> I'm now in touch with Christophe; it looks as though perhaps there's a
> separate, rogue AS 6 running around with a different set of peers/transits,
> as he was able to confirm that none of his gear is advertising these
> prefixes.

Maybe AS6 is used internally by the next AS on the path?
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)

Re: MTU to CDN's

[Vincent Bernat]

 ❦ 19 janvier 2018 08:07 -0600, Mike Hammett  :

> Wouldn't those situations be causing issues now, given the likelihood
> that someone with a less than 1,500 byte MTU is communicating with you
> now?

Those situations are causing issues now. If you have a MTU less than
1500 bytes, it is likely some destination are unreachable to you if you
only rely on PMTUD. People usually rely on TCP MSS for those cases.
-- 
I'll burn my books.
-- Christopher Marlowe

Re: MTU to CDN's

[Vincent Bernat]

 ❦ 19 janvier 2018 08:53 +1000, George Michaelson  :

> if I was an ISP (Im not) and a CDN came and said "we want to be inside
> you" (ewww) why wouldn't I say "sure: lets jumbo"

Most traffic would be with clients limited to at most 1500 bytes.
-- 
Its name is Public Opinion.  It is held in reverence.  It settles everything.
Some think it is the voice of God.
-- Mark Twain

Re: MTU to CDN's

[Vincent Bernat]

 ❦  8 janvier 2018 15:08 -0800, joel jaeggli  :

>> N00b here trying to understand why certain CDN's such as Cloudfare have
>> issues where my MTU is low. For instance if I am using pptp and the MTU is
>> at 1300 it wont work. If I increase to 1478 it may or may not work.
> PMTUD has a lot of trouble working reliability when the destination of
> the PTB  is a stateless load-balancer.

More explanations are available here:
 https://blog.cloudflare.com/path-mtu-discovery-in-practice/
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Carrier IRR Update Frequency

[Vincent Bernat]

 ❦  1 janvier 2018 10:17 -0600, Mike Hammett  :

> Any idea how often Cogent, XO, and Level 3 update their prefix filters
> from the IRRDBs? 

I got a recent answer from Cogent support stating they don't use IRR (at
least for their customers).
-- 
Consider well the proportions of things.  It is better to be a young June-bug
than an old bird of paradise.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Re: WiFi - login page redirection not working

[Vincent Bernat]

 ❦  1 décembre 2017 15:02 +0300, Nikolay Shopik  :

>> DHCP and neighbor discovery can also provide the information of the
>> login page: https://tools.ietf.org/html/rfc7710
>
> I don't think it got support in any os.

It's supported on Linux by Network Manager.
-- 
All things that are, are with more spirit chased than enjoyed.
-- Shakespeare, "Merchant of Venice"

Re: WiFi - login page redirection not working

[Vincent Bernat]

 ❦ 30 novembre 2017 18:26 -0800, Owen DeLong  :

>> SSL requests are.  For example, Google cache's their 301 redirect
>> from http://www.google.com  to
>> https://www.google.com  which means clients
>> that had access while that browser ps stays active will still
>> attempt https instead of http, regardless of what you actually type.
>
> Right, you’re talking about HSTS as I mentioned below.
>
> However, if there’s a well known URL for getting the captive portal to
> work (e.g. http://captive.portal), then we educate users (or
> browsers that they can type captive.portal (or whatever URL we choose)
> instead of google (which was my traditional go to before HSTS,
> I admit) and voila… Problem solved.

You can use http://neverssl.com/.

But as mentioned earlier in the discussion, most OS have a non-HTTPS URL
to detect a captive portal. They can display notifications to the user
when they detect a captive portal. Browsers have that too.

iOS/macOS: http://captive.apple.com/hotspot-detect.html
Windows: http://www.msftncsi.com/ncsi.txt
Ubuntu: http://start.ubuntu.com/connectivity-check
Firefox: http://detectportal.firefox.com/
Chromium: http://clients3.google.com/generate_204

DHCP and neighbor discovery can also provide the information of the
login page: https://tools.ietf.org/html/rfc7710
-- 
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare

Re: Templating/automating configuration

[Vincent Bernat]

 ❦  6 juin 2017 14:30 +0100, Oliver Elliott  :

> I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and
> verify config on switches.

Why not using the builtin ability of ansible for most vendors? (genuine
question)

 http://docs.ansible.com/ansible/list_of_network_modules.html
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: SHA1 collisions proven possisble

[Vincent Bernat]

 ❦ 23 février 2017 21:16 -0500, "Patrick W. Gilmore"  :

> A couple things will make this slightly less useful for the attacker:
>   1) How many people are not going to keep a copy? Once both docs are be
>  found to have the same hash, well, game over.

But if a transaction is automated, it may be too late. For example, if
the document is a bank transfer slip.
-- 
"You have been in Afghanistan, I perceive."
-- Sir Arthur Conan Doyle, "A Study in Scarlet"

Re: SHA1 collisions proven possisble

[Vincent Bernat]

 ❦ 23 février 2017 19:28 -0500, Jon Lewis  :

>>> cost! However this in no way invalidates SHA-1 or documents signed by
>>> SHA-1.
>>
>> We negotiate a contract with terms favorable to you.  You sign it (or more
>> correctly, sign the SHA-1 hash of the document).
>>
>> I then take your signed copy, take out the contract, splice in a different
>> version with terms favorable to me.  Since the hash didn't change, your
>> signature on the second document remains valid.
>>
>> I present it in court, and the judge says "you signed it, you're stuck with
>> the terms you signed".
>>
>> I think that would count as "invalidates documents signed by SHA-1", don't 
>> you?
>
> Depends on the format of the document.  As was just pointed out, and I
> almost posted earlier today, that there are collisions in SHA-1, or
> any hash that takes an arbitrary length input and outputs a fixed
> length string, should be no surprise to anyone.  Infinite inputs
> yielding a fixed number of possible outputs.  There have to be
> collisions.  Lots of them. The question then becomes how hard is it
> find or craft two inputs that give the same hash or one input that
> gives the same hash as another? Doing this with PDFs that look
> similar, which can contain arbitrary bitmaps or other data is kind of
> a cheat / parlor trick.
>
> Doing it with an ASCII document, source code, or even something like a
> Word document (containing only text and formatting), and having it not
> be obvious upon inspection of the documents that the "imposter"
> document contains some "specific hash influencing 'gibberish'" would
> be far more disturbing.

The collision is contained in about 128 bytes. It is easy to hide this
collision in almost any document. You need a common prefix between the
two documents, the collision, then anything you want (you still need a
lot of processing power to get the collision matching your document). It
is a weakness specific to SHA-1. Another same-length hash (like
RIPEMD-160) is not affected.
-- 
The man who sets out to carry a cat by its tail learns something that
will always be useful and which never will grow dim or doubtful.
-- Mark Twain

Re: External BGP Controller for L3 Switch BGP routing

[Vincent Bernat]

 ❦ 16 janvier 2017 14:08 +0200, Saku Ytti  :

> I wonder if true whitelabel is possible, would some 'real' HW vendor,
> of BRCM size, release HW docs openly? Then some integrator could start
> selling the HW with BOM+10-20%, no support, no software at all. And
> community could build the actual software on it.
> It seems to me, what is keeping us away from near-BOM prices is
> software engineering, and we cannot do it as a community, as HW docs
> are not available.

Mellanox with switches like the SN2700. I don't know how open is the
hardware documentation, but they are pushing support for their ASIC
directly into Linux (look at drivers/net/ethernet/mellanox/mlxsw). They
are also contributing to the switchdev framework which will at some
point allow transparent acceleration of the Linux box (switching,
routing, tunneling, firewalling, etc.), as we already have with
CumulusOS.

The datasheet is quite scarce. There is a 88k L2 forwarding entries but
no word for L3. Buffer sizes are not mentioned. But I suppose that
someone interested would be able to get more detailed information.
-- 
"Elves and Dragons!" I says to him.  "Cabbages and potatoes are better
for you and me."
-- J. R. R. Tolkien

Re: External BGP Controller for L3 Switch BGP routing

[Vincent Bernat]

 ❦ 14 janvier 2017 05:24 GMT, Faisal Imtiaz  :

> A while back there was a discussion on how to do optimized (dynamic)
> BGP routing on a L3 switch which is only capable of handing a subset
> of BGP Routing table.
>
> Someone has pointed out that there was a project to do just that, and
> had posted a link to a presentation on a European operator (Ireland ?
> ) who had done some code to take Exabgp and create such a setup..

Maybe: https://github.com/dbarrosop/sir
-- 
The difference between the right word and the almost right word is the
difference between lightning and the lightning bug.
-- Mark Twain

Re: BCP38 deployment [ was Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey ]

[Vincent Bernat]

 ❦ 26 septembre 2016 09:14 CEST, valdis.kletni...@vt.edu :

>> Linux:
>> From /etc/sysctl.conf:
>>
>> # Uncomment the next two lines to enable Spoof protection (reverse-path=20
>> # filter)
>> # Turn on Source Address Verification in all interfaces to
>> # prevent some spoofing attacks
>> net.ipv4.conf.default.rp_filter=1
>> net.ipv4.conf.all.rp_filter=1

Only "all" is needed since the kernel will use the max of all and the
current interface value.

>> Unfortunately, the net.ipv6 equivalents for those do not yet seem to be a
>> thing on Linux.
>
> See net/ipv6/netfilter/ip6t_rpfilter.c
>
> Also, note that a lot of net.ipv4.conf variables also apply to ipv6 (though
> checking the source tree, this isn't one of them, unless it's via a  macro 
> that
> some quick grepping didn't find...)

Yes, it doesn't apply. In Linux, there is no such thing as feature
parity for IPv6. davem said in the past that he didn't want this feature
in IPv6 and was planning to remove it in IPv4 (but I think this will
never happen):
 http://www.spinics.net/lists/netdev/msg166280.html

I am using this instead (assuming ip46tables is iptables + ip6tables):

ip46tables -t raw -N RPFILTER
ip46tables -t raw -A RPFILTER -m rpfilter -j RETURN
iptables   -t raw -A RPFILTER -d 255.255.255.255 -p udp --sport bootpc --dport 
bootps -j RETURN
ip6tables  -t raw -A RPFILTER -m rpfilter --accept-local -m addrtype --dst-type 
MULTICAST -j DROP
ip46tables -t raw -A RPFILTER -m limit --limit 5/s --limit-burst 5 \
   -j NFLOG --nflog-group 99 \
   --nflog-prefix "NF: rpfilter: "
ip46tables -t raw -A RPFILTER -j DROP
ip46tables -t raw -A PREROUTING -j RPFILTER
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)

Re: MTU

[Vincent Bernat]

 ❦ 22 juillet 2016 14:01 CEST, Baldur Norddahl  :

> Until now we have used the default of 1500 bytes. I now have a project were
> we peer directly with another small ISP. However we need a backup so we
> figured a GRE tunnel on a common IP transit carrier would work. We want to
> avoid the troubles you get by having an effective MTU smaller than 1500
> inside the tunnel, so the IP transit carrier agreed to configure a MTU of
> 9216.
>
> Obviously I only need to increase my MTU by the size of the GRE header. But
> I am thinking is there any reason not to go all in and ask every peer to go
> to whatever max MTU they can support? My own equipment will do MTU of 9600
> bytes.

You should always match the MTU of the remote end. So, if your transit
carrier configured 9126 on its side, you should do the same on
yours. There is no MTU discovery at the L2 layer: if you setup the MTU
of your interface at 9600 and you happen to route a 9500-byte packets,
it will be silently dropped by your transit carrier.
-- 
Test input for validity and plausibility.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [j-nsp] Viability of EX4300 in a primarily l3 environment?

[Vincent Bernat]

 ❦  6 août 2014 20:54 +0900, Paul S. cont...@winterei.se :

 Correct me if I'm wrong, but doesn't OSPF require the AFL license
 anyway to be 'legitly' ran?

OSPF does not need a feature license on those models (it is needed on
EX2200). AFL is needed for BGP, IS-IS and MPLS.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan  Plauger)

Re: Upgrade Path Options from 6500 SUP720-3BXL for Edge Routing

[Vincent Bernat]

 ❦ 30 juillet 2014 09:53 +0200, Mark Tinka mark.ti...@seacom.mu :

 IOS XR on the CRS and ASR9000 is based on QNX, which suffers 
 from being only a 32-bit kernel. So even if the hardware 
 will ship with 4GB of RAM, the OS will only see 4GB (I have 
 12GB in my CRS's and 8GB on my ASR9001's). 

What's the point of shipping more memory then? Maybe the OS can only
address 4GB per process but is able to use up to 64GB in total (PAE)?
-- 
Use self-identifying input.  Allow defaults.  Echo both on output.
- The Elements of Programming Style (Kernighan  Plauger)