Routing

Hello,

 

Currently I'm running a multihome BGP setup with a stacked EX4200 chassi.

The BGP sessions and such are working fine, but now I would like to be able to push BGP null routes / blackholing.

 

So I got in touch with the providers and while one is taking some time, the other has supplied me with session details towards an EBGP peer.

 

So according to the documentation, I assigned a separate IP to the lo0 interface:

lo0 {
unit 0 {
family inet {
address a.a.a.a/32;
}}}

 

Next I created a new BGP group:

protocols {
bgp {
local-as MyAS;

group Provider-Black {
type external;
multihop;
local-address a.a.a.a;
authentication-key ## SECRET-DATA
export export_null;
peer-as ProviderAS;
local-as MyAS;
neighbor b.b.b.b;
}}}}

 

I then went ahead and created the policy statemend and prefix list:

prefix-list export-null {
c.c.c.c/32;
}
policy-statement export_null {
term eBGP-NullAnnounce {
from {
prefix-list export-null;
}
then accept;
}
term default_allow {
then reject;
}
}

 

 

The problem is, that nothing is being exported this way, when I swap the accept and reject of the policy statement, all known routes are being advertised and nulled - so my match rule doesn't work I'd assume.

 

I tried changing the matching condition to the below but it made no difference:

policy-statement export_null {
term eBGP-NullAnnounce {
from {
route-filter d.d.d.d/32 exact;
}
then accept;
}
term default_allow {
then reject;
}
}

 

 

i would appreciate any help you could provide as I'm totally lost at this point seen to the export rules, and no this provider cannot provide any tags for some kind of community approach.

Hi Daniel,

 

You'd normally advertise routes to be black holed with a specific tag (our ISP friends can confirm this).

 

The following policy-statement will advertise only c.c.c.c/32 to the peer and reject all other routes. 

 

prefix-list export-null {
c.c.c.c/32;
}
policy-statement export_null {
term eBGP-NullAnnounce {
from {
prefix-list export-null;
}
then accept;
}
term default_allow {
then reject;
}
}

 

You're probably looking for something like the following:

 

policy-statement export_null {
term eBGP-NullAnnounce {
from {
prefix-list export-null;
}
then accept;
then tag 666;
}
term default_allow {
then accept;
}

 

This will advertise the bad routes with a specific tag of 666 that will get black holed inside the ISP core (or edge) while still advertising your normal routes.

 

Here's a good primer with a Juniper config sample near the end.

 

https://tools.ietf.org/html/rfc5635

 

HTH

 

That's almost correct. Tag, however, is only used for IGP routes. You need to configure communities and set the provider's blackhole community on the outbound route announcement. 

Hello there,

 

---

@DanielO wrote:

 

I then went ahead and created the policy statemend and prefix list:

prefix-list export-null {
c.c.c.c/32;
}
policy-statement export_null {
term eBGP-NullAnnounce {
from {
prefix-list export-null;
}
then accept;
}
term default_allow {
then reject;
}
}

 

 

The problem is, that nothing is being exported this way, 

---

Your c.c.c.c/32 route must be present on the Juniper device and be active meaning "that particular exact network/mask combo must not be hidden and be most preferred".

JUNOS does not announce routes absent on the device.

Depending on JUNOS version, You may also need to add "from protocol <name>" to term eBGP-NullAnnounce.

HTH

Thanks
Alex

dear alex,

do you have also add a static route for the blackhole?

e.g.

routing-options {
static {
route c.c.c.c/32 {
discard;
}
}
}

---

@tcz wrote:
dear alex,

do you have also add a static route for the blackhole?

e.g.

routing-options {
static {
route c.c.c.c/32 {
discard;
}
}
}

---

Essentially correct.

Static is just one way to have an active route for blackholed prefix on the device.

I suggest You study RFC 5635 Appenfix B with example JUNOS config for announcing router https://tools.ietf.org/html/rfc5635#appendix-B to get more understanding of all the steps involved.

HTH

Thanks

Alex

 

Thank you, I totally forgot about BGP requiring defined routes on the device in order to announce them further. After adding that, it does now work as intended.