Quarantine Checks

Quarantine Checks Reference

This page provides detailed information about each quarantine check available in the IXP Digital Twin.

Overview

Quarantine checks validate customer compliance with IXP technical policies before production connection. Each check verifies a specific aspect of the customer's configuration and behavior.

All configuration snippets below are fragments of the quarantine section in ixp.conf.

Check Categories

Checks are organized into three categories:

• Connectivity - Basic network connectivity
• BGP - BGP protocol compliance
• Security - Security and policy compliance

Connectivity Checks

connectivity.CheckPingAction

Purpose: Verifies basic layer 3 connectivity via ICMP ping.

How it works:

1. Each route server sends ICMP echo requests to the participant peering address of the same IP version
2. The check parses the ping output
3. The check fails if packet loss is greater than zero

Failure conditions:

• [RS name] is facing loss of X% to IP [participant IP] — the participant has partial or total packet loss.
• Error in pinging IP [participant IP] from [RS name] — the ping output could not be parsed.

Configuration:

{
  "quarantine": {
    "actions": [
      "connectivity.CheckPingAction"
    ]
  }
}

connectivity.CheckPingMtuAction

Purpose: Verifies that 1500-byte ICMP packets can be exchanged with the participant.

How it works:

1. Each route server starts a packet capture for ICMP/ICMPv6 traffic to the participant
2. It sends 5 ping packets sized to reach an MTU of 1500 bytes
3. It compares the number of echo requests and echo replies seen in the capture

Failure conditions:

• Link from [RS name] to [participant IP] is not able to send 1500 bytes packets — the number of echo replies does not match the number of echo requests.

Configuration:

{
  "quarantine": {
    "actions": [
      "connectivity.CheckPingMtuAction"
    ]
  }
}

connectivity.CheckProxyArpAction

Purpose: Verifies that the participant does not reply to Proxy ARP requests.

How it works:

1. Each route server sends ARP requests for the configured proxy_arp_ips
2. The requests are directed to the participant MAC address
3. The check fails if the participant replies for any configured IP

Failure conditions:

• Candidate router replied to Proxy ARP from [RS name] for IPs [IP list] — the participant MAC address replied to ARP requests for one or more of the configured proxy_arp_ips.

Configuration:

{
  "quarantine": {
    "actions": [
      "connectivity.CheckProxyArpAction"
    ],
    "proxy_arp_ips": [
      "192.0.2.254",
      "192.0.2.253"
    ]
  }
}

BGP Checks

bgp.CheckBgpSessionAction

Purpose: Verifies BGP session establishment with the route servers.

How it works:

1. The check queries the route server control plane for the participant neighbor state
2. It verifies that the remote AS is present
3. It verifies that the session uptime is present
4. It verifies that the remote AS matches the participant ASN

Failure conditions:

• Error in getting session information for IP [participant IP] from [RS name] — the route server command failed, returned no output, or the remote AS could not be parsed.
• BGP Session to AS [ASN] is not up for IP [participant IP] from [RS name] — the session has no uptime, meaning it is not established.
• BGP Session established to AS [actual AS] instead of AS [expected AS] for IP [participant IP] from [RS name] — the negotiated remote AS does not match the participant ASN.

Configuration:

{
  "quarantine": {
    "actions": [
      "bgp.CheckBgpSessionAction"
    ]
  }
}

bgp.CheckBgpRibAction

Purpose: Validates routes announced by the participant from the route server RIB.

How it works:

1. The check reads the participant RIB from each route server
2. It fails if the RIB is empty
3. It verifies that the number of announced prefixes does not exceed max_rib_prefixes
4. It verifies that the participant does not announce the default route
5. It verifies that the participant does not announce private prefixes
6. It verifies that the next hop matches the participant IP address
7. Verifies that the participant ASN is the next ASN in the AS path
8. It verifies that all route servers receive the same announced prefixes

Failure conditions:

• Error in getting session information for IP [participant IP] from [RS name] — the route server command failed or returned no output.
• RIB is empty for IP [participant IP] from [RS name] — no prefixes are announced by the participant.
• # advertised prefixes (N) is more than # maximum prefixes (M) for IP [participant IP] from [RS name] — the announced prefix count exceeds max_rib_prefixes.
• IP [participant IP] announced default route from [RS name] — the participant is announcing the default route ( 0.0.0.0/0 or ::/0).
• Prefix [prefix] is in the private range for IP [participant IP] from [RS name] — the participant is announcing a private prefix.
• Prefix [prefix] has [next hop] as nexthop for IP [participant IP] from [RS name] — the next hop for a prefix does not match the participant IP address.
• Prefix [prefix] has AS Path [path] not starting with [ASN] from [RS name] — the participant ASN appears in the AS path but is not the first element.
• # announced prefixes on [RS1] differs from the ones on [RS2] — different route servers received different prefix sets from the participant.

Configuration:

{
  "quarantine": {
    "actions": [
      "bgp.CheckBgpRibAction"
    ],
    "max_rib_prefixes": {
      "4": 5000,
      "6": 2000
    }
  }
}

Security Checks

security.CheckServicesAction

Purpose: Verifies that DNS, NTP, and SNMP are not responding on the participant address.

How it works:

1. The check builds and deploys a probe container connected to the participant collision domain
2. The probe uses the configured probe_ips address for the participant IP version
3. It checks DNS with dig using the configured dns_name
4. It checks NTP with ntpq
5. It checks SNMP with snmpwalk

Failure conditions:

• Error while building Docker image — the probe Docker image could not be built.
• DNS responding on IP [participant IP] — the participant replied to the DNS query.
• NTP responding on IP [participant IP] — the participant replied to the NTP query.
• SNMP responding on IP [participant IP] — the participant replied to the SNMP walk.

Configuration:

{
  "quarantine": {
    "actions": [
      "security.CheckServicesAction"
    ],
    "probe_ips": {
      "4": "192.0.2.10",
      "6": "2001:db8::10"
    },
    "dns_name": "example.org"
  }
}

security.CheckTrafficAction

Purpose: Detects unauthorized traffic involving the participant.

How it works:

1. The check copies the traffic dumper script into each route server
2. It captures traffic for the configured traffic_dump_mins
3. It reports packets classified as unauthorized by the traffic dumper

Failure conditions:

• Unauthorized traffic on [RS name] — one or more packets were classified as unauthorized by the traffic dumper.

Classification rules used by the traffic dumper:

• Always unauthorized:
  • Any STP packet.
• Unauthorized when involving the participant MAC (source or destination):
  • The packet does not match any allowed exception listed below.
• Allowed exceptions (not flagged):
  • Traffic where the other MAC belongs to a known IXP member.
  • IPv4 broadcast ARP packets.
  • IPv6 Neighbor Discovery NS/NA packets.
  • Participant-originated BGP traffic on TCP port 179.
  • Participant-originated ICMP/ICMPv6 echo request/reply traffic.

Configuration:

{
  "quarantine": {
    "actions": [
      "security.CheckTrafficAction"
    ],
    "traffic_dump_mins": 1
  }
}