Re: Issues with 4-octet BGP AS and Akamai?

[Jared Mauch <jared () puck nether net>]

It should be noted that AS_TRANS aka 23456 shouldn’t be visible on the global internet and many people may filter that 
on AS4_PATH cable devices.

The fact that you’re seeing an AS_TRANS path from the Telia LG is likely an indication that route may be not fully 
internet visible.

It’s fairly suspicious that someone in 2017 is still having that issue.

There’s a chance that is being filtered if someone is putting AS_TRANS in the AS4_PATH, but it does appear the route is 
fully visible:

https://stat.ripe.net/widget/routing-history#w.resource=216.165.0.0/17&w.normalise_visibility=true

Note that the routes in red have low visibility, which includes some of the CIDR blocks you specified.

https://stat.ripe.net/216.165.124.0%2F23#tabId=routing

- Jared



> On Nov 14, 2017, at 12:36 PM, Greg Gombas -X (grgombas) <grgombas () cisco com> wrote:
>
> Thank you all for your assistance thus far. I wanted to confirm with my customer that it was okay to share more 
> details and they said it was okay. We did just send an email to Akamai net support and awaiting their reply.
>
> The customer is NYULH (AS 394666). They currently use NYU (AS 12) for internet connectivity. They advertise the 
> following prefixes to NYU:
>
> 216.165.124.0/24
> 216.165.125.0/24
> 216.165.126.0/24
> 216.165.127.0/24
>
> NYU aggregates the above prefixes, strips NYULH's AS number, and replaces it with their own AS number (AS 12).
> The aggregates are as follows:
>
> 216.165.124.0/23
> 216.165.126.0/23
>
> Below is a sample /23 route seen from one of the looking glass servers with origin AS 12:
>
> 216.165.124.0/23  
> [DIGITALOCEAN3 2017-11-11 from 162.243.188.2] * (100/-) [AS12i]
>       Type: BGP unicast univ
>       BGP.origin: IGP
>       BGP.as_path: 393406 3630 12
>       BGP.next_hop: 162.243.188.2
>       BGP.local_pref: 100
>       BGP.atomic_aggr: 
>       BGP.aggregator: 192.168.255.3 AS12
>       BGP.community: (14061,2000) (14061,2002) (14061,3000) (14061,3001) (65363,714) (65363,2906) (65363,13335) 
> (65363,13414) (65363,14061) (65363,20940) (65363,32934) (65363,41690) (65363,46489) (65363,65340)
>       BGP.ext_community: (RPKI Origin Validation State: not-found)
>
> With their routes originating from AS 12, all their internet connectivity works fine.
>
> However when they failover to their secondary path which is F5 Silverline DDOS protection over Optimimum Lightpath, 
> they are unable to connect to any Akamai hosted websites.
> The difference between their primary path and secondary path is that the secondary path does not strip their origin 
> AS 394666.
>
> To answer Job's question, yes the originating router is AS4 capable. I checked the looking glass link you provided 
> and see the correct origin AS 394666. See below:
>
> 216.165.124.0/24  
> [DIGITALOCEAN5 14:14:44 from 5.101.111.2] * (100/-) [AS394666i]
>       Type: BGP unicast univ
>       BGP.origin: IGP
>       BGP.as_path: 202109 2914 55002 394666
>       BGP.next_hop: 5.101.111.2
>       BGP.local_pref: 100
>       BGP.community: (2914,410) (2914,1203) (2914,2201) (2914,3200) (14061,2100) (14061,2101) (14061,4000) 
> (14061,4001)
>       BGP.ext_community: (RPKI Origin Validation State: not-found)
>
> However we noticed some of Level 3's looking glass routers only see the AS_Trans 23456 as shown in the output below. 
> I'm assuming that means some of Level3's routers are not AS4 capable, but does that mean they will drop the routes?
>
> Report generated from: car1.jan1
>
> Route results for 216.165.124.0/24 from Jackson, MS
>
> BGP routing table entry for 216.165.124.0/24
> Paths: (2 available, best #2)
>  1299 55002 23456
>  AS-path translation: { TELIANET DEFENSENET-1 AS23456 }
>    ear3.Dallas1 (metric 43807)
>      Origin IGP, metric 100000, localpref 86, valid, internal
>      Community: North_America Lclprf_86 United_States Level3_Peer Dallas Level3:10497
>      Originator: ear3.Dallas1
>  1299 55002 23456
>  AS-path translation: { TELIANET DEFENSENET-1 AS23456 }
>    ear3.Dallas1 (metric 43807)
>      Origin IGP, metric 100000, localpref 86, valid, internal, best
>      Community: North_America Lclprf_86 United_States Level3_Peer Dallas Level3:10497
>      Originator: ear3.Dallas1
>
> Thanks,
> Greg
>
> Gregory Gombas
> CCIE# 19649 - R&S
> Network Consulting Engineer
> Advanced Services
> grgombas () cisco com
> Office: +1-212-714-4497
> Mobile: +1-201-675-9457
> Cisco Systems Limited
> One Penn Plaza
> 6th & 9th Floors
> New York, NY 10119
> United States
> Cisco.com
>
>
>
>
>
> Think before you print.
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, 
> use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this 
> message.
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
> -----Original Message-----
> From: Job Snijders [mailto:job () ntt net] 
> Sent: Tuesday, November 14, 2017 11:36 AM
> To: Greg Gombas -X (grgombas) <grgombas () cisco com>
> Cc: nanog () nanog org
> Subject: Re: Issues with 4-octet BGP AS and Akamai?
>
> Hi,
>
> What prefix and ASN is this about?
>
> Are you sure you are advertising from an AS4 capable router?
>
> Do you see the expected 4-byte ASN as origin in a aggregator looking glass like 
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=www.nlnog.net ?
>
> Kind regards,
>
> Job