Is your bad internet experience being caused by your ISP's underperforming DNS? Find out today

So you have finally signed up for that broadband and dedicated internet bandwidth that you ISP has been trying to sell you for the last one year and has been telling you all the nice things that dedicated bandwidth can do! you decided to bite the bullet and release that hard earned cash to experience that fast lane for internet, may be it started out so well on day one but the experience gets worse by the day and soon or later you can't even tell the difference between your old and new connection.

Well, there are other factors that affect internet speeds and trust me you can have a whole pipe of 100Mbps to yourself, but if your ISP's DNS (Domain Name Server) has issues, it will always have a direct impact to your internet experience. 

One of the major performance indicators (a.k.a KPIs) for DNS is the "DNS Response Time"; This is the time it takes (in milliseconds) for the DNS to resolve a requested domain (for example www.facebook.com) into it's corresponding IP (Internet Protocal) address (for example 157.240.7.35).

A slow, overloaded or unreliable DNS has a direct impact on customer's internet experience and noticeably slows down virtually all your internet use. Every ISP has their own DNS infrastructure that is closer to their end users (topology-wise), but this does not directly imply that it will be the fastest DNS in response time. There are many well known publicly available DNS alternatives, which by geo-location and topology-wise are far away from your access device but have better response times and today am going to show you how you can determine that and also optimize your connection.

"You can't optimize it until you can measure it"

Another important point is that your ISP DNS could be in the wrong order, with the secondary DNS performing faster than the primary DNS and this also matters because the requests will always be sent to the primary DNS first. so this article is for both the end user and you the ISP engineer. Am sure you don't want a customer to walk into your office and present to you a report of how publicly available DNS(s) are performing better than your DNS(s)! So you better measure it now and optimize it now.

DNS Benchmark is a freeware tool and you can download it HERE
This tool compares the performance of the ISP DNS with many well known publicly available alternatives. The tool then generates visual reports that compare your ISP DNS response time with other public DNS(s), these reports are easy to interpret and the DNS(s) are ranked according to response time. You don't need to be an expert or geek to use this tool, and you will find the "How tos?" on the download website.

See below a screen shot of the tool and sample report:

DNS Benchmark

DNS Benchmark Report

Based on the results and conclusions from the benchmark, you can determine if you should continue using the DNS(s) provided by your ISP (if they rank top) or if you should change to public DNS(s), that's if the public DNS(s) rank on top of your ISP DNS(s). And if the DNS settings for your connection can't be manually changed, you have the right to walk up to your ISP and challenge them, just make sure to save your benchmark reports.

Going forward, don't let a slow DNS ruin your internet experience. Have fun

Credits: Precision Freeware by Steve Gibson

What are bogon routes & why should they be a concern to ISP network admins?

What are bogon routes?

Bogons are martians (private and reserved addresses defined by RFC1918, RFC5735 and RFC 6598) and net blocks that have been allocated to a regional internet registry (RIR) by the internet assigned numbers authority (IANA).

A bogon prefix is a route that should never appear in the internet routing table therefore packets routed over the public internet with a source address in a bogon range should be discarded.

Why should bogon prefixes be a concern to ISP network administrators?

Bogons are used by malicious internet users and hackers to launch DDoS attacks and IP address spoofing. In fact, most of the frequently attacked sites, 60% of the naughty packets were obvious bogons.

What should you do as an ISP network administrator to guard your network against bogons?

You need to filter and reject or discard bogon routes at your BGP edge router so they don’t enter your routing table as valid destinations. Filtering should be done on both the ingress and egress direction because similarly you don’t want to advertise bogon prefixes to your upstream provider.

However, if you choose to filter bogons you need to have a plan to keep your filters update because these lists change every day especially the full bogon list which has significant changes every day.

You can find the full bogon IPv4 and IPv6 lists here.

Bogon filtering is good and a wise decision but you have to be committed to maintaining it every day, if you just download a full bogons list once and use it to filter at your BGP router without updating it, it will become out of date very quickly and you will end up blocking legitimate traffic.

A good idea is to peer with bogon route servers, it’s a free service and you can apply here. 

In this way, your bogon prefixes will be automatically updated. Any changes in the full bogon prefixes will immediately be reflected in your BGP router which saves you from what would otherwise be a rigorous daily routine of downloading and updating your full bogon lists.

Credits: TEAM CYMRU

Cacti graphs NOT returning the actual interface traffic throughput statistics (bits/sec)

Having successfully installed and configured cacti on RHEL 6.2, i was very excited and i couldn't wait to start monitoring my routers and switches. I work in a network that has over 100 Routers and 500 Switches, and you can imagine what a relief cacti was going to bring to my life!

However, my happiness was short lived after i graphed my first interface and cacti returned wrong values for the bandwidth utilization. This was a high speed interface (Gigabit Ethernet), that carries all our mobile internet traffic and the current throughput was about 400 Mbps, yet the cacti graph was reporting a maximum of 120 Mbps and the graph appeared like it was dropping traffic (crazy graph)! see screen shot below:

