BGP
100
is picked. The matching action causes each of the settings that are present to replace what is currently picked.
E.g. if a MED is set in the top level and a named rule set the named rules set replaces the top level setting.
Important note - adding or removing community tags does not compound. For each setting (e.g. tag, untag,
med and localpref and any added in future) the latest that was found after checking top level peer settings, the
ordered list of filters, and then the local filters, is what applies. Multiple tag do not cause all the tags to be
added, just the latest listed tags in the action. There are plans to improve this in the future to work step by step
and even allow MED and localpref adjustments to compund.
You can have a rule with no action attributes. If matched then this means none of the actions are taken and
communities, localpref, med, etc., are all unchanged.
15.2.6. Well known community tags
Specific well known communities are supported natively. Some of these are set automatically based on peer
type and can be explicitly removed using the detag action. These rules are automatically checked for exporting
routes unless overridden on the peer attributes.
Table 15.2. Communities
Community
Name
Meaning
FFFFFF01
no-export
The route is not announced on any EBGP session (other than confederation or
where allow-export is set).
FFFFFF02
no-advertise
The route is not considered part of BGP. Whilst it is applied and used for
routing internally it is not announced at all or considered to have been received
for the purposes of BGP.
FFFFFF03
local-as
The route is only advertised on IBGP (same AS) sessions.
FFFFFF04
no-peer
This tag is passed on to peers but does not have any special meaning internally
15.2.7. Announcing black hole routes
The FireBrick allows black hole routes to be defined using the the blackhole object. Routing for such addresses
is simply dropped with no ICMP error. Such routes can be marked for BGP announcement just like any other
routes.
In order to ensure that your internal BGP network sees such routes as a black hole, and not simply as a route
to the router than has the black hole defined (where the packets will be dropped), you can ensure all black hole
routes are announced using a suitable community tag. In many cases an EBGP peer will even allow you to
announce black hole routes to them with a suitable community tag.
The top level bgp object includes a blackhole-community attribute which can be set to a tag that is used to
mark routes as a black hole within your network. Any route received on a BGP peer within that config object
which includes the specified community is treated as a black hole route. It is installed in the BGP routes and
propagated as normal but it is internally set as forwarding to nowhere and packets dropped as a black hole.
Each peer object also has a blackhole-community tag. If set then this is added to any black hole routes
announced. If not set, then black hole routes are not sent on EBGP links. On IBGP links, if not set, the blackhole-
community from the parent bgp is added if present. Black hole routes are always announced on IBGP (subject
to normal rules for announcement).
To use this, define a suitable blackhole-community for your network, such as YourAS:666 and set in all bgp
objects. For all EBGP peers, set the peer object blackhole-community attribute with the tag they expect for
black hole routes.
It is unlikely you would want to announce a black hole route to an EBGP peer without an agreed tag as you
will be drawing traffic from them only to be discarded. If you want to do this, you have to specify a blackhole-
community to add, but this could simply be your own community tag for black holes.
Содержание FB6402
Страница 1: ...FireBrick FB6402 User Manual FB6000 Versatile Network Appliance...
Страница 2: ......
