Re: [swinog] Swinog #34 Ride on 30th - Geneva and Lausanne

[Vincent Bernat]

Same train from Lausanne for me.
-- 
Make the coupling between modules visible.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: "lucas.dousse" 
 Sent: 29 octobre 2018 20:08 +0100
 Subject: Re: [swinog] Swinog #34 Ride on 30th - Geneva and Lausanne
 To: Will van Gulik; swi...@swinog.ch

> I will be taking the train at 07:20 from Lausanne, in 2nd class. Tell me 
> where you will be on the train.
> Cheers, Lucas 
>  Message d'origine De : Will van Gulik
>  Date : 29.10.18 19:47 (GMT+01:00) À :
> swi...@swinog.ch Objet : [swinog] Swinog #34 Ride on 30th - Geneva and
> Lausanne
> Hey Swinogers,
>
> FYI I will be taking the train at 6:42 from GVA, in 2nd class. If
> anyone wanna join me, I'll try to take some space for those stepping
> in in Lausanne.
>
> Cheers and see you all tomorrow ! :)
>
> Will
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] BGP LLGR, followup

[Vincent Bernat]

Hey!

A quick followup for my lightning talk from last year about BGP LLGR:

 - Support has been added in BIRD 1.6, BIRD 2 and GoBGP. AFAIK, Cisco
   still only supports it on VPN and FlowSpec families.
 
 - Draft 4 has been published and IANA has assigned capability code and
   well-known comunity (compatible with existing implementations).

https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-04
https://vincent.bernat.ch/en/blog/2018-bgp-llgr
-- 
Make sure all variables are initialised before use.
- The Elements of Programming Style (Kernighan & Plauger)


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] IRR and trust

[Vincent Bernat]

 ❦ 11 mars 2018 09:54 +0100, Vincent Bernat <ber...@luffy.cx> :

>> Did you try contacting radb.net or the ARIN first? Their answers would
>> be interesting about it.
>
> As I am not familiar with how things work, I did not. But I have mailed
> CloudFlare NOC.

They told me the entries are legit as they are running some experiments
with APNIC from their ASN.
-- 
My only love sprung from my only hate!
Too early seen unknown, and known too late!
-- William Shakespeare, "Romeo and Juliet"


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] IRR and trust

[Vincent Bernat]

 ❦ 11 mars 2018 09:49 +0100, Vincent Jardin  :

> Did you try contacting radb.net or the ARIN first? Their answers would
> be interesting about it.

As I am not familiar with how things work, I did not. But I have mailed
CloudFlare NOC.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] IRR and trust

[Vincent Bernat]

 ❦ 10 mars 2018 23:02 +0100, Vincent Bernat <ber...@luffy.cx> :

> I am peering with Atlantic Metro at DE-CIX. Their IRR record is
> "AS-AMC". I have noticed recently some invalid prefixes:
>
> $ bgpq3 -4 -R 24 -m 24 -A -J -E AS-AMC
> [...]
>   route-filter 1.0.0.0/24 exact;
>   route-filter 1.1.1.0/24 exact;
>
> I didn't check which members of the macro pulled those prefixes (is
> there an easy way to get where it comes from?) but I thought information
> from IRR records were veted by RIR. It seems this is not the case. Is it
> because some RIR don't check anything or just because there is no way to
> secure such a macro? In this case, what is the best practice when
> peering with such a transit provider?

Those two routes are from CloudFlare (just got it by luck):

http://irrexplorer.nlnog.net/search/AS13335

So ARIN doesn't check anything?
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] IRR and trust

[Vincent Bernat]

Hey!

I am peering with Atlantic Metro at DE-CIX. Their IRR record is
"AS-AMC". I have noticed recently some invalid prefixes:

$ bgpq3 -4 -R 24 -m 24 -A -J -E AS-AMC
[...]
  route-filter 1.0.0.0/24 exact;
  route-filter 1.1.1.0/24 exact;

I didn't check which members of the macro pulled those prefixes (is
there an easy way to get where it comes from?) but I thought information
from IRR records were veted by RIR. It seems this is not the case. Is it
because some RIR don't check anything or just because there is no way to
secure such a macro? In this case, what is the best practice when
peering with such a transit provider?

