This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.
One of our open tickets on MidWest-IX is a member reporting slow speeds on their exchange port. After having them send us some data and a few e-mails back and forth we began looking at their switch port on the fabric. Right away we noticed errors on the port. After a counter reset the errors were still incrementing
19 runts 0 giants 1210 CRC 0 no buffer 1329 input error 0 short frame 0 overrun 0 underrun 0 ignored
This led us to look at our LibreNMS data for this port. A quick look shows on October 31st the port started seeing input errors.
By dilling down we are able to see exactly when this started happening
We now have responded to the customer to see if anything changed that day. Maybe a new switch, new optic, or software upgrade. By having this data available in an NMS we were able to cut down on troubleshooting by a huge margin. We now know when the issue started and are closer to the root cause of this. Without this data, we would be spending more time trying to diagnose and track down issues.
For those of you not so familiar with routers
Some photos of the Cambium cnPilot e430w 802.11ac wave 2 dual-band wi-fi wall plate access point.
-802.11AC Wave 2
-2×2 MU-MIMO streams.
-Max Data Rates 1.3 Gbps. 867 Mbps (5 GHz), 400 Mbps (2.4 MHz)
-16 SSIDs across 2 radios
ping -D -s 1472
What the command does
ping = Obvious
-D = Don’t fragment
-s <value> = the ping size.
Why did I start with 1472? That is the total packet size plus 28 bytes, which equals a 1500 byte packet.
Justins-MacBook-Pro:~ j2sw$ ping -D -s 1472 18.104.22.168 PING 22.214.171.124 (126.96.36.199): 1472 data bytes 1480 bytes from 188.8.131.52: icmp_seq=0 ttl=57 time=426.164 ms 1480 bytes from 184.108.40.206: icmp_seq=1 ttl=57 time=110.762 ms --- 220.127.116.11 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 110.762/268.463/426.164/157.701 ms Justins-MacBook-Pro:~ j2sw$ ping -D -s 1473 18.104.22.168 PING 22.214.171.124 (126.96.36.199): 1473 data bytes ping: sendto: Message too long ping: sendto: Message too long Request timeout for icmp_seq 0
If you want to learn how to do this on windows:
One of the common questions I get is what is the difference between Masquerade and SRC-NAt? Which should I use?
The quick answer is to use SRC-NAT if your gateway IP is static, and use masquerade if it can change.
The Mikrotik Wiki Entry
Firewall NAT action=masquerade is unique subversion of action=srcnat, it was designed for specific use in situations when public IP can randomly change, for example DHCP-server changes it, or PPPoE tunnel after disconnect gets different IP, in short – when public IP is dynamic.
Every time interface disconnects and/or its IP address changes, router will clear all masqueraded connection tracking entries that send packet out that interface, this way improving system recovery time after public ip address change.
A little Background on the rollover
ICANN is planning to perform a Root Zone Domain Name System Security Extensions (DNSSEC) KSK rollover as required in the Root Zone KSK Operator DNSSEC Practice Statement [TXT, 99 KB].
Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root’s “trust anchor.” The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet’s DNS.
Maintaining an up-to-date KSK is essential to ensuring DNSSEC-validating DNS resolvers continue to function following the rollover. Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries.
If you are running bind the quickest way to check is this:
If your configuration shows
dnssec-validation yes;, you must change it to
dnssec-validation auto;and restart your server before taking the steps below. This is in your named.conf
Polarity defines direction of flow, such as the direction of a magnetic field or an electrical current. In fiber optics, it defines the direction that light signals travels through an optical fiber.
To properly send data via light signals, a fiber optic link’s transmit signal (Tx) at one end of the cable must match the corresponding receiver (Rx) at the other end.