Good MANRS for IXPs route servers made easier

Posted on by Pier Carlo Chiodi
No Comments

Now, more than ever, we need a more resilient Internet.

This is the first sentence that shows up on the website of MANRS, a global project that aims to improve the security of Internet routing. Every network is in a good position to actively pursue such an important goal, and MANRS helps them by offering different programmes with guidelines and suggestions based on industry best practices, focused on the role of each network: ISPs, CDNs, Internet Exchange Points (IXPs).

In this post I’ll focus on the IXP programme, and I’ll share some thoughts on how ARouteServer, a tool I’ve been working on for several years, can help IXP operators to easily deploy and operate secure route servers and meet MANRS requirements.

Read more …

Categories: Networking, Security | Tags: , , , , , ,

Route server feature-rich and automatic configuration

Posted on by Pier Carlo Chiodi
No Comments

So, lately I’ve spent my spare cycles on a tool to automate route servers configuration and, finally, ARouteServer came out: “A Python tool to automatically build (and test) feature-rich configurations for BGP route servers.”

Actually I don’t know how this idea came to my mind, I’ve never run an Internet Exchange nor a route server. Simpl(y|istically) I thought that an open source tool, which everyone can contribute to, with some good builtin features and based on an abstract definition of policies which are automatically converted into BGP-speaker-specific configuration files would have been useful to the community.

Thought to be used with any BGP speaker, currently it has been focused on the BIRD implementation to shorten development times and to have something that could be usable supports BIRD and OpenBGPD. TL/DR: a couple of YAML files (general policies + clients list) and some configuration knobs bring to a configuration that offers RPKI/IRRDB validation, BGP filtering best-practices, blackhole filtering capabilities, announcement control via BGP communities and other features.

A live testing framework also allows to run custom scenarios to simulate a real clients/server environment where it’s possible to test the configurations produced by the script.

Reviews and testing needed

Now, as said previously, I’ve never run a route server: the project needs reviews, advices and testing from the real life. Anyone who wants to contribute or share his/her point of views is more than welcome! Please open an issue on GitHub or drop me a message for any comment.

Presentations

  • RIPE74, 10 May 2017, Connect Working Group: video (9:53), slides (PDF)
    • Categories: Networking | Tags: , , , , , ,

    Large BGP Communities playground

    Posted on by Pier Carlo Chiodi
    No Comments

    Lately, in the IETF Inter-Domain Routing (idr) area, various efforts are going on to push a (IMHO) winning idea to solve a 32-bits-wide problem: standard BGP communities are no longer enough to describe routing policies which involve 4-byte ASNs. For example, how can I tell my transit provider to not announce my prefixes to AS65551 (a 4-byte ASN) using a schema like 65500:nnn do not announce to peer nnn? Well, draft-heitz-idr-large-community proposes a simple and quick solution to this problem: Large BGP Communities (http://largebgpcommunities.net/ for more info).

    Many vendors seem to like the idea, some of them have already published a working implementation, others plan to work on it in the (hopefully) near future.

    In order to test current implementations and see them with my own eyes I wanted to build a Large BGP community playground, just a way to have the new code up & running quickly. Hopefully I will keep it up to date as soon as more vendors release their code.

    GoBGP:

    # gobgp neighbor 192.0.2.2 adj-in
    Network Next Hop AS_PATH Age Attrs
    203.0.113.1/32 192.0.2.2 65536 00:14:49 [{Origin: i} {LargeCommunity: [ 65536:1:2]}]

    ExaBGP:

    Thu, 15 Sep 2016 14:15:18 5 routes peer 192.0.2.3 ASN 65537 << UPDATE (1) ( 4) attributes origin incomplete as-path [ 65537 ] large-community 65537:3:4

    It’s on GitHub: comments or suggestions would be greatly appreciated.

    Categories: Networking | Tags: , , , , ,

    RFC7050 (DNS64 prefix via ipv4only.arpa) on RIPE Atlas probes

    Posted on by Pier Carlo Chiodi
    No Comments

    You know when in the morning you wake up and a thought flashes across your mind? One of these mornings I had this: how many RIPE Atlas probes are on a NAT64/DNS64 scenario? RFC7050 can help to answer this question.

    Read more …

    Categories: Networking | Tags: , , , , , ,

    Network monitoring: ripe-atlas-monitor

    Posted on by Pier Carlo Chiodi
    No Comments

    A post I wrote for RIPE Labs has been published today: The RIPE Atlas Monitor – Network Monitoring with RIPE Atlas.

    It’s about a Python tool I developed to monitor results collected by RIPE Atlas probes and verify they match against predefined expected values: ripe-atlas-monitor:

    descr: Check network reachability
matching_rules:
- descr: Probes from France via AS64496
  src_country: FR
  expected_results: ViaAS64496
  actions: EMailToNOC
- descr: RTT from AS64499 and AS64500 below 50ms
  src_as:
  - 64499
  - 64500
  expected_results: LowRTT
  actions: EMailToNOC
expected_results:
  ViaAS64496:
    upstream_as: 64496
  LowRTT:
    rtt: 50
actions:
  EMailToNOC:
    kind: email
    to_addr: noc@agreatcompany.org
    subject: "ripe-atlas-monitor: unexpected results"
measurement-id: 123456789

    For more details: GitHub / official documentation site.

    Contributions and suggestions from the community are very welcome!

    Categories: Networking | Tags: , , , ,