Sep 25 2025

Some interesting stuff I found on IX LANs

These days the internet as a whole is mostly constructed out of point to point ethernet circuits, meaning an ethernet interface (mostly optical) attached directly from one routing device to another routing device.

However that is not always the case, as the humble “internet exchange” (IX) still exists, and while the relevancy of IXs are progressively being diminished by the internet increasingly being concentrated into a small handful of content networks and IXs not keeping up with the lowering price of transit or private fiber connections to the largest networks, there are still a large number of networks that’s attached to at least one IX fabric.

IXs are a little bit strange, as they are at their core practically identical to a simple ethernet switch you may find in your home or office (except your home switch is unlikely to be doing terabits per second of traffic). As IXs depend on the ethernet switches interest in only being the MAC addresses of traffic and not the Layer 3 IP addresses.

However home and small and medium business (SMB) routers often come with defaults that make life a lot easier for networks way of desktop computers and common office equipment on them, these same defaults are at the very least annoying and at the very worst actively exploitable if put on a IX LAN with many untrusted participants.

bgp.tools “naughty packets” feature

The company that I run and operate has a large number of ports at internet exchanges (at a rough estimate I am the top 13 of all networks on the internet in this metric!), and alongside the route collecting that bgp.tools does on these IX ports, it also listens in on the broadcast and multicast traffic that happens on these exchanges.

This isn’t that magical, at its core it works by running tcpdump on each IX port, and picking up the BUM traffic, parsing what it is looking at (and throwing away the unknown unicast, since that is a separate common problem that I don’t want to get involved with), and reporting that data back up the chain to bgp.tools’s website.

This creates little warning icons (or alerts if they use the monitoring product) on their IX membership rows to let them and others know that something is not configured correctly

When I first started off developing this feature I was basically going off the top of my head on what the obvious mistakes that were likely to happen on misconfigured IX ports. However at the same time I developed a “miscellaneous packets” feed that collected packets that I didn’t have code to deal with.

Here are all of the things that have found

Checking that miscellaneous packet feed every week has been a lot of fun and deeply terrifying on what networks have been sending into exchanges. Here are some of the things that bgp.tools finds on a regular basis

Router/Switch Identification

With large deployments of routers and switches it is often very difficult to actually locate where each device is plugged into at either end. For this exact reason, many vendors ship protocols that emit various identifier packets that are designed to help operations teams identify the “far side” of each port

LLDP

Commonness: Low

Operational Danger: Low

Security Danger: Information Disclosure

Link Layer Discovery Protocol is a pretty common cross vendor protocol for doing exactly this, it is also sometimes used to automatically configure capabilities like higher wattage power over ethernet.

Here’s an example of a LLDP packet (and what information it discloses) from my own network:

root@blah:~# lldpctl 
------------------------------------------------------------------
LLDP neighbors:
------------------------------------------------------------------
Interface:    ens1f0, via: LLDP, RID: 3, Time: 146 days, 02:13:47
  Chassis:     
    ChassisID:    mac 1c:34:da:90:90:01
    SysName:      bgptools-switch
    SysDescr:     Debian GNU/Linux 12 (bookworm) Linux [...]
    MgmtIP:       10.xxx.xxx.2
    MgmtIface:    3
    MgmtIP:       fdd2:xxx::1
    MgmtIface:    3
    Capability:   Bridge, on
    Capability:   Router, on
    Capability:   Wlan, off
    Capability:   Station, off
  Port:        
    PortID:       mac 1c:34:da:90:90:26
    PortDescr:    swp8
    TTL:          120
    PMD autoneg:  supported: yes, enabled: yes
      Adv:          1000Base-X, HD: no, FD: yes
      MAU oper type: 10GigBaseCX4 - X copper over 8 pair 100-Ohm balanced cable

CDP

Commonness: High

Operational Danger: None

Security Danger: Information Disclosure

Cisco Discovery Protocol is a older and proprietary to Cisco (although that does not stop many vendors from having copied it) version of LLDP

MNDP

Commonness: High

Operational Danger: None

Security Danger: Information Disclosure

The popular budget network equipment vendor Mikrotik ships by default with a feature called “Mikrotik Neighbor Discovery Protocol” enabled by default.

Here is an example decoded MNDP packet from a network on FranceIX

    Seq: 134398
    MAC Address: 08:55:31:1b:9c:aa
    Identity: DC2.A23.CCR02
    Version: 6.49.6 (stable)
    Platform: MikroTik
    Uptime: 2239h52m39s
    SoftwareID: HBWH-7QHV
    Board: CCR1009-7G-1C-1S+
    IPv6Address: 2001:7f8:54::1:85
    InterfaceName: FRANCE_IX
    IPv4Address: 37.49.237.85

We can see what they named the device , what type of device it is, the interface name (FRANCE_IX), and the device uptime.

Automatic Addressing

Most consumer devices when they come on the network do not know what IP address/gateway they are supposed to be using, This is because in most environments you do not want to have machines that have statically configured addresses.

However IX’s are not these kinds of environments, as they are environments where all participants have been assigned a very specific IP address to use on the LAN. This does not stop these automatic IP address assignment protocols from attempting to grab IP addresses with some configurations.

DHCP / DHCPv6

Commonness: Medium

Operational Danger: High

Security Danger: Targeted traffic redirection

This is the exact same protocol that your mobile phone or laptop is using, just being blasted out to terabit/s per second switching fabrics. When a IX participant is asking for addresses with DHCP on the exchange, any one of the entities connected (some of which may be considered adversaries of your state) could reply to their request and assign them an IP address and default gateway, the latter possibly redirecting large amounts of traffic through them!

IPv6 RA

Commonness: High

Operational Danger: People using your network for free

Security Danger: Low

IPv6 Router Advertisement is a protocol where routers periodically announced onto the LAN but they are capable of acting as a gateway (and optionally include instructions for clients to generate IPv6 addresses automatically), this is useful for IPv6 deployment, but this behavior is absolutely not desirable on internet exchanges as you do not want to have people use you as a gateway for the entire internet over peering LANs, as effectively giving them free internet transit, which is typically bad for business.

Unfortunately this feature is enabled by default on Cisco and Arista, meaning it is so common that bgp.tools has a dedicated icon for it on the site.

Non BGP Routing Protocols

On exchanges there is generally only one accepted routing protocol that is allowed to be used between members and that is BGP. However that does not seem to stop other networks from accidentally enabling other protocols, some of which automatically “flood” messages to broadcast so they can look for peers to automatically establish relationships with.

OSPF and IS-IS / ES-IS

Commonness: Low

Operational Danger: You will import other peoples internal routes

Security Danger: People can insert routes into your network

OSPF and IS-IS are the classic internal routing protocols that a lot of networks use to manage their internal routing table. This internal routing table is where the more specific routes for individual customers or subscriber pools exist.

While OSPF and IS-IS offer an ability to restrict sessions that are automatically started without a given password in configuration, a decent number of networks do not use this feature.

The result of this is if these networks without a password configured meet each other on the internet exchange with OSPF/IS-IS configured they will automatically exchange internal routing tables of each other, the effects of this could range between a security risk because an attacker could inject routes into their internet routing table, all the way to a full blown outage as there would be overlap in internal network routes.

RIP / RIPv2

Commonness: Rare

Operational Danger: You will import other peoples internal routes

Security Danger: People can insert routes into your network

Routing Information Protocol is a very old way of doing what OSPF and IS-IS does on most modern networks today.

RIP and RIPv2 have similar automatic peer configuration features, meaning that if two or more members on an internet exchange have this configured they will almost certainly automatically merge their internal routing tables.

MPLS LDP

Commonness: Rare

Operational Danger: People can manipulate MPLS labels

Security Danger: People can manipulate MPLS labels

MultiProtocol Label Switching Label Distribution Protocol is a different type of internal routing protocol that rather than dealing with IP prefixes, handles the exchange of MPLS Labels. Given that a lot of networks deploy MPLS as the core way of moving data around in their network, exposing this to another untrusted party is pretty bad.

Various vendors loop testing protocols

Commonness: Low

Operational Danger: None

Security Danger: None

Quite a lot of vendors have their own form of proprietary ethernet loop detection, which often involve sending out probing packets into the LAN and seeing if they arrive back on any other interface (which would indicate a loop)

For example, here is a loop testing packet from a Huawei device

Spanning Tree (of various flavors)

Commonness: Medium

Operational Danger: Local disruption

Security Danger: None

Spanning Tree Protocol is a very common default that is enabled across most ethernet switches to combat ethernet loops. However accepting STP packets and sending them to other members of the exchange could result in disruption to the peer, as both sides try to agree a hierarchy with each other.

The problem with SONiC

SONiC is an open source network operating system (NOS) developed mostly by Microsoft, this is notable because almost all network operating systems are proprietary with no source code available. There are many reasons for this but one of the primary ones is that while there are many networking equipment vendors out there, the actual fundamental ASIC/Chips suppliers that are used to build high end equipment are limited down to around 3, with the majority of the market share being Broadcom. SONiC has in recent years become the most well known by name open source NOS.

Unfortunately SONiC is also just not a very good pick for almost all users, and mortally let down by its software quality. An example of this is a script called arp_update that transmits a “Ping all IPv6 devices” packet to all connected LANs so that it can work around a potential limitation in the hardware that it supports. This is a nuisance on internet exchanges because once there are more than a handful of these devices on the exchange, every one is spending a non zero amount of resources responding to pointless pings.

