NTAC Peering Working Group

[Steven Wallace <>]

Here’s a draft of something that might provide some context/answers:

There’s a network reachability problem (i.e., certain sites can’t be reached despite an apparent valid network path) that may also cause problems for users of DDoS cloud-based scrubbing services. The underlying cause is how IP packets are routed, and how the routing information is distributed.

Internet routers receive routing information from other routers and their local configuration.  The routing information is compiled into a table, known as the routing table, or more formally the routing information base (RIB). Understanding this next part is important, as it’s the core of the problem. The router looks for the longest prefix match to find the valid route for a packet. Suppose the router has to route a packet to 129.79.1.4. A routing table might contain two routes that match this destination: 129.79.0.0/16 (e.g., matches everything that starts with “129.79”) and 129.79.1.0/24 (e.g., matches everything starting with “129.79.1.”) Both of these routes match 129.79.1.4, however only the “longest match” is valid.

When a network is multihomed (is peering with two or more upstream providers), it should receive routing information from all of its peers. Unfortunately existing router equipment may not have the memory to accommodate a complete routing table. In such cases, a network may decide to receive routing information from a subset of their peers, and send packets for which there is no match to their Internet transit provider.

If a network isn’t able to accept all routes from its peers, the following can cause network reachability problems. If a peer is sending the route for 129.79.0.0/16, then you’d think a packet addressed to 129.79.1.4 would match that route. However, if another peer had the route for 129.79.1.0/24, but your router wasn’t accepting that peer’s routes, the ONLY VALID ROUTE for 129.79.1.4 would be ignored, and the packet would be sent along the wrong path.

Sometimes packets sent along the wrong path will still arrive at their destination, however sometimes they won’t.

On Apr 20, 2017, at 3:54 PM, Pete Siemsen <> wrote:

Ok, I forwarded these notes to some colleagues, and got back "Please explain item 6 in more detail. Why does traffic get "blackholed by TR-CPS or its peer," and why are connectors with full routes immune to this issue?.

I had to admit that I'd zoned out during actual call, attempting to do two things at once, and learning once again that I can't :-)

Anyone care to enlighten me, please?

-- Pete

On Wed, Apr 19, 2017 at 9:02 AM, Matt Mullins <> wrote:

Here are the notes from yesterday’s meeting. Please feel free to correct any mistakes I have made.

 

1. Agenda Bash

2. Update on peering and TR-CPS/I2

·         Move Charter from 1GE to 10GE in Ashburn/Chicago/Dallas. Seattle to move to public exchange.

·         Capacity updates for Amazon for TR-CPS in Ashburn/Chicago for Amazon.

 

3. Network Weather Update

§  Nothing to update.

 

4. RPKI Update

·         Not much progress to report.

·         Will be a BoF at Global Summit.

 

5. Network DDoS Scrubbing Service Update

·         Close to signing contracts with Zenedge.

·         Pilots starting early-mid May.

·         Will be a Bof at Global Summit.

 

6. How to deal with the lack of a full routing table on TR-CPS (was: lack of transit on TR-CPS)

·         Issue Occurrence

o    only an issue with connectors/members that receive only a default route from their transit provided and more specifics from I2/TR-CPS

o    some times traffic gets blackholed  by TR-CPS or its peer

o    other times the peer will use their transit to deliver the traffic

·         Possible solutions:

o    members/connectors get full table from their provider.

§  Concern with requiring members/connectors having hardware needed for full table.

o    TR-CPS gets full routes from a transit provider. Don't advertise table to customers or advertise customer routes to provider.

§   Internet2 is in talks with Level(3) on increasing capacity to 10GE ports at Los Angeles/Chicago/Washington.

o    KanREN willing to provide full routes to TR-CPS as long as use is of limited occurrence and issues addressed with the I2 member. Possible issue is KanREN provider having filters in place which might drop the traffic from prefixes other than KanREN's. Brad to check with his Executive on that possibility and verify with KanREN's upstreams that prefixes are not being filtered.

§  Brad to hear back from Charter on ACL removal. All other KanREN transit providers will have no issue.

§  Could be setup quickly and used to get data for how common the issue is.

§  If KanREN is unable to provide, Dave Farmer can ask Big 10 Academic Alliance.

·         Concern with making sure the DDoS scrubbing service is taken into consideration.

o    Steve Wallace to write up a proposal.

7. AOB

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature