- NANOG - lists.nanog.org

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

MVPN Question - profile 0
by Hari . 30 May '18

30 May '18

Hey - One question on MVPN behavior. Will the PIM JOIN from the customer will be received on all the MVPN members - encapsulated MDT group. ? Can we expect to see the state in all the MDT members? Thought it will be seen only on RPF neighbor? In our scenario, the multicast VRF in PE should be preferring Core2 (thanks to default from core2 with high preference). But still, we are seeing some state created in CORE1. Although the majority is on CORE2. Any thought on why the state created on CORE1 overriding the RPF check? Regards

1 0

Re: Impacts of Encryption Everywhere (any solution?)
by John R. Levine 30 May '18

30 May '18

In article <CAEmG1=oiVJ4qj_D9hA3WS=g64zoo4pYkZ-zDZ0nEEQcTjE5A=A(a)mail.gmail.com>, Matthew Petach <mpetach(a)netflight.com> wrote: >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. Nonetheless, Safaricom sells entirely usable data plans. A one day 1GB bundle on a prepaid SIM costs about $1, a monthly 1GB costs about $5. They have 4G, it works, I've used it. What do they know that Telegeography (who made that slide) doesn't? -- 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

10 16

Re: Opinions on intent-based networking
by Marcus Leske 30 May '18

30 May '18

A Tier-1 deployed it today. http://www.lightreading.com/data-center/data-center-infrastructure/apstra-d… It can be a lot of things and nothing, it can be just a GUI with some UX built into it, relatively making it easy to configure stuff, and it can be just a bunch of well written automation scripts with all sorts of checks and whistles, it can be just a little bit more analytics on top of that, and it can definitely be something a lot more if done PROPERLY, I hear good things about Apstra but i cant confirm because it can easily be marketing. In my humble opinion, if done properly, the Network Operating System would send telemetry info on any change in the network, and the Intent Based Networking system would consume that, run it by a lot of policies and take automated/guided actions. There is a webinar tomorrow with their VP of Engneering, join it and ask your question: http://go.apstra.com/webinar-apstra-cumulus-disaggregation Cheers, Marcus > On Tue, May 29, 2018 at 7:29 PM, K. Scott Helms <kscott.helms(a)gmail.com> wrote: >> A substantial percentage, perhaps 100%, of the use case can be accomplished >> using micro-segmentation. >> >> On Tue, May 29, 2018 at 2:33 PM LF OD <bz_siege_01(a)hotmail.com> wrote: >> >>> Been following the articles on "intent-based" networking from Cisco and >>> other vendors for a couple years now, and I have a basic grasp of the >>> concept of "define your goals/outcomes and automation will make it so", but >>> I do not know the practical applications of it or how you are supposed to >>> convey your "intent". However, $dayjob is a medium-sized enterprise and >>> looking at a potential refresh in the upcoming budget. >>> >>> >>> So... do any of you at ISPs, Cloud Providers, or Enterprises have any >>> hands-on experience with "intent-based" networking products? If so, could >>> you please provide some info on what caused you to look at it, who did you >>> look at, why did you choose whoever you chose, and is it working out for >>> you? >>> >>> >>> If you looked at it very closely and decided not to bother with it, I'd >>> also be interested on your take. At $dayjob we have been adopting >>> automation at the application and workload level, but there hasn't been >>> much need for it at the infrastructure level. However, if we can improve >>> the services we offer while refreshing that infrastructure, it wouldn't >>> hurt - depending on cost of course. >>> >>> >>> Thanks in advance. >>> >>> LF0D >>>

1 0

BGP Hijack/Sickness with AS4637
by Alain Hebert 29 May '18

29 May '18

Hi, We're looking for a contact, *that works*, to get in touch with AS4637 (Telstra/HK) about some hijacking or router sickness. BGPmon has been reporting an hijack of AS3's subnet 18.29.238.0/23. After being contacted by AS3, we went over the advertisement with AS29909 and AS16532 to be sure. Then we tried getting in touch with AS4637 (Telstra/HK) but it went nowhere at this point. PS: If anyone has better observations that would be greatly appreciated. ----- Context: A few times this month, BGPmon reported an hijack of 18.29.238.0/23 (AS3). For this hijack I see AS4637 (Telstra/HK), AS3257( GTT) AS29909 (MOO) and AS16532 ( (which are peers I know and I'm in contact with). 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

5 4

Opinions on intent-based networking
by LF OD 29 May '18

29 May '18

Been following the articles on "intent-based" networking from Cisco and other vendors for a couple years now, and I have a basic grasp of the concept of "define your goals/outcomes and automation will make it so", but I do not know the practical applications of it or how you are supposed to convey your "intent". However, $dayjob is a medium-sized enterprise and looking at a potential refresh in the upcoming budget. So... do any of you at ISPs, Cloud Providers, or Enterprises have any hands-on experience with "intent-based" networking products? If so, could you please provide some info on what caused you to look at it, who did you look at, why did you choose whoever you chose, and is it working out for you? If you looked at it very closely and decided not to bother with it, I'd also be interested on your take. At $dayjob we have been adopting automation at the application and workload level, but there hasn't been much need for it at the infrastructure level. However, if we can improve the services we offer while refreshing that infrastructure, it wouldn't hurt - depending on cost of course. Thanks in advance. LF0D

4 3

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

29 May '18

I believe you were responding to me, but it was really hard to tell. If so, here's the conversation... > 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. --- ben(a)6by7.net wrote: From: Ben Cannon <ben(a)6by7.net> Then Africa in particular is specifically disadvantaged - I spent a good deal of time in Haiti and 4G connectivity was abundant at good speeds, as were terrestrial fiber connections. Mirrors my experience in half a dozen other 3rd world countries. Unless there’s something particularly oppressive about Africa? -------------------------------------- I guess I was more meaning in the Pacific, since I'm from there. And more particularly places like Kiribati, Cook Islands, Marquesas and other far flung Pacific Island Countries. My apologies for the confusion. Hati and other countries close to a rich mainland country do not suffer the same issues due to geography. scott ps. lately the SW Pacific countries (Vanuatu, Solomons, etc) are getting it together on circuits to main islands in the group from help by NZ, AUS and the Asian Development Bank.

2 1

Whois vs GDPR, latest news
by Brian Kantor 28 May '18

28 May '18

A draft of the new ICANN Whois policy was published a few days ago. https://www.icann.org/en/system/files/files/proposed-gtld-registration-data… >From that document: "This Temporary Specification for gTLD Registration Data (Temporary Specification) establishes temporary requirements to allow ICANN and gTLD registry operators and registrars to continue to comply with existing ICANN contractual requirements and community-developed policies in light of the GDPR. Consistent with ICANN’s stated objective to comply with the GDPR, while maintaining the existing WHOIS system to the greatest extent possible, the Temporary Specification maintains robust collection of Registration Data (including Registrant, Administrative, and Technical contact information), but restricts most Personal Data to layered/tiered access. Users with a legitimate and proportionate purpose for accessing the non-public Personal Data will be able to request such access through Registrars and Registry Operators. Users will also maintain the ability to contact the Registrant or Administrative and Technical contacts through an anonymized email or web form. The Temporary Specification shall be implemented where required by the GDPR, while providing flexibility to Registry Operators and Registrars to choose to apply the requirements on a global basis based on implementation, commercial reasonableness and fairness considerations. The Temporary Specification applies to all registrations, without requiring Registrars to differentiate between registrations of legal and natural persons. It also covers data processing arrangements between and among ICANN, Registry Operators, Registrars, and Data Escrow Agents as necessary for compliance with the GDPR."

30 56