It’s hard for me to understate how crap of a workaround this is, and how much more crap this is for devices with internet exchange ports.

Weird misc stuff that should not be on internet exchanges

There is a final category for things that are kind of just bizarre to see. They are just things that should not actually appear at all on any internet exchange port, and suggest something strange has happened. Either with unexpected devices being connected into the exchange fabric entirely, or very inadvisable configurations being used for public “network edge” ports.

Broadcast NTP

Commonness: Low

Operational Danger: None

Security Danger: None

While Network Time Protocol is very common, most of the time it is configured in a unicast way (meaning that a device deliberately queries a NTP peer), however there is a lesser used broadcast mode where a server broadcasts the time into the LAN on regular intervals.

Unfortunately some networks have decided to enable this on their internet exchange ports, meaning that all members are receiving (but are unlikely using) these packets.

It doesn’t help that almost every single time I have seen one of these situations, the time being broadcast itself is wrong by at least a few days implying that a device itself does not actually have a good source of time, and it’s just drifting from it’s original set up

MikroTik Winbox / MAC-Telnet

Commonness: Medium

Operational Danger: None

Security Danger: Exposure of a remote configuration interface to untrusted networks

Once again our friend MikroTik comes back with some interesting defaults, In this case the RoMON protocol that allows their GUI management interface (WinBox), and the ability to “telnet” into a neighboring device with just its MAC address.

The logic behind the telnet feature is that it is useful for when you need to go to recover a device that you may have accidentally set a bad firewall or IP address/routing configuration on. However that does also mean that bgp.tools has traces of people using this telnet feature (which often broadcasts keystrokes and outputs) to all members. Implying that some networks are using the IX LAN (presumably by borrowing another member’s router) as a recovery mechanism for their misconfigurations.

DEC-MOP

Commonness: Medium

Operational Danger: None

Security Danger: Exposure of a legacy protocol to untrusted networks

The Digital Equipment Corporation (Yes, the PDP-11 company) developed a series of network protocols called DECnet. While it is unlikely that you will ever encounter a device that needs DECNet support, Cisco by default enables this protocol on all interfaces (unless explicitly configured otherwise) on all enterprise software versions for IOS/IOS-XE.

SSDP (UPNP)

Commonness: Rare

Operational Danger: None

Security Danger: Allowing untrusted networks to configure your device

Simple Service Discovery Protocol and its’s most common implementation use case Universal Plug and Play is a protocol normally only ever found in the home/residential networking space. It allows for simple configuration for things like port forwarding. Since no one should be connecting such hardware to IX LANs, this is generally a sign of a serious misconfiguration.

LLMNR / MDNS

Commonness: Rare

Operational Danger: None

Security Danger: Information Disclosure

Multicast DNS and Link-Local Multicast Name Resolution are protocols used mostly by desktop computers to locate other things on the network (typically home or small biz networks) by name.

MDNS is also very common in the automatic discovery of network printers, it also happens to be what I discovered the most on various exchanges

While this is obviously ridiculous that a printer would be attached to an IX, what is likely actually happening here is that linux distributions like Debian will/would offer a “print server” role enabled by default. Since Linux “software routers” based on Debian are common in some regions, it doesn’t necessarily surprise me that these routers were installed with the print server role left enabled by mistake when they the operating system was installed.

NETBIOS

Commonness: Rare

Operational Danger: None

Security Danger: The exposure of Windows or SMB to untrusted networks

NETBIOS is often used to power SMB/Samba, the Windows file and printer sharing protocol.

When I first encountered this packet I assumed that this was going to be a windows server configuration that had been let onto the exchanged by mistake, as encountering windows servers acting as edge routers is unheard of (although windows does actually have a bgp implementation, it is not designed for edge peering and so would make an extremely poor edge router)

Upon further inspection of the packets it appears that what has actually happened here (at least 6 different times) is desktops/laptops have been let into the exchange instead. I can tell this because windows will automatically generate host names like SERVER-ABCD1234 for windows server installations, and DESKTOP-ABCD1234 for desktop/laptop ones, and NETBIOS packets often include the hostname of the system that is querying.

I can only assume this has happened due to incorrect physical cable patching or VLAN translation.

VRRP/HSRP

Commonness: Low

Operational Danger: Untrusted networks could trigger failover of your routers

Security Danger: None

Virtual Router Redundancy Protocol and Hot Standby Router Protocol are protocols that are designed to allow two routers to automatically take over from another if they fail. To do this the protocol sends packets on a regular interval into the LAN that has the gateway ip address that is being protected from downtime.

While redundancy is obviously desired on exchanges, this is typically done by actually attaching two discrete routers to the exchange with different LAN IP addresses, so VRRP and similar protocols are not appreciated configurations.

DNS-Broadcast

Commonness: Medium

Operational Danger: Embarrassment

