[j-nsp] RTBH

[Hugo Slabbert]

On Fri 2016-Jan-15 18:58:08 +0100, Raphael Mazelier <raph at 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

hugo at slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20160115/259388a1/attachment.sig>