Participant Info

  • LocationES
  • Network ASNs49638 60082
  • IX-F IDs11

Implementation of MANRS Actions

  • Action 1: Filtering of Route Announcements Our bird route server at Catnix supports checks and implements the following filtering rules: - It only accepts valid next hops (customer address is in the CATNIX LAN). - It does not accept as-path longer than 32 hops. - It checks the customer AS is the first in the path. - It checks there are not invalid ASN's in the path. - It filters bogon IPv4 and IPv6 addresses - It filters BGP announcements based on IRRDB data (aut-num and as-set objects indicated in the PeeringDB), building the filters every day based on the changes made in the IRR databases. - It does RPKI BGP Origin Validation. - It uses RPKI ROAs as route objects, that is, if an AS-SET is given and it authorizes routes originated by ASx, then all the ROAs which also have ASx as the origin are used as if they were route objects. The AS-SET that includes the peers at the CATNIX Route-server is AS-CATNIX-RS and AS-CATNIX-IP6-RS.
  • Action 2-1: Offer assistance to its members to maintain accurate routing information in an appropriate repository (IRR and/or RPKI) CATNIX actively promotes the MANRS initiative among the membership. For instance, the talk given by CATNIX engineers before the las Technical Commission Meeting in June 2018 was titled “Route-servers and how to make the most of it with manners” ( The route-server at CATNIX implements several filters, as stated in Action 1. Members are informed about the need to be correctly registered and act properly in order not to be filtered by the route server. CATNIX has offered the members its help to keep the Routing information updated in the RIPE Database and also de peeringDB. Several RIPE NCC tutorials have been done at our facilities at CSUC and we are always available to host new RIPE NCC training courses. The last set of courses organized at CSUC included a “Routing Security Training Course” ( and A presentation about peeringDB was also done before the 35th Technical Commission Meeting ( and a tutorial about the registration in peeringDB was sent to the mailing list and is send to new customers (
  • Action 2-2: Offer assistance in implementing MANRS ISP Actions for the members During the last 2 Technical Commission Meetings there has been an active involvement from CATNIX. MANRS T-shirts picked up at the Euro-IX and RIPE meetings were given to 4 members (1 MANRS compliant and 3 willing to implement it). Members were also given stickers and information leaflets from the MANRS initiative and a part of the technical report from the network team was about the MANRS initiative. During the 21st ESNOG Meeting in April, hosted by CATNIX, there was a round table about the MANRS initiative moderated by Maria Isabel Gandia, the Communications Manager at CSUC/CATNIX, with the participation of Jan Zorz and 3 CATNIX members invited by us ( AS13041, also managed by CSUC, is already MANRS-compliant (See Tweet: We have facilitated the links to the materials and tutorials from the MANRS website to our members, and have put AS13041 as an example of a member that has is already in MANRS. Since then, 3 CATNIX members have joint the MANRS community.
  • Action 2-3: Indicate MANRS participation on the member list and the website We have indicated CSUC’s participation in the website ( and in the blog ( It’s not yet in the CATNIX website, because CATNIX is not yet a member, but we will include it once we are able to join. While this happens, we are re-designing the website and the new version will have a section about MANRS.
  • Action 2-4: Provide incentives linked to MANRS readiness The idea that has been transmitted to the members from CATNIX is that belonging to MANRS is a way to let their customers know that they are trustable ISPs. They also have more visibility in the Technical Meetings, because a report about MANRS readiness is presented to the members. It is a way to push the others to appear in the green side of the report.
  • Action 3: Protect the peering platform Some traffic on the peering fabric can be dangerous for CATNIX and its members. That's why CATNIX performs the following actions: • Ports between the customers and the switches at CATNIX must be in access mode (no trunk mode allowed). • Only one known MAC address per port is allowed (port-security). • LLDP is not allowed. • BPDU are not allowed. • Multicast storm-control is configured in the switch ports. Moreover, CATNIX continuously monitors layer 2 traffic on the exchange by taking traffic samples of broadcast and flooded traffic, using the IXP-watch tool. This tool generates alerts when one of the following conditions occurs: Excessive ARP, Excessive traffic captured, Spanning Tree, Non-IP/IPv6 Traffic (for example CDP), Multicast/Traffic directed to - DHCP/OSPF/IGP etc, Stray SNMP. It also generates reports with the number of ARP Queries, ARPs per minute, IPv4 Packets, IPv6 Packets, ICMP Packets, NON-IP Packets, ARPs Sponged and Dead BGP Peers). Links:
  • Action 4: Facilitate global operational communication and coordination between network operators CATNIX has an active technical mailing list where members quickly exchange information in case of any issue. The mailing list is only for members. We also maintain a JSON file with the information from all the members using the Euro-IX format (
  • Action 5: Provide monitoring and debugging tools to the members Since the creation of CATNIX, the looking glass is an important tool that can help debugging problems. Members and users can check what routes are visible in CATNIX. The looking Glass is based on bird-lg and it’s compatible with all devices, like computers and mobile phones. Some of the commands users can run from the looking-glass are bgp map, whois queries and a command history.

Why Catalunya Neutral Internet Exchange Supports MANRS