Re: Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/30/2017 07:38 PM, John R. Levine wrote:
I did a draft of a double signing thing that let the sender say who's 
expected to sign a modified forwarded version.  The big mail systems 
weren't interested.  They want the recipient system to decide.


https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/


Okay, I've now read your draft and have some questions.

How would the !fs tag enable multiple forwarders?

The only way that I can think of is for the originating mail server to 
DKIM sign the message twice, 1st with the classic DKIM-Signature w/o the 
!fs tag, and 2nd with a DKIM-Signature that includes the !fs tag with a 
value of of the recipient's domain.


I would assume that would mean that the recipient could then forward the 
message to a new recipient and that their outgoing mail server would 
also sign twice, 1st with classic DKIM-Signature w/o the !fs tag, and 
2nd with a DKIM-Signature that includes the !fs tag with a value of the 
new recipient's domain.


A1:  DKIM-Signature: ... d=domainA.example ...
A2:  DKIM-Signature: ... d=domainA.example; !fs=domainB.example ...
<1st forward>
B1:  DKIM-Signature: ... d=domainB.example ...
B2:  DKIM-Signature: ... d=domainB.example; !fs=domainC.example ...
<2nd forward>
C1:  DKIM-Signature: ... d=domainC.example ...
C2:  DKIM-Signature: ... d=domainC.example; !fs=domainD.example ...
<3rd forward>
D1:  DKIM-Signature: ... d=domainD.example ...
D2:  DKIM-Signature: ... d=domainD.example; !fs=domainE.example ...
<4th forward>
E1:  DKIM-Signature: ... d=domainE.example ...
E2:  DKIM-Signature: ... d=domainE.example; !fs=domainF.example ...

(I suppose that this pattern could go on forever.)

Is this what you were intending?  A list of DKIM-Signatures linked via 
!fs tags?


If I do understand correctly, I think that it's intriguing.  I'm not 
aware of anything else that would work quite the same way.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

OSPF Monitoring Tool

[Methsri Wickramarathna]

Hi Guys,
Is anyone knows about a Monitoring tool for OSPF ??

~~( ŊëŌ )~~

Re: aggregate6 - a fast versatile prefix list compressor

[Job Snijders]

On Fri, Dec 01, 2017 at 12:35:13PM -0500, Aliaksei Sheshka wrote:
> On Thu, Nov 30, 2017 at 3:07 PM, Job Snijders  wrote:
> > I re-implemented the venerable 'aggregate' tool (by Joe Abley & co)
> > in python under the name of 'aggregate6'. The 'aggregate6' tool is
> > faster and also has IPv6 support.
> >
> > https://github.com/job/aggregate6
>
> Nice!
> "-t" from the "classic" IPv4 "aggregate" would be nice. I've sent a
> pull request.

That's best approach to get things done: make suggestions and submit
patches. Thank you!

Kind regards,

Job

Re: ccTLDs - Become a Registrar

[John McCormac]

On 01/12/2017 18:24, Ryan Finnesey wrote:

I was wonder if anyone within the group has done this research and might be 
able to save me a bit of time.  I am in the process of putting together a new 
Registrar and we would like complete ccTLD coverage.  I know for example CIRA 
(.ca)  has a Canadian Presence Requirement and we have formed a Canadian 
Corporation to meet this requirement.

I am hoping to find what other TLD operators may have similar requirements.


Some have due diligence checks for finance and trade references. 
However, covering all ccTLDs may not be feasible as some of the smaller 
ones (<10K registrations) may still use manual processing of applications.


From what I remember, some of the EU registries may have liberalised 
and a point of presence company/corporation within the EU or even a 
US/Canadian company might be sufficient.


The real issue with ccTLDs for end users will be sorting out the 
requirements for registration. Some ccTLDs like .UK or .ME may have 
relatively liberal/open registration requirements for their most popular 
subdomains (e.g .CO.UK) but have, in the case of .UK, different 
requirements for registering at .UK level. The .EU nominally requires 
registrants to be within or connected to the EU or European Economic 
Area. The .DE ccTLD requires a German point of contact for registrations 
but that might be handled by forming a local company.


The main ccTLDs for any new registar venture would be the ones with a 
liberal registration policy. The more restrictive ones might require a 
lot more handholding and paperwork for the registrants and unless your 
new registrar venture is concentrating on brand protection 
registrations, it might be best to steer clear of these initially.


Most ccTLD markets are heavily dominated by in-country registrars and 
they can be quite difficult for a foreign registrar to gain market 
share. They also have very different dynamics to the legacy TLDs like 
COM/NET/ORG and the gTLDs. The one year renewal rates for some of them 
can be 70% or higher. Web usage also tends to be higher for some ccTLDs 
so a registrant buying a domain name/hosting package is somewhat more 
likely to use that hosting. In a ccTLDs Web Usage Survey I ran last 
month, the Content/No Content rate (the totals of (domain names with 
developed content) / (domain names on holding 
pages/PPC/sales/unavailable/no website) ) for .DE ccTLD was 0.92, .ES 
was 0.48, .EU was 0.37, .FR was 0.58, .UK was 0.39 and .US was 0.13. 
These are based on random 110,000 domain name samples. It is simpler to 
express this as a kind of development rate as the surveys have 
approximately 28 categories of usage. The development rate excludes 
redirects as it is a simple content related metric.


In some markets, the local ccTLD dominates the market and the 
COM/NET/ORG and gTLDs have gone legacy. The main TLD pair for most 
developed markets will be the ccTLD/COM. The NET and ORG generally tend 
to be legacy TLDs rather than attracting high volumes of new 
registrations in these countries. While you may not be concentrating on 
the new gTLDs, if you are targeting markets with a strong ccTLD, also 
consider the new gTLD geo TLD if it is applicable. (.IRISH for Ireland, 
.LONDON, .SCOT, .CYMRU, .WALES for the UK, .BERLIN, .RUHR etc for 
Germany, .RIO for Brazil, .NYC, .VEGAS, .MIAMI for the US etc.) Many of 
these are early stage TLDs (low registration volume and relatively low 
use but that's typical for new gTLDs as some of these seem to be 
following a ccTLD development curve rather than a gTLD development 
curve) but they tend to be different from less precisely targeted new gTLDs.


Regards...jmcc
--
**
John McCormac  *  e-mail: j...@hosterstats.com
MC2*  web: http://www.hosterstats.com/
22 Viewmount   *  Domain Registrations Statistics
Waterford  *  And Historical DNS Database.
Ireland*  Over 516 Million Domains Tracked.
IE *  Skype: hosterstats.com
**

Re: ccTLDs - Become a Registrar

[Marco Prause]

>wow, 256 of 539 report "no" for DNSSEC.

Having a look at the link, it seems it's representing the options of the 
opensrs system and not necessarily the options of the registry.

For .de e.g. the registry DENIC provides DNSSEC.

Just my 2 Cent,
Marco

RE: ccTLDs - Become a Registrar

[Jacques Latour]

That's why we're working on DNSSEC automation, to let the DNS Operator sign the 
zone and automate the provisioning of DS record into the registry without 
registrant or registrar intervention.  Multiple methods and approach being work 
on.  

API for DNS Operator: 
https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-04
Registry full zone polling: 
https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/

Jacques


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Rubens Kuhl
Sent: December 1, 2017 2:36 PM
To: Christopher Morrow 
Cc: nanog@nanog.org
Subject: Re: ccTLDs - Become a Registrar

http://rick.eng.br/dnssecstat/ is more on topic of we what discussing,
although the monitor is interesting too.


Rubens


On Fri, Dec 1, 2017 at 5:35 PM, Rubens Kuhl  wrote:

>
>
> On Fri, Dec 1, 2017 at 5:20 PM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>>
>>
>> On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl  wrote:
>>
>>>
>>> .br also has such requirements. OpenSRS reference chart has a good hint
>>> of
>>> which ccTLDs have such requirements:
>>> http://bit.ly/OpenSRS_TLD_Reference_Chart
>>
>>
>> wow, 256 of 539 report "no" for DNSSEC.
>>
>
> For DNSSEC this one is more reliable:
> http://rick.eng.br/mon/
>
>
> Rubens
>
>
>

Re: ccTLDs - Become a Registrar

[Rubens Kuhl]

http://rick.eng.br/dnssecstat/ is more on topic of we what discussing,
although the monitor is interesting too.


Rubens


On Fri, Dec 1, 2017 at 5:35 PM, Rubens Kuhl  wrote:

>
>
> On Fri, Dec 1, 2017 at 5:20 PM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>>
>>
>> On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl  wrote:
>>
>>>
>>> .br also has such requirements. OpenSRS reference chart has a good hint
>>> of
>>> which ccTLDs have such requirements:
>>> http://bit.ly/OpenSRS_TLD_Reference_Chart
>>
>>
>> wow, 256 of 539 report "no" for DNSSEC.
>>
>
> For DNSSEC this one is more reliable:
> http://rick.eng.br/mon/
>
>
> Rubens
>
>
>

Re: ccTLDs - Become a Registrar

[Rubens Kuhl]

On Fri, Dec 1, 2017 at 5:20 PM, Christopher Morrow 
wrote:

>
>
> On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl  wrote:
>
>>
>> .br also has such requirements. OpenSRS reference chart has a good hint of
>> which ccTLDs have such requirements:
>> http://bit.ly/OpenSRS_TLD_Reference_Chart
>
>
> wow, 256 of 539 report "no" for DNSSEC.
>

For DNSSEC this one is more reliable:
http://rick.eng.br/mon/


Rubens

Re: ccTLDs - Become a Registrar

[sthaug]

> > I am hoping to find what other TLD operators may have similar requirements.
> >
> 
> .br also has such requirements. OpenSRS reference chart has a good hint of
> which ccTLDs have such requirements:
> http://bit.ly/OpenSRS_TLD_Reference_Chart

It might be advisable to verify the data. For instance, the chart claims
no DNSSEC for .no (Norway) - but in reality, .no has been offering DNSSEC
since 2014,

https://www.norid.no/en/registrar/system/videreutvikling/dnssec/omdnssec/

and about 58% of .no domains use DNSSEC - see graph on the right hand side
of https://www.norid.no/en/

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: ccTLDs - Become a Registrar

[Christopher Morrow]

On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl  wrote:

>
> .br also has such requirements. OpenSRS reference chart has a good hint of
> which ccTLDs have such requirements:
> http://bit.ly/OpenSRS_TLD_Reference_Chart


wow, 256 of 539 report "no" for DNSSEC.

Re: CenturyLink VoIP

[Michael Morrison]

It appears there is a major outage in the CenturyLink Network for voip 
customers, potentially on the SS7 side of the network.

Nothing has been confirmed except certain CenturyLink reps have informed me 
that everything West of Colorado is down. I know this to be true for 3 of my 
sites, LAX, SFO, and SEA.



> On Dec 1, 2017, at 8:36 AM, Michael Morrison  
> wrote:
> 
> Need to get ahold of a CTL VoIP tech, 
> 
> Phone queues seem to be down. Any Help is appreciated.
> 
> 

Re: ccTLDs - Become a Registrar

[Rubens Kuhl]

On Fri, Dec 1, 2017 at 4:24 PM, Ryan Finnesey  wrote:

> I was wonder if anyone within the group has done this research and might
> be able to save me a bit of time.  I am in the process of putting together
> a new Registrar and we would like complete ccTLD coverage.  I know for
> example CIRA (.ca)  has a Canadian Presence Requirement and we have formed
> a Canadian Corporation to meet this requirement.
>
> I am hoping to find what other TLD operators may have similar requirements.
>

.br also has such requirements. OpenSRS reference chart has a good hint of
which ccTLDs have such requirements:
http://bit.ly/OpenSRS_TLD_Reference_Chart

While it details the registration requirements, usually they are aligned:
most ccTLDs that are restricted to local residents also restrict registrars
to be locally incorporated.


Rubens

Fibertech / Lightower Contact?

[Bryon Adams]

Anyone know if they're having trouble? I can't seem to get through to
their NOC using a pair of toll frees I have or any of the individual
contacts we have numbers for. If someone from there can contact me off
list, I just need some info for a new turnup (vlan, port on CPE, etc).

-- 
  Bryon Adams
  bryonad...@fastmail.com

Re: aggregate6 - a fast versatile prefix list compressor

[Aliaksei Sheshka]

On Thu, Nov 30, 2017 at 3:07 PM, Job Snijders  wrote:
> Dear NANOG,
>
> I re-implemented the venerable 'aggregate' tool (by Joe Abley & co) in
> python under the name of 'aggregate6'. The 'aggregate6' tool is faster
> and also has IPv6 support.
>
> https://github.com/job/aggregate6
>

Nice!
"-t" from the "classic" IPv4 "aggregate" would be nice. I've sent a
pull request.

CenturyLink VoIP

[Michael Morrison]

Need to get ahold of a CTL VoIP tech, 

Phone queues seem to be down. Any Help is appreciated.

Re: Arista Layer3

[Nicholas Buraglio]

While I am personally a fan of mikrotik for their ridiculously inexpensive
MPLS features, their total and complete lack of ISIS is a show stopper in a
lot of cases (and makes me sad) and their v6 support is
mostly-ok-but-still-wonky(which also makes me sad) - and ROS 7 has been
"coming soon" in the same way that Apple has been "going out of business"
for 30 years.
The Arista 7500R series has a lot of promise from a service provider
perspective, but the MPLS stack is still under heavy development, but
what's actually there has been solid. What I do like about their gear is
what has typically been true of younger vendors: they listen and implement.
Like Frederik stated, their roadmap is impressively full and my experience
has been that they deliver on their roadmap since it's completely customer
driven. For complicated SPs with lots of RSVP-TE, segment routing, complex
route leaking and other multi-tenant features it may or may not be ready
yet but it's getting pretty close. Interface buffers and other SP specific
things are there based on their chipsets, which is encouraging, and on
paper their programmability is near the top of the heap, especially if
you're using something like Ansible or other access to eAPI (FWIW, we've
been testing some of the programmability on smaller Arista for a bit and
are so far no issues).

nb

ᐧ

---
Nick Buraglio
Energy Sciences Network; AS293
Lawrence Berkeley National Laboratory
burag...@es.net
+1 (510) 995-6068

On Fri, Dec 1, 2017 at 9:59 AM, Frederik Kriewitz 
wrote:

> On Thu, Nov 30, 2017 at 7:36 PM, Romeo Czumbil <
> romeo.czum...@tierpoint.com>
> wrote:
> >
> > So do we have any Arista L3 people out here that can share some negatives
> or positives?
>
> We're using the Arista 7280R with Jericho(+) chips as PE routers.
> We're happy with them.
> Stable operation, no serious issues so far.
>
> Feature wise they're still behind the traditional vendors.
> Some limitations which come to mind:
> - reverse path filtering
> - prefix lists are limited to 65k entries
> - unexpected behaviour with route-map community add/delete (it's not
> possible to add a community which would be delted by a previous term)
> - VRF/MPLS/VPLS support is very basic
> - no support for unnumbered interfaces
> - no BGP flowspec
> - no BGP large communities
> - no subinterfaces
>
> On the other hand all of the above (except unnumbered interfaces) are
> already on their 2018 road map.
> Traditionally they focused on their data center customers.
> But more and more (big) carriers are pushing Arista for the corresponding
> features needed by carriers.
>

ccTLDs - Become a Registrar

[Ryan Finnesey]

I was wonder if anyone within the group has done this research and might be 
able to save me a bit of time.  I am in the process of putting together a new 
Registrar and we would like complete ccTLD coverage.  I know for example CIRA 
(.ca)  has a Canadian Presence Requirement and we have formed a Canadian 
Corporation to meet this requirement.  

I am hoping to find what other TLD operators may have similar requirements.

Cheers
Ryan

Re: aggregate6 - a fast versatile prefix list compressor

[Steve Atkins]

> On Dec 1, 2017, at 2:16 AM, Elmar K. Bins  wrote:
> 
> na...@studio442.com.au (Julien Goodwin) wrote:
> 
>>> The first optimisation is to remove any supplied prefixes which are
>>> superfluous because they are already included in another supplied
>>> prefix. For example, 2001:67c:208c:10::/64 would be removed if
>>> 2001:67c:208c::/48 was also supplied.
>>> 
>>> The second optimisation identifies adjacent prefixes that can be
>>> combined under a single, shorter-length prefix. For example,
>>> 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the
>>> single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and
>>> 10.0.1.0/24 can be joined into 10.0.0.0/23.
>> 
>> Will it catch cases like:
>> 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22
> 
> I guess the developers will have implemented a loop that runs until no
> more optimizations have been found. Which would of course catch it as
> 
> Iteration 1
> 10.0.0.0/24 + 10.0.1.0/24
> -> 10.0.0.0/23
> 
> Iteration 2
> 10.0.0.0/23 + 10.0.2.0/23
> -> 10.0.0.0/22
> 

The usual trick is to build a prefix tree then walk the tree, which catches
this sort of case in one step.

Cheers,
  Steve

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 02 Dec, 2017

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  672139
Prefixes after maximum aggregation (per Origin AS):  261947
Deaggregation factor:  2.57
Unique aggregates announced (without unneeded subnets):  325805
Total ASes present in the Internet Routing Table: 59187
Prefixes per ASN: 11.36
Origin-only ASes present in the Internet Routing Table:   51121
Origin ASes announcing only one prefix:   22517
Transit ASes present in the Internet Routing Table:8066
Transit-only ASes present in the Internet Routing Table:238
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  42
Max AS path prepend of ASN ( 23679)  26
Prefixes from unregistered ASNs in the Routing Table:85
Number of instances of unregistered ASNs:85
Number of 32-bit ASNs allocated by the RIRs:  20763
Number of 32-bit ASNs visible in the Routing Table:   16600
Prefixes from 32-bit ASNs in the Routing Table:   68130
Number of bogon 32-bit ASNs visible in the Routing Table:11
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:327
Number of addresses announced to Internet:   2861310370
Equivalent to 170 /8s, 140 /16s and 33 /24s
Percentage of available address space announced:   77.3
Percentage of allocated address space announced:   77.3
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.8
Total number of prefixes smaller than registry allocations:  222321

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   184628
Total APNIC prefixes after maximum aggregation:   53090
APNIC Deaggregation factor:3.48
Prefixes being announced from the APNIC address blocks:  183767
Unique aggregates announced from the APNIC address blocks:77055
APNIC Region origin ASes present in the Internet Routing Table:8496
APNIC Prefixes per ASN:   21.63
APNIC Region origin ASes announcing only one prefix:   2393
APNIC Region transit ASes present in the Internet Routing Table:   1231
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 42
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3373
Number of APNIC addresses announced to Internet:  767131170
Equivalent to 45 /8s, 185 /16s and 126 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:201468
Total ARIN prefixes after maximum aggregation:97048
ARIN Deaggregation factor: 2.08
Prefixes being announced from the ARIN address blocks:   202861
Unique aggregates announced from the ARIN address blocks: 94992
ARIN Region origin ASes present in the Internet Routing Table:18034
ARIN Prefixes per ASN:   

CenturyLink (former MFON) OSP Contact

[Mike Hammett]

I'm looking for a contact at CenturyLink knowledgeable on one of their routes 
that originally was built by Midwest Fiber Optic Networks (was a part of 
LightCore's network). 

I got conflicting stories from a sales engineer as to the status on the route. 
We may have better options elsewhere, but I wanted to make sure I explored all 
options thoroughly. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

Re: WiFi - login page redirection not working

[Owen DeLong]

> On Dec 1, 2017, at 04:16 , Vincent Bernat  wrote:
> 
> ❦  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.

Oh, you mean the first software anyone with clue turns off as soon as they can 
because of all the problems it causes for networking?

Owen

Re: Arista Layer3

[Frederik Kriewitz]

On Thu, Nov 30, 2017 at 7:36 PM, Romeo Czumbil 
wrote:
>
> So do we have any Arista L3 people out here that can share some negatives
or positives?

We're using the Arista 7280R with Jericho(+) chips as PE routers.
We're happy with them.
Stable operation, no serious issues so far.

Feature wise they're still behind the traditional vendors.
Some limitations which come to mind:
- reverse path filtering
- prefix lists are limited to 65k entries
- unexpected behaviour with route-map community add/delete (it's not
possible to add a community which would be delted by a previous term)
- VRF/MPLS/VPLS support is very basic
- no support for unnumbered interfaces
- no BGP flowspec
- no BGP large communities
- no subinterfaces

On the other hand all of the above (except unnumbered interfaces) are
already on their 2018 road map.
Traditionally they focused on their data center customers.
But more and more (big) carriers are pushing Arista for the corresponding
features needed by carriers.

Re: Contacting AS6589 - "Beneficial Technologies"

[Dovid Bender]

Public shaking seems to work. They are no longer advertising those
prefixes.

On Fri, Dec 1, 2017 at 10:30 AM, Nathan Brookfield <
nathan.brookfi...@simtronic.com.au> wrote:

> The remainder of the advertisements being more /16’s from China Seems
> very very bogus.
>
> Nathan Brookfield
> Chief Executive Officer
>
> Simtronic Technologies Pty Ltd
> http://www.simtronic.com.au
>
> On 2 Dec 2017, at 02:27, Carlos M. Martinez > wrote:
>
> Hello all,
>
> I’m trying to reach anyone at AS 6589, “Beneficial Technologies”. They are
> announcing large chunk of LACNIC unallocated space, as can be seen here:
> https://bgp.he.net/AS6589
>
> Although I usually give people the benefit of doubt, in this case we are
> talking about 5 /16 prefixes. Talk about fat fingers.
>
> Private email is ok.
>
> Thanks
>
> Carlos
> LACNIC CTO
>

Re: BGP next-hop self benefits

[Ken Chase]

On an IX, without next-hop-self peer A leaking peer B's routes they receive to
C will have C send direct to B on the IX (assuming flat layer 3 addressing,
and not multiple little /30s or /96s everywhere or something - do any
exchanges do that?)

This may seem more efficient than sending C's traffic to A to get to B (pumping 
up
the IX's usage graphs) but B may not have peering agreements with C.

Setting next-hop-self avoids this. An 'advantage' in some views. Not related to
n-h-s in an igp specifically, but an interesting (mis)use case.

/kc


On Fri, Dec 01, 2017 at 03:06:34PM +, craig washington said:
  >Hello everyone,
  >
  >
  >Question, what are the true benefits to using the next-hop self feature, 
doesn't matter what vendor.
  >
  >Most information I see is just to make sure you have reach-ability for 
external routes via IBGP, but what if all your IBGP knows the eBGP links?
  >
  >Is there a added benefit to using next hop self in this situation?
  >
  >
  >Any feedback is much appreciated, either for the question specifically or 
whatever else you got , L3VPN's or underlying technology that has to have 
that.
  >
  >
  >Thanks
  >
  >

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Contacting AS6589 - "Beneficial Technologies"

[Nathan Brookfield]

The remainder of the advertisements being more /16’s from China Seems very 
very bogus.

Nathan Brookfield
Chief Executive Officer

Simtronic Technologies Pty Ltd
http://www.simtronic.com.au

On 2 Dec 2017, at 02:27, Carlos M. Martinez 
> wrote:

Hello all,

I’m trying to reach anyone at AS 6589, “Beneficial Technologies”. They are 
announcing large chunk of LACNIC unallocated space, as can be seen here: 
https://bgp.he.net/AS6589

Although I usually give people the benefit of doubt, in this case we are 
talking about 5 /16 prefixes. Talk about fat fingers.

Private email is ok.

Thanks

Carlos
LACNIC CTO

Contacting AS6589 - "Beneficial Technologies"

[Carlos M. Martinez]

Hello all,

I’m trying to reach anyone at AS 6589, “Beneficial Technologies”. 
They are announcing large chunk of LACNIC unallocated space, as can be 
seen here: https://bgp.he.net/AS6589


Although I usually give people the benefit of doubt, in this case we are 
talking about 5 /16 prefixes. Talk about fat fingers.


Private email is ok.

Thanks

Carlos
LACNIC CTO

Update: Packet Loss through Level 3 in Southern California?

[Gregorio Focaccio]

Hi All,

We have continued our investigation and data seem to show a more focused issue 
at the peering between Level 3 (CenturyLink) and MSN in LA.  Can someone look 
at our data (new data below) and see if this seems like a reasonable conclusion?

>From our network (San Diego) to an MSN Azure sever through the "Cogent | MSN 
>Portal in LA" has no loss, but the same server has loss when going through the 
>"Level 3 | MSN Portal in LA"

Also, we have data showing no packet loss through the same Level 3 LA 
(LosAngeles1) nodes to Cogent to Texas, so data seems to clear the Level 3 Los 
Angeles and Cogent peering.

Thanks,
Greg

Testing data:

IPERF UDP results looks good on path through Level 3 (CenturyLink) in LA 
(LosAngeles1) when going to a server in Texas (non-MSN Azure)

gfxc0.localdomain (0.0.0.0) 
   Thu Nov 30 16:16:02 2017
Keys:  Help   Display mode   Restart statistics   Order of fields   quit

   Packets   Pings
Host
Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 216.75.40.1  
 0.0%860.3   7.1   0.3 172.4  27.4
2. xe-8-3-3.bar1.SanDiego1.Level3.net   
 0.0%863.3   3.6   3.3  25.4   2.4
3. ae-3-3.ebr1.LosAngeles1.Level3.net   
90.6%863.6   3.6   3.6   3.7   0.0
4. ae-1-51.ear2.LosAngeles1.Level3.net  
95.3%86  7225. 7157. 7134. 7225.  45.4
5. Cogent-level3-100G.LosAngeles1.Level3.net
 0.0%863.8   3.9   3.6   5.7   0.2
6. be3360.ccr42.lax01.atlas.cogentco.com
 0.0%863.6   3.7   3.5   4.0   0.0
7. be2932.ccr32.phx01.atlas.cogentco.com
 0.0%86   12.6  12.6  12.4  13.0   0.0
8. be2930.ccr21.elp01.atlas.cogentco.com
 0.0%85   20.7  20.9  20.6  22.5   0.2
9. be2928.ccr42.iah01.atlas.cogentco.com
 0.0%85   36.8  36.6  36.4  37.1   0.0
10. be2443.ccr32.dfw01.atlas.cogentco.com   
  0.0%85   41.6  41.7  41.5  42.6   0.0
11. be2939.rcr21.dfw04.atlas.cogentco.com   
  0.0%85   42.6  42.7  42.3  44.0   0.2
12. te0-0-1-1.nr12.b028597-0.dfw04.atlas.cogentco.com   
  0.0%85   43.2  43.2  43.1  43.5   0.0
13. 38.122.200.202  
  0.0%85   42.4  42.4  42.3  42.7   0.0
14. 138.128.243.167 
  0.0%85   42.6  42.7  42.4  48.2   0.7

[root@gfxc0 ~]# iperf3 -uZVc 138.128.243.167 -b10m -t15 --get-server-output
iperf 3.1.3
Linux gfxc0.localdomain 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 
2017 x86_64
Time: Fri, 01 Dec 2017 00:17:19 GMT
Connecting to host 138.128.243.167, port 5201
  Cookie: gfxc0.localdomain.1512087439.341597.
[  4] local 216.75.40.2 port 42277 connected to 138.128.243.167 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 
15 second test
[ ID] Interval   Transfer Bandwidth   Total Datagrams
[  4]   0.00-1.00   sec  1.09 MBytes  9.11 Mbits/sec  139
[  4]   1.00-2.00   sec  1.20 MBytes  10.0 Mbits/sec  153
[  4]   2.00-3.00   sec  1.19 MBytes  9.96 Mbits/sec  152
[  4]   3.00-4.00   sec  1.20 MBytes  10.0 Mbits/sec  153
[  4]   4.00-5.00   sec  1.19 MBytes  9.96 Mbits/sec  152
[  4]   5.00-6.00   sec  1.20 MBytes  10.0 Mbits/sec  153
[  4]   6.00-7.00   sec  1.19 MBytes  9.96 Mbits/sec  152
[  4]   7.00-8.00   sec  1.20 MBytes  10.0 Mbits/sec  153
[  4]   8.00-9.00   sec  1.20 MBytes  10.0 Mbits/sec  153
[  4]   9.00-10.00  sec  1.19 MBytes  9.96 Mbits/sec  152
[  4]  10.00-11.00  sec  1.20 MBytes  10.0 Mbits/sec  153
[  4]  11.00-12.00  sec  1.19 MBytes  9.96 Mbits/sec  152
[  4]  12.00-13.00  sec  1.20 MBytes  10.0 Mbits/sec  153
[  4]  13.00-14.00  sec  1.20 MBytes  10.0 Mbits/sec  153
[  4]  14.00-15.00  sec  1.19 MBytes  9.96 Mbits/sec  152
- - 

BGP next-hop self benefits

[craig washington]

Hello everyone,


Question, what are the true benefits to using the next-hop self feature, 
doesn't matter what vendor.

Most information I see is just to make sure you have reach-ability for external 
routes via IBGP, but what if all your IBGP knows the eBGP links?

Is there a added benefit to using next hop self in this situation?


Any feedback is much appreciated, either for the question specifically or 
whatever else you got , L3VPN's or underlying technology that has to have that.


Thanks

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

[Nikolay Shopik]

On 01/12/17 09:32, Vincent Bernat wrote:
> 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.

Current take on that is capport WG
https://datatracker.ietf.org/wg/capport/documents/

Re: Arista Layer3

[Jared Mauch]

> On Nov 30, 2017, at 11:56 PM, Colton Conor  wrote:
> 
> Jared,
> 
> Which Arista box do you use for FTTH features? Whats the cost like as FTTH 
> boxes are usually inexpensive, and Arista is not know to be inexpensive 
> compared to something like Calix or Adtran. 


I use the DCS-7050S-52-F.  This is because I get good routed features to meet 
my use-case, and the cost per SFP port was right.  I’m purchasing them used, so 
my price per 1G port (that can also do 10G to uplink/infrastructure) is 
comparable to the per-port price of other BCM based SFP switches, and the 
software quality is much much higher.  I don’t need 10’s of these either, so my 
use case is perhaps unique.

I really need some basic routing support, DHCP relay w/ circuit id, etc.

Ping me offline if you want more details about my use-case.  Once I have a few 
more things sorted, expect a full nanog talk about my problem & solution.

- Jared

Re: aggregate6 - a fast versatile prefix list compressor

[Job Snijders]

On Fri, Dec 01, 2017 at 09:09:38PM +1100, Julien Goodwin wrote:
> Will it catch cases like:
> 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22

Yes it does!

hanna:~ job$ echo 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 | aggregate6
10.0.0.0/22
hanna:~ job$

Kind regards,

Job

Re: aggregate6 - a fast versatile prefix list compressor

[Elmar K. Bins]

na...@studio442.com.au (Julien Goodwin) wrote:

> > The first optimisation is to remove any supplied prefixes which are
> > superfluous because they are already included in another supplied
> > prefix. For example, 2001:67c:208c:10::/64 would be removed if
> > 2001:67c:208c::/48 was also supplied.
> > 
> > The second optimisation identifies adjacent prefixes that can be
> > combined under a single, shorter-length prefix. For example,
> > 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the
> > single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and
> > 10.0.1.0/24 can be joined into 10.0.0.0/23.
> 
> Will it catch cases like:
> 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22

I guess the developers will have implemented a loop that runs until no
more optimizations have been found. Which would of course catch it as

Iteration 1
10.0.0.0/24 + 10.0.1.0/24
-> 10.0.0.0/23

Iteration 2
10.0.0.0/23 + 10.0.2.0/23
-> 10.0.0.0/22

Re: aggregate6 - a fast versatile prefix list compressor

[Julien Goodwin]

On 01/12/17 07:27, Job Snijders wrote:
> Someone suggested I should clarify what 'aggregate6' actually does :-)
> 
> aggregate6 takes a list of IPv4 and/or IPv6 prefixes in conventional
> format, and performs two optimisations to attempt to reduce the length
> of the prefix list.
> 
> The first optimisation is to remove any supplied prefixes which are
> superfluous because they are already included in another supplied
> prefix. For example, 2001:67c:208c:10::/64 would be removed if
> 2001:67c:208c::/48 was also supplied.
> 
> The second optimisation identifies adjacent prefixes that can be
> combined under a single, shorter-length prefix. For example,
> 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the
> single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and
> 10.0.1.0/24 can be joined into 10.0.0.0/23.

Will it catch cases like:
10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22

> The above two optimalisations are useful in context of firewall rule
> generation or generation of BGP prefix-list filters.

Or being a nice citizen and rationalising your announcements.

Re: Arista Layer3

[Ruairi Carroll]

Their L3 stuff is as stable as their L2 stuff, in general.

MP-BGP and VRFs are a tiny bit bleeding edge/lacking features, however for
plain OSPF/BGP, they're great.

/Ruairi



On 30 November 2017 at 18:36, Romeo Czumbil 
wrote:

> So I've been using Arista as layer2 for quite some time, and I'm pretty
> happy with them.
> Kicking the idea around to turn on some Layer3 features but I've been
> hearing some negative feedback.
> The people that I did hear negative feedback don't use Arista themselves.
> (they just heard)
>
> So do we have any Arista L3 people out here that can share some negatives
> or positives?
>
> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP
> Maybe 20k routes (no full internet routes)
> 7050 Series
> 7280 Series
>
> -Romeo
>