Adding a BGP Community to Routes

2017-11-03 09:05:07

Problem

You want to add a BGP community to routes so you can apply common routing policy to the routes.

Solution

BGP communities are a way to group routes so you can apply the same policy to them. To use them in a routing policy, first define the community members and an AS path string:

[edit policy-options] aviva@RouterF# set community customer members 65500:1234 aviva@RouterF# set as-path AS65505-path "65505.*"

Then include the community in the routing policy:

[edit policy-options policy-statement community-add ] aviva@RouterF# set term match-route from protocol bgp aviva@RouterF# set term match-route from as-path AS65505-path aviva@RouterF# set then community add customer aviva@RouterF# set then accept

To have the policy take effect, apply it with an import statement to an EBGP group:

[edit protocols bgp] aviva@RouterF# set group session-to-AS65505 import community-add

Discussion

BGP communities are a way to group routes so that the same routing policy can be applied to them. This recipe shows a simple application of BGP communities that adds the community 65500:1234 to all received BGP routes that have the AS number 65505 in their AS path.

Creating the routing policy is a two-step process. First, define the members in your community with the set community statement. Each member has a community identifier, which looks like AS-number:community-value. The AS-number portion of the identifier is the local AS number. The community-value is a number from 1 through 65535 that you assign to identify the community. How you choose this number is a function of your internal administrative policies. Because the first part of the community identifier is your AS number, the identifier is unique across the network.

In the community identifier, you can use regular expressions to specify matches for the AS number and member identifier. The regular expressions have the same format as those for AS paths, consisting of a term and an operator, and they use the same operators as AS paths (see Table 13-1).

Because the routing policy in the recipe matches an AS number, we need the set as-path command to define which ASs to look for.

The second part of the process is creating a routing policy that references the community. The routing policy checks for BGP routes that have 65505 in their AS path and adds the community customer to any that match. Heres what the policy-options portion of the configuration looks like:

[edit policy-options] aviva@RouterF# show policy-statement community-add { term match-route { from { protocol bgp; as-path AS65505-path; } then { community add customer; accept; } } } community customer members 65500:1234; as-path AS65505-path "65505 .*";

As with all policies, to have it take affect, apply it to BGP. Here, we apply it with an import statement on routes being learned from the EBGP peer to AS 65505.

The detail option of the show route command lists the community attributes associated with a route:

aviva@RouterF> show route detail 192.168.18.1 inet.0: 18 destinations, 22 routes (18 active, 0 holddown, 0 hidden) 192.168.18.1/32 (1 entry, 1 announced) *BGP Preference: 170/-101 Next-hop reference count: 18 Source: 10.0.31.1 Next hop: 10.0.31.1 via t1-0/0/3.0, selected State: <Active Ext> Local AS: 65500 Peer AS: 65505 Age: 2d 18:35:30 Metric: 65 Task: BGP_65505.10.0.31.1+2079 Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve tree 1 AS path: 65505 I Communities: 65500:1234 Localpref: 100 Router ID: 192.168.14.1

You see that the route to 192.168.18.1, which is in AS 65505, has been marked with the configured community 65500:1234.

The rest of this section provides a more detailed example of using BGP communities and shows a configuration that updates the bogon prefixes on your router automatically whenever they change. Bogons are prefixes that should never appear in the Internet routing table. (The term bogon refers to something that is bogus.) There are two types of bogons: martian prefixes, which are private ( RFC 1918) and reserved addresses (multicast and loopback), and unallocated prefixes, which are address spaces that have not yet been assigned to a routing information registry ( RIR) by IANA. Although you can use bogon addresses in a private network, they should never leak out to the public Internet.

A good security policy on edge routers that face the Internet is to filter bogons. If you are using private address space inside your private network, you don want these addresses to leak out to the public Internet because traffic to or from these prefixes should not be seen on the public Internet. Also, if your network receives bogons from the Internet, you want to ignore them. Some common occurrences of bogons on the Internet include spoofed attacks, prefix hijacking, and simple configuration mistakes.

