May 2018 - Test - lists.nanog.org

3rd party QSFP-100G-LR4-S for Cisco
by Ryugo Kikuchi 10 Jun '18

10 Jun '18

Hey all, Does anyone have a recommended model of 3rd party's "QSFP-100G-LR4-S" for Cisco ASR and Nexus? Cisco's original 100G SFP costs us an arm and a leg, so we want to try to use 3rd party 100g SFP. But we are not sure which manufacturer's SFP is reliable or has good performance. Does anyone have experience? Many thanks, Roy

9 9

Satelite Internet Provider
by Ing. Edwin Salazar 07 Jun '18

07 Jun '18

Hi, I would like to know if anyone knows any satellite internet provider for the Galapagos Islands in Ecuador that I can contact? Best regards, Edwin Salazar.

3 2

Subsea availability
by Mehmet Akcin 07 Jun '18

07 Jun '18

Hello there, I am working on a masters project idea to create an interactive map of the world’s subsea cables (cls to cla without local loops from cls to dc) I would like to know if anyone have worked with something like this in the past, and whether you think it would be cool to have a map where you can see subsea cable availability. I am also going to be at nanog denver to talk about this project with people. Let me know if you are available and interested in talking on ways to collaborate. I have few ideas on how to make this work with using ripe atlas probe like devices installed in strategic locations. Mehmet

7 9

ICANN GDPR lawsuit
by Dan Hollis 06 Jun '18

06 Jun '18

http://www.circleid.com/posts/20180527_icann_files_legal_action_against_dom… -Dan

17 34

Bezeq Internet (IL) around?
by Elmar K. Bins 06 Jun '18

06 Jun '18

Hi Bezeq people, I hope you're subscribed here, I could use your immediate help, probably leading to a contract... Yours, Elmar.

3 3

Re: BGP Hijack/Sickness with AS4637
by Alain Hebert 01 Jun '18

01 Jun '18

Hi, Well bad news on the ColoAU front, they refused to cooperate. We'll pushback thru our GTT accounts... But I'm running out of ideas. If anyone has any good ideas how to proceed at this point feel free to share =D. ----- Alain Hebert ahebert(a)pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/29/18 16:31, Chris Conn wrote: > Hello, > > I am the contact for AS16532. > > We never announced nor are we currently advertising this prefix as we are not a transit AS for anyone. As well, it seems to appear and disappear from AS63956 looking glass. According to that LG, the route changed 6d ago, and is *still currently visible* at this very moment; > > https://lg.coloau.com.au/ > > Command: show route 18.29.238.0 protocol bgp table vrf-international.inet.0 active-path > > vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 active, 0 holddown, 103994 hidden) > + = Active Route, - = Last Active, * = Both > > 18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2 > AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified > > > AS16532 is not announcing this prefix. We have a strict prefix-list that is applied to all sessions. As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb. And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA. > > There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path? > > I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would change anything, as I am not seeing this prefix in their route-server > > public(a)route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp active-path > > inet.0: 691667 destinations, 11752983 routes (691665 active, 1 holddown, 1 hidden) > + = Active Route, - = Last Active, * = Both > > 18.29.0.0/16 *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 213.200.87.23 > AS path: 3257 174 3 I, validation-state: unverified > > to 141.136.111.13 via xe-1/0/0.0 > > {master} > public(a)route-server.as3257.net-re0> > > > {master} > public(a)route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp | find 16532 > > Pattern not found > {master} > > > > So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find. > > > Chris Conn > AS16532 > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Tom Paseka via NANOG > Sent: Friday, May 25, 2018 6:01 PM > To: Nikolas Geyer <nik(a)neko.id.au> > Cc: NANOG list <nanog(a)nanog.org> > Subject: Re: BGP Hijack/Sickness with AS4637 > > This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened. > > If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be. > Bouncing your session with 4637 would likely clear this. > > -Tom > > On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer <nik(a)neko.id.au> wrote: > >> Greetings! >> >> Actually, what you have provided below shows the exact opposite. It >> shows ColoAU have received the route from 4637 who have received it >> from 3257 who have received it from 29909 who have received it from >> 16532 who originated it. It infers nothing about who 16532 found the route to come from. >> >> It is evident that GTT are advertising that route to Telstra Global :) >> >> Regards, >> Nik. >> >>> And I'm pretty sure AS3257 (GTT ) is in the same boat as us, >>> as >> they're not the one advertising those routes to AS4637 >>> AS16532 found it to come from AS4637 as you can see from this >>> ColoAU >> LG output below >>> >>> ----- https://lg.coloau.com.au/ >>> >>> vrf-international.inet.0: 696533 destinations, 2248101 routes >>> (696249 >> active, 0 holddown, 103835 hidden) >>> + = Active Route, - = Last Active, * = Both >>> >>> 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from >> 103.97.52.2 >>> AS path: 4637 3257 29909 16532 16532 16532 >>> 16532 >> I, validation-state: unverified >>> -- >>> ----- >>> Alain Hebert ahebert(a)pubnix.net >>> PubNIX Inc. >>> 50 boul. St-Charles >>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >>> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >>>

