Technical Documentation

Configuring BGP Groups and Peers

A BGP system must know which routing devices are its peers (neighbors). You define the peer relationships explicitly by configuring the neighboring routers that are the peers of the local BGP system. After peer relationships have been established, the BGP peers exchange update messages to advertise network reachability information.

You arrange BGP routing devices into groups of peers. Different peer groups must have different group types, AS numbers, or route reflector cluster identifiers.

Each group must contain at least one peer.

To configure BGP groups and peers, see the following sections:

Defining a Group with Static Peers

To define a BGP group that recognizes only the specified BGP systems as peers, statically configure all the system’s peers by including one or more neighbor statements. The peers on at least one side of each BGP connection must be configured statically. The peer neighbor’s address can be either an IPv6 or IPv4 address.

group group-name {peer-as autonomous-system;type type;neighbor address; # One "neighbor" statement for each peer}

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

As the number of EBGP groups increases, the ability to support a large number of BGP sessions may become a scaling issue. The preferred way to configure a large number of BGP neighbors is to configure a few groups consisting of multiple neighbors per group. Supporting fewer EBGP groups generally scales better than supporting a large number of EBGP groups. This becomes more evident in the case of hundreds of EBGP groups when compared with a few EBGP groups with multiple peers in each group. The following examples illustrate this point.

For sample configurations, see the following sections:

Example: Defining a Large Number of Groups with Static Peers

Enable BGP and define three EBGP groups that recognize BGP systems in AS 56, AS 57, and AS 58 as peers:

[edit]routing-options {autonomous-system 23;}protocols {bgp {group G1 {type external;peer-as 56;neighbor 10.0.0.1;}group G2 {type external;peer-as 57;neighbor 10.0.10.1;}group G3 {type external;peer-as 58;neighbor 10.0.20.1;}}}

Example: Defining a Small Number of Groups with Static Peers for Better Scalability

For improved scalability, configure only one EBGP group consisting of the three BGP neighbors:

[edit]routing-options {autonomous-system 23;}protocols {bgp {group G {type external;neighbor 10.0.0.1 {peer-as 56;}neighbor 10.0.10.1 {peer-as 57;}neighbor 10.0.20.1 {peer-as 58;}}}}

Defining a Group with Dynamic Peers

To define a BGP group in which the local system’s peers are dynamic and change over time, include the allow statement. To recognize all BGP systems as peers, include the allow-all statement. To recognize BGP systems within specified address ranges, specify a set of addresses in the allow network/mask-length statement. These addresses can be IPv6 or IPv4 addresses.

group group-name {peer-as autonomous-system;type type;allow ([ network/mask-length] | all);}

Note: You cannot define a BGP group with dynamic peers with authentication enabled.

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

Defining the Group Type

When configuring a BGP group, you can indicate whether the group is an IBGP group or an EBGP group. All peers in an IBGP group are in the same AS, while peers in an EBGP group are in different ASs and normally share a subnet.

To configure an IBGP group, which allows intra-AS BGP routing, include the following form of the type statement:

type internal;

To configure an EBGP group, which allows inter-AS BGP routing, include the following form of the type statement:

type external;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

Specifying the Peer’s AS Number

When configuring a peer, you must specify the peer system’s AS. To do this, include the peer-as statement:

peer-as autonomous-system;

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

For autonomous-system, you can specify a number of 1 through 4,294,967,295 in plain-number format. In Junos OS Release 9.1 and later, the range for autonomous system (AS) numbers is extended to provide BGP support for 4-byte AS numbers as defined in RFC 4893, BGP Support for Four-octet AS Number Space. The Junos OS continues to support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 in plain-number format (this is a subset of the 4-byte range).

In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: <16-bit high-order value in decimal>.<16-bit low-order value in decimal>. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value in the range from 0.0 through 65535.65535 in AS-dot notation format.

For EBGP, the peer is in another AS, so the AS number you specify in the peer-as statement must be different from the local router’s AS number, which you specify in the autonomous-system statement. For IBGP, the peer is in the same AS, so the two AS numbers that you specify in the autonomous-system and peer-as statements must be the same. For more information about configuring the AS number of the local router, see Configuring AS Numbers for BGP.

With the introduction of 4-byte AS numbers, you might have a combination of routers that support 4-byte AS numbers and 2-byte AS numbers. For more information about what happens when establishing BGP peer relationships between 4-byte and 2-byte capable routers, see the following topics:

Defining Group Properties

To define group-specific properties, include one or more of the following statements.

accept-remote-nexthop;advertise-external <conditional>;advertise-inactive;(advertise-peer-as | no-advertise-peer-as);allow [ network/mask-length ];as-override;authentication-algorithm algorithm;authentication-key key;authentication-key-chain key-chain;bfd-liveness-detection {authentication {algorithm algorithm-name;key-chain key-chain-name;loose-check;}detection-time {threshold milliseconds;}holddown-interval milliseconds;minimum-interval milliseconds;minimum-receive-interval milliseconds;no-adaptation;transmit-interval {threshold milliseconds;minimum-interval milliseconds;}multiplier number;no-adaptation;version (1 | automatic);}cluster cluster-identifier;damping;description text-description;disable;export [ policy-names ];family {(inet | inet6 | inet-vpn | inet6-vpn | iso-vpn) {(any | flow | labeled-unicast | multicast | unicast) {accepted-prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}<loops number>;prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}rib-group group-name;}flow {no-validate policy-name;}labeled-unicast {accepted-prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}aggregate-label {community community-name:}explicit-null {connected-only;}prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}resolve-vpn;rib inet.3;rib-group group-name;}}route-target {accepted-prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}advertise-default;external-paths number;prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}}(inet-mdt | inet-mvpn | inet6-mvpn | l2-vpn) {signaling {accepted-prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}<loops number>;prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}rib-group group-name}}}graceful-restart {disable;restart-time seconds;stale-routes-time seconds;}hold-time seconds;idle-after-switch-over (seconds | forever);import [ policy-names ];include-mp-next-hop;ipsec-sa ipsec-sa;keep (all | none);local-address address;local-as autonomous-system <private>;local-interface interface-name;local-preference local-preference;log-updown;metric-out (metric | minimum-igp <offset> | igp <offset>);mtu-discovery;multihop {no-nexthop-change;ttl value;}multipath {multiple-as;}neighbor address {... peer-specific-options ...}no-aggregator-id;no-client-reflect;out-delay seconds;outbound-route-filter{bgp-orf-cisco-mode;prefix-based {accept {(inet | inet6);}}}passive;peer-as autonomous-system;preference preference;remove-private;tcp-mss segment-size;traceoptions {file filename <files number> <size size> <world-readable | no-world-readable>;flag flag <flag-modifier> <disable>;}type type;vpn-apply-export;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

