BGP Hijack/Sickness with AS4637


I am the contact for AS16532.

We never announced nor are we currently advertising this prefix as we are not a transit AS for anyone. As well, it seems to appear and disappear from AS63956 looking glass. According to that LG, the route changed 6d ago, and is *still currently visible* at this very moment;

Command: show route protocol bgp table vrf-international.inet.0 active-path

vrf-international.inet.0: 696764 destinations, 2288960 routes (696480 active, 0 holddown, 103994 hidden)
+ = Active Route, - = Last Active, * = Both *[BGP/170] 6d 01:06:11, localpref 90, from
                      AS path: 4637 3257 29909 16532 16532 16532 16532 I, validation-state: unverified

AS16532 is not announcing this prefix. We have a strict prefix-list that is applied to all sessions. As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb. And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA.

There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path?

I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would change anything, as I am not seeing this prefix in their route-server> show route protocol bgp active-path

inet.0: 691667 destinations, 11752983 routes (691665 active, 1 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from
                      AS path: 3257 174 3 I, validation-state: unverified
                    > to via xe-1/0/0.0


{master}> show route protocol bgp | find 16532

Pattern not found

So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find.

Chris Conn