6 10

Juniper BGP Convergence Time
by Adam Kajtar 31 May '18

31 May '18

Hello: I'm running two Juniper MX104s. Each MX has 1 ISP connected running BGP(full routes). iBGP is running between the routers via a two port 20G lag. When one of the ISPs fails, it can take upwards of 2 minutes for traffic to start flowing correctly. The router has the correct route in the routing table, but it doesn't install it in the forwarding table for the full two mins. I have a few questions if anyone could answer them. - What would a usual convergence time be for this setup? - Is there anything I could do speed this process up? (I tried Multipath) - Any tips and tricks would be much appreciated Thanks in Advance -- Adam Kajtar Systems Administrator City of Wadsworth akajtar(a)wadsworthcity.org ----------------------------------------------------- http://www.wadsworthcity.com Facebook <http://www.facebook.com/cityofwadsworth>* |* Twitter <https://twitter.com/CityOfWadsworth> *|* Instagram <https://www.instagram.com/cityofwadsworth/> *|* YouTube <https://www.youtube.com/channel/UCymlH-AZgvxTaHtgp3-AmDQ>

17 26

SIP fax sending software?
by John R. Levine 30 May '18

30 May '18

Can anyone recommend software that sends faxes over SIP? I have plenty of inbound fax to email services, but now and then I need to send a reply and it looks tacky to use one of the free web ones that put an ad on it. I know that if I wanted to pay $15/mo there are lots of lovely services but we're taking about one fax a month, maybe, here. Ideally it'd take a postscript or PDF or Word document and a phone number and fax it to that number. I have Ubuntu, FreeBSD, and MacOS boxes. Any suggestions? Regards, John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly

12 14

Re: Impacts of Encryption Everywhere (any solution?)
by Scott Weeks 30 May '18

30 May '18

