Not too sure about your topology, but I¡¯ve had something similar bite me, so we typically put a prefix list inbound to deny receiving our internal prefixes from our peers. This probably doesn¡¯t work as well if your network is less ¡°eyeballish¡± than ours, however. 

/chris



On Wed, Mar 27, 2019 at 4:37 PM -0500, "Graham Johnston" <johnstong@westmancom.com> wrote:

This afternoon at around 12:17 central time today we began learning the subnet for the Equinix IX in Chicago via a transit provider; we are on the IX as well. The subnet in question is 208.115.136.0/23. Using stat.ripe.net I can see that this subnet is also being learned by others, see the snip below. On our network this caused a nasty routing loop until we figured out what was wrong. My current best understanding is that because the route was learned via eBGP it trumped the OSPF learned route. As soon as I filtered the advertisement from my transit provider everything returned to normal. What am I doing that isn¡¯t best practices that would have prevented this?

 

Thanks,

graham

 

 

RIPE Info

1 RRCs see 1 peers announcing 208.115.136.0/23 originated by AS32703

¡€         ¡åRRC00 in Amsterdam, Netherlands sees 1 ASN orginating 208.115.136.0/23.AS32703

o    ¡åAS32703 is seen as the origin by 1 peer.192.102.254.1

¡×  ¡å192.102.254.1 is announcing route AS395152 AS63297 AS6327 AS36280AS32703.

¡×  Origin: IGP
¡×  Next Hop: 192.102.254.1
¡×  Peer: 192.102.254.1
¡×  Community: 63297:1000
¡×  AS Path: 395152 63297 6327 36280 32703
¡×  Last Updated: 2019-03-27T17:17:19

 

 

Route-views

route-views.chicago.routeviews.org> show ip bgp 208.115.136.0

BGP routing table entry for 208.115.136.0/23

Paths: (1 available, best #1, table Default-IP-Routing-Table)

  Not advertised to any peer

  32709 32703

    208.115.136.134 from 208.115.136.134 (63.134.128.248)

      Origin IGP, localpref 100, valid, external, best

      AddPath ID: RX 0, TX 64414249

      Last update: Wed Mar 27 17:16:09 2019