Thanks!
-- 
It were not best that we should all think alike; it is difference of opinion
that makes horse-races.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] RIPE database and more specific routes

[Vincent Bernat]

Hey!

I am updating the route/inetnum objects in the RIPE database and I am
wondering if I have to create more specific route objects. For example,
I have the following routes announced:

 - 89.145.160.0/21
 - 89.145.160.0/22 (FR7)
 - 89.145.164.0/23 (DK2)
 - 89.145.166.0/23 (GV2)

Each more specific route is announced in a different location. Should I
create only the top route object or should I create a route object for
each announce?

If I look at bgpq3, I see by default, it uses exact matches:

$ bgpq3 -4 -J -E AS61098 | grep 89.145
route-filter 89.145.160.0/21 exact;
route-filter 89.145.160.0/22 exact;
route-filter 89.145.164.0/23 exact;
route-filter 89.145.166.0/23 exact;

However, I use it this way:

$ bgpq3 -R 24 -4 -J -E AS61098 | grep 89.145
route-filter 89.145.160.0/21 upto /24;

But I am concerned some people may build filters using only exact
matches, so it seems safer to have route objects for more specifics.
-- 
If more of us valued food and cheer and song above hoarded gold, it would
be a merrier world.
-- J.R.R. Tolkien


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] TCP timestamps

[Vincent Bernat]

 ❦ 10 mars 2016 17:12 +0100, Andre Keller  :

> in the last few months we had several security audits and all of them
> proposed to disable tcp timestamps. (i.e. on Linux
> net.ipv4.tcp_timestamps=0). AFAIK roundtrip time calculation in tcp
> relies on this and there might be implications for PAWS (tcp sequence
> number wrapping).
>
> What do you guys think about this?

By disabling it, the effective bandwidth of the TCP connections may
decrease quite a bit (much of RFC7323 relies on timestamps) and you
deprive yourself of some interesting workarounds when handling many
connections (RFC 1337 and the likes).
-- 
Soap and education are not as sudden as a massacre, but they are more
deadly in the long run.
-- Mark Twain


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Swisscom 6RD and MTU

[Vincent Bernat]

Hi!

At home, I have replaced Swisscom internet box by my own (Linux)
router. For IPv6, I noticed that the MTU is 1472 instead of 1480 (1500 -
20). For IPv4, MTU is 1500.

Does anyone know why the MTU on those 6RD links has to be 1472 and not
1480? Have other people with the same setup noticed that too?
-- 
printk(HPFS: G... Kernel memory corrupted ... going on, but 
it'll crash very soon :-(\n);
2.4.3 linux/fs/hpfs/super.c


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] chrome ipv6-only vpn targets not accessible.

[Vincent Bernat]

 ❦ 16 juillet 2014 15:40 +0200, Andre Keller a...@list.ak.cx :

 we have customers that run basically an IPv6-only infrastructure with
 some ipv4 reverse proxies in front of the services that need to be
 publicly available. Some of these internal services can be accessed
 using a VPN. The VPN connection will provide a static IPv6 address for
 the client and a route to the ipv6 only servers will be pushed so
 traffic goes through the VPN.

 In chrome the above does not work if the client has no global IPv6
 access (i.e. an IPv6 default route). It just does not resolve 
 records as it seems, because access with literals (such as
 http://[2001:db8::1]) works.

 Does anybody know if there is a knob to alter this behavior? Other
 tested browsers are Firefox, Opera, Midori and Lynx which seem to work
 fine.

Hi Andre!

There is a flag --enable-ipv6:
 http://peter.sh/experiments/chromium-command-line-switches/

You can also check by visiting:
 chrome://net-internals/#dns

Chrome is testing if there is a functional IPv6 functionality. With only
a partial connectivity, the test is failing. Maybe you could also
advertise two default routes 0::/1 and 8000::/1 through the VPN to fix
that (and routes the IPv6 probes that Chrome tries to send).
-- 
 /* James M doesn't say fuck enough. */
2.4.3 linux/net/core/netfilter.c


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog