Re: Incoming SMTP in the year 2017 and absence of DKIM
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
Hi Guys, Is anyone knows about a Monitoring tool for OSPF ?? ~~( ŊëŌ )~~
Re: aggregate6 - a fast versatile prefix list compressor
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
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
>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
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
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
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
> > 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
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
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
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?
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
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
Need to get ahold of a CTL VoIP tech, Phone queues seem to be down. Any Help is appreciated.
Re: Arista Layer3
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
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
> 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
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
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
> 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
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"
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 carlosm3...@gmail.com>> 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
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"
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 mailto:carlosm3...@gmail.com>> 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"
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?
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
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
❦ 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
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
> 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
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
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
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
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 >