Security Danger: Information disclosure

When Cisco devices are unable to find a working DNS resolver, they resort to broadcasting the DNS query on all interfaces, Most of the time this just means that the Cisco licensing server (the “cslu-local”) is queried for, with an added bonus of the owners DNS search domain (if they have configured one)

So filtering for these packets is quite easy, and results in pretty much exactly what you would think.

$ tcpdump -nr dns.pcap |& pcregrep -o1 '\] A{1,4}\? ([^\)]+)' | awk '{print $1}' | sort | uniq -c | sort -n | tail -n 15
    875 cslu-local.{CORP-F}
    998 cslu-local.{CORP-F}
   1162 tools.cisco.com.{Military-A}.
   1648 cslu-local.{CORP-G}
   1659 cslu-local.{CORP-F}
   1880 cslu-local.{CORP-E}
   2088 tools.cisco.com.{CORP-A}.
   2910 cslu-local.{CORP-D}
   4213 cslu-local.{Military-A}.
   5125 cslu-local.{CORP-C}.com.
   5515 cslu-local.{CORP-B}.fr.
   7367 cslu-local.{CORP-A}.com.
   7675 tools.cisco.com.
   9934 cslu-local.{Military-A}
  10838 cslu-local.

Except Cisco also has another interesting default back from the days when Cisco sold dedicated terminal servers where you would dial into the device (over the phone), and then type the device name you were looking to connect to.

In practice everybody should be disabling this function in 2025, however by default it is enabled, so if you log into the Cisco CLI and make a typo (let’s say for this example you forgot the you’re on a cisco rather than a huawei), this happens:

The CLI just hangs, as it broadcasts your typo onto all interfaces…

Anyway with a little bit of careful processing we can see all of these typos and sometimes the search domain from where they came from:

$ tcpdump -nr dns.pcap |& pcregrep -o1 '\] A{1,4}\? ([^\)]+)' | awk '{print $1}' | sort | uniq -c | sort -n | egrep -v  'cslu|tools.cisco.com'

      1 cls.basetelco.com.
      1 configre.jato3.com.
      1 conft.asn28176.com.br.
      1 conft.powernet.net.br.
      1 cont.wanfiber.net.br.
      1 cpnf.cd.net.za.
      1 end.3cta.eb.mil.br.
      1 end.as37497.net.
      1 end.cd.net.za.
      1 end.spnet.com.br.
      1 exiexit.cd.net.za.
      1 exit-address-family.
      1 exitr.jfsc.local.
      1 expression.jato3.com.

I’ve collected favorite most common typos below:

$ tcpdump -nr dns.pcap |& pcregrep -o1 '\] A{1,4}\? ([^\)]+)' | awk '{print $1}' |& pcregrep -o1 '^([^.]+)' | sort | uniq -c | sort -n 
...

      1 access-list
      1 configre
      1 cont
      1 cpnf
      1 exiexit
      1 exit-address-family
      1 exitr
      1 exti
      1 extit
      1 ifconfig
      1 int
      1 interface
      1 qconft
      1 qqq
      1 reboot
      1 uptime
      2 coinf
      2 Please
      2 shorun
      2 top
      4 ip
      4 ping
      6 save
      9 conft
     87 y
     92 quit
    134 q
    289 summary

There is of course an added danger while having this enabled that you could actually answer these queries and then trick an operator into typing into a terminal that you control. But I suspect that almost all operators would notice something like that happening, making such a trick difficult to pull off.

How can IXs prevent this?

While pretty much all exchanges have rules that define the kind of traffic that you are allowed to be sent into the internet exchange fabric that would forbid almost all of these types of packets from being sent ( For example, here is AMS-IX’s list of rules ), enforcement of these rules is nonexistent in most exchanges.

Which is a shame really because a lot of this can be automatically done with simple access control lists (ACLs) that target just mac addresses alone.

DEC-MOP, RoMON, STP, CDP, IS-IS, ES-IS, LLDP, VRRP, OSPF, IPv6 RA are remarkably common, and yet they use specific MAC address destinations that could just be filtered out on all ports, preventing them from being seen by other IX participants.

While [LLMNR, NetBIOS, PIM, LDP, MDNS, DHCPv4 /DHCPv6, SSDP, DNS-Broadcast, Broadcast NTP, MikroTik Discovery] do require the IX device to be able to inspect Layer 3 headers like UDP port numbers in ACLs, this feature is very common among deployed hardware in the industry.

Even if exchanges are not able to automatically enforce policy using ACLs, there are open source projects like IXP-Watch and systems like bgp.tools that will monitor this for you.

There shouldn’t really be an excuse for things to be this way!

---

If you want to stay up to date with the blog you can use the RSS feed or you can follow me on Fediverse @benjojo@benjojo.co.uk

Until next time!