Defining Peer Properties

When you use the neighbor statement to configure BGP peers statically, you also can define peer-specific properties.

accept-remote-nexthop;advertise-external <conditional>;advertise-inactive;(advertise-peer-as | no-advertise-peer-as);as-override;authentication-algorithm algorithm;authentication-key key;authentication-key-chain key-chain;bfd-liveness-detection {authentication {algorithm algorithm-name;key-chain key-chain-name;loose-check;}detection-time {threshold milliseconds;}holddown-interval milliseconds;minimum-interval milliseconds;minimum-receive-interval milliseconds;no-adaptation;transmit-interval {threshold milliseconds;minimum-interval milliseconds;}multiplier number;no-adaptation;version (1 | automatic);}cluster cluster-identifier;damping;description text-description;export [ policy-names ];family {(inet | inet6 | inet-vpn | inet6-vpn | iso-vpn) {(any | flow | labeled-unicast | multicast | unicast) {accepted-prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}<loops number>;prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}rib-group group-name;}flow {no-validate policy-name;}labeled-unicast {accepted-prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}aggregate-label {community community-name:}explicit-null {connected-only;}prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}resolve-vpn;rib inet.3;rib-group group-name;}}route-target {accepted-prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}advertise-default;external-paths number;prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}}(inet-mdt | inet-mvpn | inet6-mvpn | l2-vpn) {signaling {accepted-prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}<loops number>;prefix-limit {maximum number;teardown <percentage> <idle-timeout (forever | minutes)>;}rib-group group-name}}}graceful-restart {disable;restart-time seconds;stale-routes-time seconds;}hold-time seconds;idle-after-switch-over (seconds | forever);import [ policy-names ];include-mp-next-hop;ipsec-sa ipsec-sa;keep (all | none);local-address address;local-as autonomous-system <private>;local-interface interface-name;local-preference preference;log-updown;metric-out (metric | minimum-igp <offset> | igp <offset>);mtu-discovery;multihop {no-nexthop-change;ttl value;}multipath {multiple-as;}no-aggregator-id;no-client-reflect;out-delay seconds;outbound-route-filter{bgp-orf-cisco-mode;prefix-based {accept {(inet | inet6);}}}passive;peer-as autonomous-system;preference preference;remove-private;tcp-mss segment-size;traceoptions {file filename <files number> <size size> <world-readable | no-world-readable>;flag flag <flag-modifier> <disable>;}vpn-apply-export;

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

Related Topics


Published: 2010-07-02

|
|