Re: constant FEC errors juniper mpc10e 400g

[JÁKÓ András]

> What "all the ethernet control frame juju" might you be referring
> to?  I don't recall Ethernet, in and of itself, just sending stuff back and
> forth.

I did not read the 100G Ethernet specs, but as far as I remember
FastEthernet (e.g. 100BASE-FX) uses 4B/5B coding on the line, borrowed
from FDDI. Octets of Ethernet frames are encoded to these 5-bit
codewords, and there are valid codewords for other stuff, like idle
symbols transmitted continuously between frames.

Gigabit Ethernet (1000BASE-X) uses 8B/10B code on the line (from Fibre
Channel). In GE there are also special (not frame octet) PCS codewords
used for auto-negotiation, frame bursting, etc.

So I guess these are not frames that you see, but codewords representing
other data, outside Ethernet frames.

András

Re: Texas internet connectivity declining due to blackouts

[JÁKÓ András]

> I have lived in France and now Hungary. I have never seen power lines
> above ground, but I have heard there are some in rural France.

You'll find them even in Budapest:

https://www.google.com/maps/@47.4720119,19.1245507,3a,75y,127.74h,82.44t/data=!3m6!1e1!3m4!1sWCy2Wa7XFx751XnTwI4ZEA!2e0!7i16384!8i8192
https://www.google.com/maps/@47.4326756,19.0117106,3a,75y,258.31h,97.99t/data=!3m6!1e1!3m4!1shghXkZI-u04Nh_Y-b_MbiA!2e0!7i16384!8i8192
https://www.google.com/maps/@47.4530487,19.1693045,3a,75y,202.63h,100.06t/data=!3m6!1e1!3m4!1soSuaHQbCGTcdj-DoRhbYew!2e0!7i16384!8i8192

András

Re: Lawsuits for falsyfying DNS responses ?

[JÁKÓ András]

On Mon, Sep 12, 2016 at 04:08:08PM -0400, William Herrin wrote:
> On Mon, Sep 12, 2016 at 1:41 PM, Jean-Francois Mezei
>  wrote:
> > To do so, it will provide ISPs with list of web sites to block
> >
> > Are there examples of an ISP getting sued because it redirected traffic
> > that should have gone to original site ?
> 
> Hi,
> 
> You're talking about two different things here: blocking a DNS domain
> and redirecting a domain.

Blocking for that purpose usually means redirecting in practive. You'll
redirect to a page that explains why the original site is not available.

András

Re: DHCPv6 PD & Routing Questions

[JÁKÓ András]

> Well the requesting router could announce the route.  ISC's client
> has hooks that allow this to be done.  That is, after all, how
> routing is designed to work.  The DHCP server usually is sitting
> in a data center on the other side of the country with zero ability
> to inject approptiate routes.
> 
> The DHCP relay could also have injected routes but that is a second
> class solution.

A CPE announcing the route is fine as long as the ISP controls the CPE.

If the CPE is controled by the customer, then the ISP's problems are
similar. They need to find a way to filter the CPE's announcement so
that it can announce only the prefixes delegated to it.

András

Re: valley free routing?

[JÁKÓ András]

 It's that business deal I want to hear about. When A-B and B-C are
 free peering but the traffic goes A-B-C for some reason other than a
 misconfiguration or deliberate abuse. On or off list, I'd like to know
 about real-life use cases where folks do this on purpose.

As far as I understand some NRENs do that in Europe. Check out AS1853
and AS-ACONETTOVIX in the RIPE whois. A networks are the peers a VIX,
B is ACONET, C networks are CESNET, SANET, and PIONIER.

DTAG's looking glass shows this path to SANET:

sh ip bgp regexp _2607_
BGP table version is 0, local router ID is 217.239.38.165
Status codes: s suppressed, d damped, h history, * valid,  best, i -
internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network  Next HopMetric LocPrf Weight Path
*i147.175.0.0  194.25.5.150  100  0 1853 2607 i
*i147.213.0.0  194.25.5.150  100  0 1853 2607 i
*i147.232.0.0  194.25.5.150  100  0 1853 2607 i
*i158.193.0.0  194.25.5.150  100  0 1853 2607 i
*i158.195.0.0  194.25.5.150  100  0 1853 2607 i
*i158.197.0.0  194.25.5.150  100  0 1853 2607 i
*i192.108.130.0194.25.5.150  100  0 1853 2607 i
*i192.108.131.0194.25.5.150  100  0 1853 2607 i
*i192.108.132.0/23 194.25.5.150  100  0 1853 2607 i
*i192.108.138.0194.25.5.150  100  0 1853 2607 i
*i192.108.149.0194.25.5.150  100  0 1853 2607 i
*i193.87.0.0/16194.25.5.150  100  0 1853 2607 i
*i194.1.0.0/17 194.25.5.150  100  0 1853 2607 i
*i194.160.0.0/16   194.25.5.150  100  0 1853 2607 i
Total number of prefixes 14

Regards,
András

Re: Cogent IPV6 connectivity to fireball.acr.fi

[JÁKÓ András]

 IPV6 connectivity to fireball.acr.fi is failing inside Cogent AS174.  I
 have already contacted the Cogent NOC, but I haven't heard anything back
 yet. I'm wondering if somebody else with Cogent IPV6 connectivity can
 run some tests.   IPV4 connectivity is working fine.  

It works from AS2547 through Cogent:

PING6(56=40+8+8 bytes) 2001:738:2001:2001::c -- 2001:1bc8:100d::2
16 bytes from 2001:1bc8:100d::2, icmp_seq=0 hlim=52 time=57.356 ms
16 bytes from 2001:1bc8:100d::2, icmp_seq=1 hlim=52 time=57.499 ms
16 bytes from 2001:1bc8:100d::2, icmp_seq=2 hlim=52 time=57.889 ms
^C
--- fireball.acr.fi ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 57.356/57.581/57.889/0.225 ms


traceroute6 to fireball.acr.fi (2001:1bc8:100d::2) from
2001:738:2001:2001::c, 64 hops max, 12 byte packets
 1  vl100.taz.net.bme.hu  0.730 ms  0.389 ms  0.369 ms
 2  tg0-1-0-1.rtr.bme.hbone.hu  1.116 ms  0.839 ms  0.590 ms
 3  * * *
 4  2001:978:2:27::7:1  1.227 ms  0.979 ms  0.942 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * 2001:978:2:3f::6  46.962 ms
12  2001:1bc8:1:7:0:d:0:1  47.060 ms *  47.309 ms
13  2001:1bc8:100:100:5::2  55.083 ms !N  54.830 ms !N  62.167 ms !N


$ telnet -6 fireball.acr.fi 80
Trying 2001:1bc8:100d::2...
Won't send login name and/or authentication information.
Connected to fireball.acr.fi.
Escape character is '^]'.
GET
!DOCTYPE HTML public -//W30//DTD W3 HTML 3.0//EN
HTML
HEAD
TITLEThe Home Page of Tero Kivinen/TITLE
LINK REL=Up HREF=http://www.iki.fi/;
LINK REL=Home HREF=index.html
LINK REV=made HREF=mailto:kivi...@iki.fi;
/HEAD


András

Re: TCP time_wait and port exhaustion for servers

[JÁKÓ András]

 Ray,

 With a 60 second timeout on TIME_WAIT, local port identifiers are tied
 up from being used for new outgoing connections (in this case a proxy
 server).  The default local port range on Linux can easily be
 adjusted; but even when bumped up to a range of 32K ports, the 60
 second timeout means you can only sustain about 500 new connections
 per second before you run out of ports.

Is that 500 new connections per second per {protocol, remote address, 
remote port} tuple, that's too few for your proxy? (OK, this tuple is more 
or less equivalent with only {remote address} if we talk about a web 
proxy.) Just curious.

Regards,
András

Re: Big Temporary Networks

[JÁKÓ András]

  just a small comment: As far as I understand AP isolation doesn't work
  if you don't have a WLAN controller but do have more than one APs. E.g. in
  the following setup
 
  ap1--sw1--sw2--ap2
 
  with AP isolation turned on, clients associated to ap1 cannot
  communicate directly with other clients associated to ap1, however they
  can communicate directly with those associated to ap2. Broadcast from
  ap1's clients does also get to all clients at ap2.
 
 Hi András,
 
 This is one place where Cisco's switchport protected comes in handy.

Yes, but only as long as all APs are connected to the same switch, as I 
understand. (That's why I put two switches in the example above.)

 You can get the same effect with other brands. For example, in one
 on-the-cheap 5-AP hotspot I did, I vlaned the APs (using an older
 802.1q capable switch) back to a Linux bridge with ebtables --insert
 FORWARD --jump DROP. The Linux bridge was also the default router out
 of the wlan, so anything *to* the router worked but anything that
 would be forwarded was dropped instead. Works great.

Nice, that should do the trick with multiple switches too.

Regards,
András

Re: Big Temporary Networks

[JÁKÓ András]

 Second, in the hotspot scenarios where this is likely to be a problem
 (in IPv4 -or- IPv6) it's addressed by the AP isolation feature
 that's getting close to omnipresent even in the low end APs. With this
 feature enabled, stations are not allowed to talk to each other over
 the wlan; they can only talk to hosts on the wired side of the lan.

Not related to the original subject, neither to IPv6 usability on WLANs, 
just a small comment: As far as I understand AP isolation doesn't work 
if you don't have a WLAN controller but do have more than one APs. E.g. in 
the following setup

ap1--sw1--sw2--ap2

with AP isolation turned on, clients associated to ap1 cannot 
communicate directly with other clients associated to ap1, however they 
can communicate directly with those associated to ap2. Broadcast from 
ap1's clients does also get to all clients at ap2.

Regards,
András