--- mpetach(a)netflight.com wrote: From: Matthew Petach <mpetach(a)netflight.com> On Mon, May 28, 2018 at 11:22 AM, Ben Cannon <ben(a)6by7.net> wrote: > I’m sorry I simply believe that in 2018 with the advanced and cheap ptp > radio (ubiquiti anyone? $300 and I have a 200mbit/sec link over 10miles! > Spend a bit more and go 100km) plus the advancements in cubesats about to > be launched, even the 3rd world can simply get with the times. I do not think you adequately understand the economics of the situation. https://www.slideshare.net/InternetSociety/international-bandwidth-and-pric… slide 22, IP transit cost. Your 200mbit/sec link that costs you $300 in hardware is going to cost you $4960/month to actually get IP traffic across, in Nairobi. Yes, that's about $60,000/year. Could *you* afford to "get with the times" if that's what your bandwidth was going to cost you? Please, do a little research on what the real costs are before telling others they need to "simply get with the times." ----------------------------------------- Also, please don't just look at continental countries when researching. Look at the small PICs (Pacific Island Countries). For example, search the posts from Christian on Kiribati on the PICISOC list. The cost is extraordinary and all the ego-flattering bloat rsk speaks (relevant part of the post id below) of in very expensive to download and is nearly impossible to stop. scott * > The problem (part of the problem) is that the people doing these foolish > things are new, ignorant, and privileged: they don't realize that bandwidth > is still an expensive and scarce resource for most of the planet. I've > said for years that every web designer should be forced to work in an > environment bandlimited to 56K in order to instll in them the virtue > of frugality and strongly discourage them from flattering their egos > by creating all-singing all-dancing web sites...that look great in the > portfolios they'll show to their peers but are horribly bloated, slow, > unrenderable in a lot of browsers, and fraught with security and privacy > problems. (Try pointing a text-only browser at your favorite website. > Can you even read the home page?)

9 18

Re: BGP Hijack/Sickness with AS4637
by Chris Conn 30 May '18

30 May '18

Hello, I am the contact for AS16532. We never announced nor are we currently advertising this prefix as we are not a transit AS for anyone. As well, it seems to appear and disappear from AS63956 looking glass. According to that LG, the route changed 6d ago, and is *still currently visible* at this very moment; https://lg.coloau.com.au/ Command: show route 18.29.238.0 protocol bgp table vrf-international.inet.0 active-path vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 active, 0 holddown, 103994 hidden) + = Active Route, - = Last Active, * = Both 18.29.238.0/23 *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2 AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified AS16532 is not announcing this prefix. We have a strict prefix-list that is applied to all sessions. As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb. And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA. There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path? I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would change anything, as I am not seeing this prefix in their route-server public(a)route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp active-path inet.0: 691667 destinations, 11752983 routes (691665 active, 1 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 18.29.0.0/16 *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 213.200.87.23 AS path: 3257 174 3 I, validation-state: unverified > to 141.136.111.13 via xe-1/0/0.0 {master} public(a)route-server.as3257.net-re0> {master} public(a)route-server.as3257.net-re0> show route 18.29.238.0 protocol bgp | find 16532 Pattern not found {master} So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find. Chris Conn AS16532 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Tom Paseka via NANOG Sent: Friday, May 25, 2018 6:01 PM To: Nikolas Geyer <nik(a)neko.id.au> Cc: NANOG list <nanog(a)nanog.org> Subject: Re: BGP Hijack/Sickness with AS4637 This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened. If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be. Bouncing your session with 4637 would likely clear this. -Tom On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer <nik(a)neko.id.au> wrote: > Greetings! > > Actually, what you have provided below shows the exact opposite. It > shows ColoAU have received the route from 4637 who have received it > from 3257 who have received it from 29909 who have received it from > 16532 who originated it. It infers nothing about who 16532 found the route to come from. > > It is evident that GTT are advertising that route to Telstra Global :) > > Regards, > Nik. > > > > > And I'm pretty sure AS3257 (GTT ) is in the same boat as us, > > as > they're not the one advertising those routes to AS4637 > > > > AS16532 found it to come from AS4637 as you can see from this > > ColoAU > LG output below > > > > > > ----- https://lg.coloau.com.au/ > > > > vrf-international.inet.0: 696533 destinations, 2248101 routes > > (696249 > active, 0 holddown, 103835 hidden) > > + = Active Route, - = Last Active, * = Both > > > > 18.29.238.0/23 *[BGP/170] 1d 19:57:28, localpref 90, from > 103.97.52.2 > > AS path: 4637 3257 29909 16532 16532 16532 > > 16532 > I, validation-state: unverified > > > > -- > > ----- > > Alain Hebert ahebert(a)pubnix.net > > PubNIX Inc. > > 50 boul. St-Charles > > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > >

1 0