Mikrotik 6.47.1 released

Lots of things here. Some noteable things

What’s new in 6.47.1 (2020-Jul-08 12:34):

*) crs3xx – fixed HW offloading for netPower 15FR and netPower 16P devices (introduced in v6.47);
*) crs3xx – fixed increased CPU temperature for CRS354-48G-4S+2Q+ device (introduced in v6.47);
*) crs3xx – improved Ethernet port group traffic forwarding for CRS354 devices;
*) dhcpv6-server – disallow changing binding’s “prefix-pool”;
*) dhcpv6-server – improved stability when changing server for static bindings;
*) dns – do not allow setting “forward-to” same as “name” or “regex”;
*) dns – do not allow setting zero value IP addresses for “A” and “AAAA” records;
*) dns – do not use DoH for local queries when a server is specified;
*) ftp – fixed possible buffer overflow;
*) ike2 – fixed initiator child SA init without policy;
*) ike2 – fixed policy reference for pending acquire;
*) ike2 – retry RSA signature validation with deduced digest from certificate;
*) ipsec – do not update peer endpoints for generated policy entries (introduced in v6.47);
*) lora – added “spoof-gps” parameter for fake GPS coordinate sending;
*) lora – fixed JSON statistics inaccuracies;
*) lte – added support for MTS 8810FT;
*) lte – fixed modem initialization when multiple modems are used simultaneously;
*) lte – fixed PDP authentication configuration for SIM7600;
*) metarouter – fixed image importing (introduced in v6.46);
*) ospf – improved route tag processing for OSPFv3;
*) ppp – allow specifying pool name for “remote-ipv6-prefix-pool” parameter;
*) profile – fixed “unclassified” load reporting on PowerPC devices (introduced in v6.47);
*) qsfp – fixed auto-negotiation status;
*) qsfp – ignore FEC mode when set to fec91, only fec74 mode is supported (introduced in v6.47);
*) switch – fixed MAC address learning on switch-cpu port for Atheros8316, Atheros8227 and Atheros7240 switch chips;

Full change log at https://mikrotik.com/download

Sponsored Post: Ritalia Funding

As you may already know, we have been exhibitors at Wispa shows for almost 9 years. We are a technology financing source for the industry and work with many well known vendors such as Streakwave, ISP Supplies, Winncom, WavOnline, CTI, among others. We have implemented some new financing programs for you in order to meet the current market needs, please see below:

Our capabilities:

•       App Only Financing Program available for any type of IT / Non IT Equipment (including towers), Software, Services and Soft Costs on transactions starting at 8k and up to 500k.

•       CBRS auction fees and cost financing

•       Special financing structures for new spectrum releases

•       Terms 24 – 60 Months.

•       Hardware & Software (Any brand, any vendor, including CPE’s)

•       Licensing renewals, Software only

•       Maintenance only financing, Implementations only. 

•       Approvals on transactions with a high percentage of Professional Services / Challenging Transactions.

•       60 days deferred payment option available.

•       Pre-approvals in less than 48hrs.

•       Find attached our WISPA Q3 rate sheet for A credit and its requirements.

Please let us know if there is anything we can help you at all.

Thanks, we are looking forward to working with you.

Ivan Crowe / Greg Urbaez

(818)-921-3624 — (818) 921-3630

icrowe@rtflease.com / greg@rtflease.com

www.ritaliafunding.com

RPKI and misconceptions

After my blog post about Hurricane Electric and RPKi support, I was seeing some comments by folks that warrant some clarification. I put together a short midnight podcast on this.  To summarize
1. route original validation is not the same as having ROA’S with your RIR
2. If you have an ASN you should have a peering DB entry
3.ROAs have nothing to do with your router supporting RPKI

Hurricane Electric now requires IRR and filters invalid RPKI

If you are a Hurricane Electric customer you may be receiving e-mails like the following:

Dear ASXXX,

Routing Security Report for ASXXX

Hurricane Electric cares about your routing security.  We filter all BGP sessions using prefix filters based on IRR and RPKI.

This report is being sent to help you identify prefixes which may need either their IRR or RPKI information created or updated 
and to also help you identify possibly hijacked routes you may be accepting and reannouncing.  

Routes with RPKI status INVALID_ASN strongly indicate a serious problem.

IPv4 SUMMARY

Routes accepted: 3
Routes rejected: 3
Routes with RPKI status VALID: 0
Routes with RPKI status INVALID: 0

IPv6 SUMMARY

Routes accepted: 1
Routes rejected: 0
Routes with RPKI status VALID: 0
Routes with RPKI status INVALID: 0

We currently do not have a valid as-set name for your network.  Please add an export line to your aut-num ASXXXX 
that references your as-set name.  For example,

export: to AS-ANY announce your-as-set-name

If you do not currently have an as-set, we recommend you create one named ASXXXX:AS-ALL

Your as-set should contain just your ASN and your customers' ASNs and/or as-sets (not your peers or upstream providers).

What does this mean for you as a service provider? If you use Hurricane Electric as transit or peer with them on an exchange you will need to have ROAs for your blocksand have routing registry objects. I did a tutorial based upon Arin which can be found at: https://blog.j2sw.com/networking/routing-registries-and-you/

