On Fri 2016-Jan-15 18:58:08 +0100, Raphael Mazelier <r...@futomaki.net> wrote:
Le 15/01/16 17:40, Hugo Slabbert a écrit :Sounds like the router that receives the initial RTBH /32 is re-advertising that to your other peers, i.e.: - RTBH box announces /32 with a.b.c.d/32 next-hop discard via BGP - RTBH BGP peer #1 receives and installs the route - that discard route on RTBH BGP peer #2 is picked up in its IGP export policy, so it exports it into your IGP - other RTBH BGP peers receive both the original BGP route from the RTBH box as well as the route RTBH BGP peer #1 injected into your IGP - IGP preference beats BGP, therefore remaining RTBH BGP peers prefer the IGP route that peer #1 injected Check your IGP export policy; you shouldn't be exporting the RTBH route into your IGP.I can missing the point, but this seems ok to redistribute rtbh route in your IBGP, because you don't want to make session to your rtbh feeder on all your routers ?
Sure, but I didn't say that it's a problem to distribute/reflect the RTBH route via iBGP; I was specifically talking about injecting the RTBH route into your IGP (OSPF, IS-IS, etc.), which could lead to the types of issues reported by Johan originally.
Johan's topology had 8 BGP speakers, each with an iBGP session to the RTBH originating router. These 8 routers were *already* receiving the RTBH route directly from the RTBH router itself on their discrete iBGP sessions, and should have received it with a next-hop of 'a.b.c.d' in Johan's setup, which by convention is probably 192.0.2.1. So: job done as all of the iBGP peers to the RTBH already have a static discard next-hop for 192.0.2.1, which they resolve locally as the next-hop for the blackhole route received from the RTBH box.
The problem comes if one (or all) of those iBGP speakers peered with the RTBH box then take the BGP-learned RTBH route and, via a loose IGP (again, e.g. OSPF or IS-IS, *not* iBGP) export policy inject it into the *IGP*. Since IGP route preferences (or "administrative distance", depending on your platform) generally beat BGP or iBGP preference/distance unless you've fiddled with them, the router that advertises the RTBH route into the IGP will end up drawing all traffic for that prefix to itself; the exact symptoms Johan described.
And as generaly we configure IBGP session with next hop self, rtbh route are directed to the origin router.
Right; it's fine to reflect RTBH routes rather than setting up discrete iBGP sessions from each BGP speaker to your RTBH box, but for simplicity's sake skip the NHS on them.
That's why the Niall setup is required, make an execption (do not nhs rtbh route) and set a next hop that is localy resolved, to discard.
Right; exactly; all good. So, again:Reflecting/re-exporting RTBH routes via iBGP: no problem, provided you handle your communities correctly and have the local discard /32.
Injecting the RTBH-learned route into your IGP: through the magic of protocol preferences / admin distances, the IGP-learned route from that injecting router beats everyone else's iBGP-learned route, and that injecting router now effectively becomes a traffic sink rather than letting each iBGP speaker discard the RTBH'd traffic locally.
-- Raphael Mazelier
-- Hugo h...@slabnet.com: email, xmpp/jabber PGP fingerprint (B178313E): CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E (also on Signal)
signature.asc
Description: PGP signature
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