One way to filter bogons is to create a route prefix list that lists all the bogons and then reference this list in a routing policy. However, because the list of bogon addresses changes as unallocated space is allocated and as definitions of martian routes change, you would manually need to change the prefix lists. To avoid this administrative overhead, you can set up the configuration to automatically update the bogon list from the Team Cymru bogon route server project, which maintains a current list of bogons (see http://www.cymru.com/BGP/bogon-rs.html). This configuration, which is based on a suggested Team Cymru configuration, sets up an EBGP session with Team Cymru to automatically update the bogon list when it changes. This configuration also ties together many of the individual BGP configuration commands discussed in this chapter.

This configuration creates the community 65333:888 that is used to filter all bogons:

[edit policy-options] aviva@RouterF# set community cymru-bogon-community members [ no-export 65333:888 ]

This community includes the no-export member to attach the BGP NO_EXPORT attribute to the community to ensure that the router does not advertise the route beyond the local AS. The JUNOS software also allows you to attach the BGP NO_ADVERTISE and NO_EXPORT_SUBCONFED attributes to a community, with the no-advertise and no-export-subconfed options.

The routing policy also uses a second community:

[edit policy-options] aviva@RouterF# set community dont-announce members 65500:1234

This configuration assumes that you use community 65500:1234 as a standard way to suppress announcements of these routes outside your AS. The community is included as a precaution to provide a backup method to make sure that the routes stay within your AS in case, for some reason, the NO_EXPORT action fails.

Then define a simple regular expression to match the Team Cymru private AS number:

[edit policy-options] aviva@RouterF# set as-path cymru-private-asn 65333

The following routing policy for the EBGP peering session accepts the bogon route updates:

[edit policy-options] aviva@RouterF# edit policy-statement cymru-bogon-list [edit policy-options policy-statement cymru-bogon-list ] aviva@RouterF# set term 1 from protocol bgp aviva@RouterF# set term 1 from as-path cymru-private-asn aviva@RouterF# set term 1 from community cymru-bogon-community aviva@RouterF# set term 1 then community add dont-announce aviva@RouterF# set term 1 then next-hop 192.0.2.1 aviva@RouterF# set term 1 then accept aviva@RouterF# set then reject

The from clause matches BGP routes from the AS path defined in cymru-private-asn (that is, from AS number 65333) and that contain the community string defined in cymru-bogon-community (that is, 65333:888). The then clause performs two actions on any matching routes before accepting them. The set then community add dont-announce command attaches the community string 65500:1234 to the routes to ensure that the routes are never forwarded outside the local AS. (This is the community you defined with the set community dont-announce command.) The second action in the then clause sets the routes next hop to 192.0.1.2, which is a reserved network prefix. This next hop maps the bogons to a remotely triggered black hole, which acts as a filter for the bogons, discarding them and explicitly stating that they are never to be readvertised. You define this prefix as a static route in the routing table:

[edit routing-options] aviva@RouterF# set static route 192.0.2.1/32 discard aviva@RouterF# set static route 192.0.2.1/32 no-readvertise aviva@RouterF# set static route 192.0.2.1/32 retain

The discard option on the static route prevents it from being forwarded, no-readvertise prevents it from being readvertised to anyone else, and retain keeps the route in the forwarding table if the JUNOS routing process restarts normally.

If you are using the default JUNOS martians, 192.0.2.1/32 is a martian and will be rejected, so you need to explicitly allow the routing table to accept it:

[edit routing-options] aviva@RouterF# set martians 192.0.2.1/32 exact allow

When setting up policies, also create a second one for the EBGP peering session to make sure your network doesn forward any routing information back to Team Cymru:

[edit policy-options] aviva@RouterF# set policy-statement deny-all then reject

Now you have all the pieces in place to configure the EBGP peering session with Team Cymru so you can receive the automatic bogon updates. As with establishing a peering session with any remote AS, you need to contact the AS administrator to set up the peering terms and to provide your AS number, the IP address of the routers interface that will be used for peering, and your MD5 password. With this information you can configure the EBGP peer. The basic configuration establishes the external peering, sets a description for the peer, defines the peers AS number and the remote IP address used for the peering session, and sets a mutually agreed upon MD5 key:

[edit protocols bgp group cymru-peering ] aviva@RouterF# set type external aviva@RouterF# set description "bogon update peering with team cymru" aviva@RouterF# set peer-as 65333 aviva@RouterF# set neighbor 10.0.31.1 aviva@RouterF# set authentication-key "$9$D8imfQFnCp0zFreM87Nmf5T/C"

Apply the routing policies:

[edit protocols bgp group cymru-peering ] aviva@RouterF# set import cymru-bogon-list aviva@RouterF# set export deny-all

The import policy accepts the bogon list, and the export policy prevents the router from sending any routing updates to Team Cymru.

Because Team Cymru is more than one BGP hop away from your network, the EBGP peering needs to be a multihop session:

[edit protocols bgp group cymru-peering ] aviva@RouterF# set multihop ttl 255

The time to live (TTL) specifies how many hops your router is from the EBGP neighbor. For an EBGP session where the external neighbor is directly connected, the TTL is 1. For multihop sessions, the default TTL is 64. This configuration sets the TTL to the maximum allowable value of 255 to ensure that the peering succeeds. BGP places the TTL value in the packets IP header.

A final portion of the EBGP peer configuration restricts the number of routes Team Cymru can advertise to you, to guard against a misconfiguration or an inadvertent advertisement of the entire Internet routing table:

[edit protocols bgp group cymru-peering ] aviva@RouterF# set family inet unicast prefix-limit maximum 100 aviva@RouterF# set family inet unicast prefix-limit teardown 100

As of this writing, the bogon list contains 95 prefixes, so you use a prefix limit slightly higher than this.

This is a fairly involved configuration, so its worth summarizing it all in one place:

[edit] aviva@RouterF# show routing-options { static { route 192.0.2.1/32 { discard; retain; no-readvertise; } martians { 192.0.2.1/32 exact allow; } router-id 192.168.16.1; autonomous-system 65500; } protocols { bgp { group cymru-peering { type external; description "bogon update peering with team cymru"; multihop { ttl 255; } import cymru-bogon-list; family inet { unicast { prefix-limit { maximum 100; teardown 100; } } } authentication-key "$9$D8imfQFnCp0zFreM87Nmf5T/C"; ## SECRET-DATA export deny-all; peer-as 65333; neighbor 10.0.31.1; } } } policy-options { policy-statement cymru-bogon-list { term 1 { from { protocol bgp; as-path cymru-private-asn; community cymru-bogon-community; } then { community add dont-announce; next-hop 192.0.2.1; accept; } then reject; } policy-statement deny-all { then reject; } community cymru-bogon-community members [ no-export 65333:888 ]; community dont-announce members 65500:1234; as-path cymru-private-asn 65333; }

Adding a BGP Community to Routes

Problem

Solution

Discussion

See Also

Категории