In short you need to do the following:

  • Create a mntner object (equivalent of a user account) to give you the ability to create IRR objects in your selected IRR database
  • Create an aut-num to represent your autonomous system and describe its contact information (admin and technical) and your routing policy
  • Create an as-set to describe which autonous system numbers your peers should expect to see from you (namely your own and your transit customers)
  • Create a route/route6 object for every prefix originated from your network
  • Update your peeringdb profile to include your IRR peering policy
  • Generate RPKI https://www.arin.net/resources/manage/rpki/roa_request/#creating-a-roa-in-arin-online

Clarification:
Some folks are confusing having valid ROAs with your router supporting RPKI with route origin validation in real-time. These two are separate things. You create ROA records with your RIR, such as ARIN, which has nothing to do with route validation on your router.

Also, HE is filtering any RPKI INVALID routes. Does this mean they are requiring RPKI? You be the judge.



Briefing June 26th 2020 – API,5g,interconnection

Bots are awesome. They really are. So are APIs; both boost productivity by advancing automation, the exchange of business data and support decision making. If only everything was so perfect…. Unfortunately, 81% of organizations have reported attacks against their APIs, and 75% suffered bot attacks in a 12 month period.
Data centers will become even more pivotal to the digital economy over the next five years, which will see a meteoric rise in the volume of data traffic flowing through network intersections. This existing trend takes on new urgency with the COVID-19 pandemic, which has driven a massive shift to online services.

https://www.businessinsider.com/exclusive-massive-spying-on-users-of-googles-chrome-shows-new-security-weakness-2020-6
A newly discovered spyware effort attacked users through 32 million downloads of extensions to Google’s market-leading Chrome web browser, researchers at Awake Security told Reuters, highlighting the tech industry’s failure to protect browsers as they are used more for email, payroll and other sensitive functions.

The fifth generation of wireless connectivity, commonly referred to as 5G, is revolutionizing our digital lives by enabling unprecedented speed, bandwidth, processing and capacity at an industrial scale. For years now, we’ve been hearing about the almost science fiction-esque advancements 5G will bestow on our society, such as driverless carstelemedicine, factory automation, and smart cities.

Takeaways for the customer from Tech Support

I have been in the ISP industry for close to thirty years now. One thing that has changed very little is the customer side of technical support. What I mean by this is, no matter if it is dial-up or fiber optic, customers will still have issues. They will still need to occasionally call their ISP for support in one fashion or another. This article is to hammer home how you the customer should always have something positive they walk away with, even if you can not solve their problem right away.

Duh! you say. This is common sense, you say. After seeing many posts from technicians, I have come to realize technical support folks fall into a rut. Let’s face, being on the front line of technical support operations is brutal. From the irate customers to the ones who can’t turn on their computer, it is stressful. It takes a unique mindset to be able to do technical support. When I managed a team of customer representatives back in the dial-up days, I had one very strict rule.

At the end of every interaction with the customer give them something positive to walk away with

You hope each time the positive is you fixed their issue(s). That is always the goal. If you can’t give them a clear resolution you should always give the customer a time for the next contact and something you are going to be doing for them in the meantime. Let’s go into some scenarios below.

You determine the customer had a bad CPE/NID, etc.
What you want to be able to do is give the customer a timeframe at the very least of when a technician can be at their place, or a new unit mailed to them.
“Let’s schedule a time we can get someone out there”
“Scheduling will be calling you in the next couple of hours to schedule a service call”
“I will get a new unit in the mail to you in Today’s/Tomorrow’s mail”

Each of the above gives the customer something concrete they can expect. It might not be the answer they want to hear, but it gives them something that is a step toward resolving their issues.

The customer has an issue on their end (bad computer, bad router that isn’t yours, etc)
Reinforce with the customer you are not abandoning them, just have exhausted your avenues of resolution.
“I think it might be your computer. I can give you the names of some computer repair shops in your area. Once they take a look we are here to make sure you get back online.
“I think your router may be bad. We bypassed it and things are working. I would suggest a new router. We have a guide or can help you once you have the new one.

In each of these cases, the key is to let the customer you are not pushing off the problem. It is something you can not fix and is impeding you from helping them.

One of the phrases I heard on a message board from an ISP was “Don’t call us again if you have this problem.” I know sometimes this can be said in jest, and to the right customer, you are okay. But normally, this is something you should never say to a customer. It gives them the impression you do not want to help them anymore. I often see this used in the content of a recurring problem, usually at the customer’s own doing.

What you want to say is. If this happens again here are the steps you need to do on your own. This will save you time as you won’t have to call us. If you still need to call us after you have done this feel free.

So remember, when talking to customer’s give them something they can either look forward to or something they can do if you can’t fix it in one interaction. Give them a positive takeaway with defined goals or time.


Mikrotik Routeros 7.0beta7

What’s new in 7.0beta7 (2020-Jun-3 16:31):

!) added Layer3 hardware offloading support for CRS317-1G-16S+RM more info here: https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#L3_Hardware_Offloading
!) enabled BGP support with multicore peer processing (CLI only);
!) enabled RPKI support (CLI only);
!) ported features and fixes introduced in v6.47;
!) routing updates, complete status report: https://help.mikrotik.com/docs/display/ROS/v7+Routing+Protocol+Status
!) system kernel has been updated to version 5.6.3;
*) other minor fixes and improvements;