Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Redistributing BGP Routes with a Specific Community Tag into IS-IS

Understanding BGP Communities and Extended Communities as Routing Policy Match Conditions

A BGP community is a group of destinations that share a common property. Community information is included as a path attribute in BGP update messages. This information identifies community members and enables you to perform actions on a group without having to elaborate upon each member. You can create a named community and include it in a routing policy with the community match condition, which is described in Configuring Match Conditions in Routing Policy Terms. For a list of the actions that can be configured for communities, see Configuring Actions That Manipulate Route Characteristics.

You can configure the standard community attribute and the extended communities attribute for inclusion in BGP update messages. The standard community attribute is four octets whereas the extended communities attribute is eight octets, providing a larger range for grouping or categorizing communities. You can use community and extended communities attributes to trigger routing decisions, such as acceptance, rejection, preference, or redistribution.

The BGP community attribute format is as-number:community-value. The BGP extended communities attribute format has three fields: type:administrator:assigned-number.

When specifying community IDs for the standard community attribute, you can use UNIX-style regular expressions. Regular expressions are also supported for the extended communities attribute. The only exception is for VPN import policies (vrf-import), which do not support regular expressions for the extended communities attribute.

Note: You can assign community tags to non-BGP routes through configuration (for static, aggregate, or generated routes) or an import routing policy. These tags can then be matched when BGP exports the routes.

To use a BGP community or extended community as a routing policy match condition, you define the community and its members and then include the community in a match condition.

• RFC 1997, BGP Communities Attribute

Example: Redistributing BGP Routes with a Specific Community Tag into IS-IS

This example defines a policy that takes BGP routes from the Edu community and places them into IS-IS with a metric of 63.

• Requirements
• Overview
• Configuration
• Verification

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

Figure 1 shows the topology used in this example.

Figure 1: Redistributing BGP Routes with a Specific Community Tag into IS-IS

In this example, Device A, Device B, Device C, and Device D are in autonomous system (AS) 1 and are running IS-IS. All of the AS 1 devices, except Device D, are running internal BGP (IBGP).

Device E is in AS 2 and has an external BGP (EBGP) peering session with Device C. Device E has two static routes, 10.2.0.0/16 and 10.3.0.0/16. These routes are tagged with the Edu 2:5 community attribute and are advertised by way of EBGP to Device C.

Device C accepts the BGP routes that are tagged with the Edu 2:5 community attribute, redistributes the routes into IS-IS, and applies an IS-IS metric of 63 to these routes.

CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section Step-by-Step Procedure describes the steps on Device C and Device E.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

1. Configure the interfaces.
   [edit interfaces]user@E# set fe-1/2/0 unit 0 family inet address 10.0.0.26/30user@E# set lo0 unit 7 family inet address 192.168.0.5/32 primaryuser@E# set lo0 unit 7 family inet address 10.2.0.1/32user@E# set lo0 unit 7 family inet address 10.3.0.1/32
2. Configure the statics policy, which adds the Edu community attribute to the static routes.
   [edit policy-options]user@E# set policy-statement statics from protocol staticuser@E# set policy-statement statics then community add Eduuser@E# set policy-statement statics then acceptuser@E# set community Edu members 2:5
3. Configure EBGP and apply the statics policy.
   [edit protocols bgp group external-peers]user@E# set type externaluser@E# set export staticsuser@E# set peer-as 1user@E# set protocols bgp group external-peers neighbor 10.0.0.25
4. Configure the static routes.
   [edit routing-options static]user@E# set route 10.2.0.0/16 rejectuser@E# set route 10.2.0.0/16 installuser@E# set route 10.3.0.0/16 rejectuser@E# set route 10.3.0.0/16 install
5. Configure the router ID and the AS number.
   [edit routing-options]user@E# set router-id 192.168.0.5user@E# set autonomous-system 2

Step-by-Step Procedure

1. Configure the interfaces.
   [edit interfaces]user@C# set fe-1/2/0 unit 0 family inet address 10.0.0.10/30user@C# set fe-1/2/0 unit 0 family isouser@C# set fe-1/2/1 unit 0 family inet address 10.0.0.13/30user@C# set fe-1/2/1 unit 0 family isouser@C# set fe-1/2/2 unit 0 family inet address 10.0.0.25/30user@C# set fe-1/2/2 unit 0 family isouser@C# set lo0 unit 0 family inet address 192.168.0.3/32user@C# set lo0 unit 0 family iso address 49.0002.0192.0168.0003.00
2. Configure IBGP.
   [edit protocols bgp group int]user@C# set type internaluser@C# set local-address 192.168.0.3user@C# set neighbor 192.168.0.1user@C# set neighbor 192.168.0.2
3. Configure the Edu-to-isis policy, which redistributes the Edu-tagged BGP routes learned from Device E and applies a metric of 63.
   [edit policy-options]user@C# set policy-statement Edu-to-isis term 1 from protocol bgpuser@C# set policy-statement Edu-to-isis term 1 from community Eduuser@C# set policy-statement Edu-to-isis term 1 then metric 63user@C# set policy-statement Edu-to-isis term 1 then acceptuser@C# set community Edu members 2:5
4. Enable IS-IS on the interfaces, and apply the Edu-to-isis policy.
   [edit protocols isis]user@C# set export Edu-to-isisuser@C# set interface fe-1/2/0.0 level 1 disableuser@C# set interface fe-1/2/1.0 level 1 disableuser@C# set interface fe-1/2/2.0 level 1 disableuser@C# set interface fe-1/2/2.0 level 2 passiveuser@C# set interface lo0.0
5. Configure the send-isis-and-direct policy, which redistributes routes to Device E, through EBGP.

   Without this policy, Device E would not have connectivity to the networks in AS 1.

   [edit policy-options policy-statement send-isis-and-direct term 1]user@C# set from protocol isisuser@C# set from protocol directuser@C# set from route-filter 10.0.0.0/16 orlongeruser@C# set from route-filter 192.168.0.0/16 orlongeruser@C# set then accept
6. Configure EBGP and apply the send-isis-and-direct policy.
   [edit protocols bgp group external-peers]user@C# set type externaluser@C# set export send-isis-and-directuser@C# set peer-as 2user@C# set neighbor 10.0.0.26
7. Configure the router ID and the autonomous system (AS) number.
   [edit routing-options]user@C# set router-id 192.168.0.3user@C# set autonomous-system 1

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the IS-IS Neighbor

Purpose

Verify that the BGP routes from Device E are communicated on the IS-IS network in AS 1.

Action

From operational mode, enter the show route protocol isis command.

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.4/30        *[IS-IS/18] 22:30:53, metric 30
                    > to 10.0.0.13 via fe-1/2/0.0
10.0.0.8/30        *[IS-IS/18] 22:30:53, metric 20
                    > to 10.0.0.13 via fe-1/2/0.0
10.0.0.24/30       *[IS-IS/18] 03:31:21, metric 20
                    > to 10.0.0.13 via fe-1/2/0.0
10.2.0.0/16        *[IS-IS/165] 02:36:31, metric 73
                    > to 10.0.0.13 via fe-1/2/0.0
10.3.0.0/16        *[IS-IS/165] 02:36:31, metric 73
                    > to 10.0.0.13 via fe-1/2/0.0
192.168.0.1/32     *[IS-IS/18] 03:40:28, metric 30
                    > to 10.0.0.13 via fe-1/2/0.0
192.168.0.2/32     *[IS-IS/18] 22:30:53, metric 20
                    > to 10.0.0.13 via fe-1/2/0.0
192.168.0.3/32     *[IS-IS/18] 22:30:53, metric 10
                    > to 10.0.0.13 via fe-1/2/0.0

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

Meaning

As expected, the 10.2.0.0/16 and 10.3.0.0/16 routes are in Device D’s routing table as IS-IS external routes with a metric of 73. If Device C had not added 63 to the metric, Device D would have a metric of 10 for these routes.