Problem:

when you try graphing a high speed interface using SNMPv1 and 32-bit counters in cacti

There was no way i was going to believe this graph, because another proprietary tool was reporting 400 Mbps and my link was very stable. Plus, i logged in the router and ran the interface statistics command and observed an average of 350 Mbps. This meant two things; my cacti tool had issues! or my router doesn't love cacti! at first i suspected the router because it's a HUAWEI NE40 and i have a bias when it comes to Chinese equipment! On so many occasions they have fallen short of the standard protocols. but i was wrong this time, the router is perfect, it was my cacti installation that had issues!

Like always i hit Google to find some answers and below is what i discovered before i finally fixed my cacti installation (Am super excited i did, and if you are in the same situation, i wish you the best).

Below are the lessons i learned, call them solutions:

Solution:

1. For high speed interfaces, you should use 64-bit counters if the device you are trying to monitor supports them. (refer to this article)

High Speed interfaces (100 Mbps or above)

• ifHCInOctets: 1.3.6.1.2.1.31.1.1.1.6 (64-bit Octets in counter)
• ifHCOutOctets: 1.3.6.1.2.1.31.1.1.1.10 (64-bit Octets out counter)
• ifHCInUcastPkts: 1.3.6.1.2.1.31.1.1.1.7 (64-bit Packets in counter)
• ifHCOutUcastPkts: 1.3.6.1.2.1.31.1.1.1.11 (64-bit Packets out counter)
• ifHighSpeed: 1.3.6.1.2.1.31.1.1.1.15 (An estimate of the interface's current bandwidth in units of 1Mbps)

Low Speed interfaces

Lower speed interfaces can get by with 32-bit counters. If you use 32-bit counters on high-speed interfaces, they can wrap quickly; a 10 Mbps stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes. At 100 Mbps, the minimum wrap time is 5.7 minutes, and at 1 Gbps, the minimum is 34 seconds

• ifInOctets: 1.3.6.1.2.1.2.2.1.10 (32-bit Octets in counter)
• ifOutOctets: 1.3.6.1.2.1.2.2.1.16 (32-bit Octets out counter)
• ifInUcastPkts: 1.3.6.1.2.1.2.2.1.11 (32-bit Packets in counter)
• ifOutUcastPkts: 1.3.6.1.2.1.2.2.1.17 (32-bit Packets out counter)
• ifSpeed: 1.3.6.1.2.1.2.2.1.5 (Currently negotiated speed of the interface - Max: 4.294 Gbps)

2. This was a great piece of information to land on, and i thought my problems where solved! but i was yet to learn more. I deleted the graph i had created with 32-bit counters and created one with 64-bit counters and hoped for the best. But sorry, the graph came out just as before, crazy!
Another hour bouncing around Google, i found out that 64-bit OID counters are only supported in SNMPv2 yet i was still using SNMPv1!

3. To confirm if my router can support 64-bit OIDs, i tried an SNMPWALK from my cacti server and it returned the correct values. replace the community_string with your actual community string e.g "public" and ip_address with the ip address of the router you are trying to monitor.

//64-bit Octets In Counter
snmpwalk -v2c -c community_string ip_address 1.3.6.1.2.1.2.2.1.6
//64-bit Octets Out Counter
snmpwalk -v2c -c community_string ip_address 1.3.6.1.2.1.31.1.1.1.10

4. At this point, i was using 64-bit counters and SNMPv2 for the snmpwalk test above, so i thought it was a done deal (problem solved!). i deleted the device from cacti and created it again using SNMPv2 and created the graph using 64-bit counters (combined two of the information pieces that i had learnt), and this time round, the graph was empty :-(, And whenever i would try running snmp query in debug mode via cacti, the query was successful but "NO SNMP DATA RETURNED!!!!!"

5. Google again was my immediate friend, and after about 5 hours of reading other people's problems, i landed on my third piece of important information; The php-snmp module requires a version of PHP 5.4 and above to be able to handle "snmpbulkwalks" used in SNMPv2. Refer to this article for details.

6. I was running PHP 5.3 at the moment and i never had PHP-SNMP module installed, i think my installation was using NET-SNMP to do snmpwalks which if you are only dealing with SNMPv1 should be enough to get you cacti working. See how i installed and enabled the PHP-SNMP module here.

7. I upgraded my PHP installation to version PHP 5.5, enabled the PHP-SNMP module, restarted Apache and everything was smooth afterwards. The snmp "Verbose Query" was returning data, i re-created my devices with SNMPv2 and tested. See how my graph returned the correct values (400 Mbps) and it was smooth & accurate. I wish the same for you. Have fun :-)

Cacti Monitoring High Speed Interfaces with SNMPv2 and 64-bit counters