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) <grgom...@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
> grgom...@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:j...@ntt.net] 
> Sent: Tuesday, November 14, 2017 11:36 AM
> To: Greg Gombas -X (grgombas) <grgom...@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

Reply via email to