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
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.
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.
From: https://www.icann.org/resources/pages/ksk-rollover/#overview
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.
You must be logged in to post a comment.