Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Examples: Configuring Internal BGP Peering

    Understanding Internal BGP Peering Sessions

    When two BGP-enabled devices are in the same autonomous system (AS), the BGP session is called an internal BGP session, or IBGP session. BGP uses the same message types on IBGP and external BGP (EBGP) sessions, but the rules for when to send each message and how to interpret each message differ slightly. For this reason, some people refer to IBGP and EBGP as two separate protocols.

    Figure 1: Internal and External BGP

    Internal and External BGP

    In Figure 1, Device Jackson, Device Memphis, and Device Biloxi have IBGP peer sessions with each other. Likewise, Device Miami and Device Atlanta have IBGP peer sessions between each other.

    The purpose of IBGP is to provide a means by which EBGP route advertisements can be forwarded throughout the network. In theory, to accomplish this task you could redistribute all of your EBGP routes into an interior gateway protocol (IGP), such as OSPF or IS-IS. This, however, is not recommended in a production environment because of the large number of EBGP routes in the Internet and because of the way that IGPs operate. In short, with that many routes the IGP churns or crashes.

    Generally, the loopback interface (lo0) is used to establish connections between IBGP peers. The loopback interface is always up as long as the device is operating. If there is a route to the loopback address, the IBGP peering session stays up. If a physical interface address is used instead and that interface goes up and down, the IBGP peering session also goes up and down. Thus the loopback interface provides fault tolerance in case the physical interface or the link goes down, if the device has link redundancy.

    While IBGP neighbors do not need to be directly connected, they do need to be fully meshed. In this case, fully meshed means that each device is logically connected to every other device through neighbor peer relationships. The neighbor statement creates the mesh. Because of the full mesh requirement of IBGP, you must configure individual peering sessions between all IBGP devices in the AS. The full mesh need not be physical links. Rather, the configuration on each routing device must create a full mesh of peer sessions (using multiple neighbor statements).

    Note: The requirement for a full mesh is waived if you configure a confederation or route reflection.

    To understand the full-mesh requirement, consider that an IBGP-learned route cannot be readvertised to another IBGP peer. The reason for preventing the readvertisement of IBGP routes and requiring the full mesh is to avoid routing loops within an AS. The AS path attribute is the means by which BGP routing devices avoid loops. The path information is examined for the local AS number only when the route is received from an EBGP peer. Because the attribute is only modified across AS boundaries, this system works well. However, the fact that the attribute is only modified across AS boundaries presents an issue inside the AS. For example, suppose that routing devices A, B, and C are all in the same AS. Device A receives a route from an EBGP peer and sends the route to Device B, which installs it as the active route. The route is then sent to Device C, which installs it locally and sends it back to Device A. If Device A installs the route, a loop is formed within the AS. The routing devices are not able to detect the loop because the AS path attribute is not modified during these advertisements. Therefore, the BGP protocol designers decided that the only assurance of never forming a routing loop was to prevent an IBGP peer from advertising an IBGP-learned route within the AS. For route reachability, the IBGP peers are fully meshed.

    IBGP supports multihop connections, so IBGP neighbors can be located anywhere within the AS and often do not share a link. A recursive route lookup resolves the loopback peering address to an IP forwarding next hop. The lookup service is provided by static routes or an IGP such as OSPF, or BGP routes.

    Example: Configuring Internal BGP Peer Sessions

    This example shows how to configure internal BGP peer sessions.

    Requirements

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

    Overview

    In this example, you configure internal BGP (IBGP) peer sessions. The loopback interface (lo0) is used to establish connections between IBGP peers. The loopback interface is always up as long as the device is operating. If there is a route to the loopback address, the IBGP peer session stays up. If a physical interface address is used instead and that interface goes up and down, the IBGP peer session also goes up and down. Thus, if the device has link redundancy, the loopback interface provides fault tolerance in case the physical interface or one of the links goes down.

    When a device peers with a remote device’s loopback interface address, the local device expects BGP update messages to come from (be sourced by) the remote device’s loopback interface address. The local-address statement enables you to specify the source information in BGP update messages. If you omit the local-address statement, the expected source of BGP update messages is based on the device’s source address selection rules, which normally results in the egress interface address being the expected source of update messages. When this happens, the peer session is not established because a mismatch exists between the expected source address (the egress interface of the peer) and the actual source (the loopback interface of the peer). To make sure that the expected source address matches the actual source address, specify the loopback interface address in the local-address statement.

    Because IBGP supports multihop connections, IBGP neighbors can be located anywhere within the autonomous system (AS) and often do not share a link. A recursive route lookup resolves the loopback peer address to an IP forwarding next hop. In this example, this service is provided by OSPF. Although interior gateway protocol (IGP) neighbors do not need to be directly connected, they do need to be fully meshed. In this case, fully meshed means that each device is logically connected to every other device through neighbor peer relationships. The neighbor statement creates the mesh.

    Note: The requirement for a full mesh is waived if you configure a confederation or route reflection.

    After the BGP peers are established, local routes are not automatically advertised by the BGP peers. At each BGP-enabled device, policy configuration is required to export the local, static, or IGP-learned routes into the BGP routing information base (RIB) and then advertise them as BGP routes to the other peers. BGP's advertisement policy, by default, does not advertise any non-BGP routes (such as local routes) to peers.

    In the sample network, the devices in AS 17 are fully meshed in the group internal-peers. The devices have loopback addresses 192.168.6.5, 192.163.6.4, and 192.168.40.4.

    Figure 2 shows a typical network with internal peer sessions.

    Figure 2: Typical Network with IBGP Sessions

    Typical
Network with IBGP Sessions

    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.

    Device A

    set interfaces ge-0/1/0 unit 1 description to-Bset interfaces ge-0/1/0 unit 1 family inet address 10.10.10.1/30set interfaces lo0 unit 1 family inet address 192.168.6.5/32set protocols bgp group internal-peers type internalset protocols bgp group internal-peers description “connections to B and C”set protocols bgp group internal-peers local-address 192.168.6.5set protocols bgp group internal-peers export send-directset protocols bgp group internal-peers neighbor 192.163.6.4set protocols bgp group internal-peers neighbor 192.168.40.4set protocols ospf area 0.0.0.0 interface lo0.1 passiveset protocols ospf area 0.0.0.0 interface ge-0/1/0.1set policy-options policy-statement send-direct term 2 from protocol directset policy-options policy-statement send-direct term 2 then acceptset routing-options router-id 192.168.6.5set routing-options autonomous-system 17

    Device B

    set interfaces ge-0/1/0 unit 2 description to-Aset interfaces ge-0/1/0 unit 2 family inet address 10.10.10.2/30set interfaces ge-0/1/1 unit 5 description to-Cset interfaces ge-0/1/1 unit 5 family inet address 10.10.10.5/30set interfaces lo0 unit 2 family inet address 192.163.6.4/32set protocols bgp group internal-peers type internalset protocols bgp group internal-peers description “connections to A and C”set protocols bgp group internal-peers local-address 192.163.6.4set protocols bgp group internal-peers export send-directset protocols bgp group internal-peers neighbor 192.168.40.4set protocols bgp group internal-peers neighbor 192.168.6.5set protocols ospf area 0.0.0.0 interface lo0.2 passiveset protocols ospf area 0.0.0.0 interface ge-0/1/0.2set protocols ospf area 0.0.0.0 interface ge-0/1/1.5set policy-options policy-statement send-direct term 2 from protocol directset policy-options policy-statement send-direct term 2 then acceptset routing-options router-id 192.163.6.4set routing-options autonomous-system 17

    Device C

    set interfaces ge-0/1/0 unit 6 description to-Bset interfaces ge-0/1/0 unit 6 family inet address 10.10.10.6/30set interfaces lo0 unit 3 family inet address 192.168.40.4/32set protocols bgp group internal-peers type internalset protocols bgp group internal-peers description “connections to A and B”set protocols bgp group internal-peers local-address 192.168.40.4set protocols bgp group internal-peers export send-directset protocols bgp group internal-peers neighbor 192.163.6.4set protocols bgp group internal-peers neighbor 192.168.6.5set protocols ospf area 0.0.0.0 interface lo0.3 passiveset protocols ospf area 0.0.0.0 interface ge-0/1/0.6set policy-options policy-statement send-direct term 2 from protocol directset policy-options policy-statement send-direct term 2 then acceptset routing-options router-id 192.168.40.4set routing-options autonomous-system 17

    Configuring Device A

    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

    To configure internal BGP peer sessions on Device A:

    1. Configure the interfaces.
      [edit interfaces ge-0/1/0 unit 1]user@A# set description to-Buser@A# set family inet address 10.10.10.1/30
      [edit interfaces]user@A# set lo0 unit 1 family inet address 192.168.6.5/32
    2. Configure BGP.

      The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C.

      [edit protocols bgp group internal-peers]user@A# set type internaluser@A# set description “connections to B and C”user@A# set local-address 192.168.6.5user@A# set export send-directuser@A# set neighbor 192.163.6.4user@A# set neighbor 192.168.40.4
    3. Configure OSPF.
      [edit protocols ospf area 0.0.0.0]user@A# set interface lo0.1 passiveuser@A# set interface ge-0/1/0.1
    4. Configure a policy that accepts direct routes.

      Other useful options for this scenario might be to accept routes learned through OSPF or local routes.

      [edit policy-options policy-statement send-direct term 2]user@A# set from protocol directuser@A# set then accept
    5. Configure the router ID and the AS number.
      [edit routing-options]user@A# set router-id 192.168.6.5user@A# set autonomous-system 17

    Results

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

    user@A# show interfaces
    ge-0/1/0 {unit 1 {description to-B;family inet {address 10.10.10.1/30;}}}
    lo0 {unit 1 {family inet {address 192.168.6.5/32;}}}
    user@A# show policy-options
    policy-statement send-direct {term 2 {from protocol direct;then accept;}}
    user@A# show protocols
    bgp {group internal-peers {type internal;description “connections to B and C”;local-address 192.168.6.5;export send-direct;neighbor 192.163.6.4;neighbor 192.168.40.4;}}
    ospf {area 0.0.0.0 {interface lo0.1 {passive;}interface ge-0/1/0.1;}}
    user@A# show routing-optionsrouter-id 192.168.6.5;autonomous-system 17;

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

    Configuring Device B

    Step-by-Step Procedure

    The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

    To configure internal BGP peer sessions on Device B:

    1. Configure the interfaces.
      [edit interfaces ge-0/1/0 unit 2]user@B# set description to-Auser@B# set family inet address 10.10.10.2/30
      [edit interfaces ge-0/1/1]user@B# set unit 5 description to-Cuser@B# set unit 5 family inet address 10.10.10.5/30
      [edit interfaces]user@B# set lo0 unit 2 family inet address 192.163.6.4/32
    2. Configure BGP.

      The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C.

      [edit protocols bgp group internal-peers]user@B# set type internaluser@B# set description “connections to A and C”user@B# set local-address 192.163.6.4user@B# set export send-directuser@B# set neighbor 192.168.40.4user@B# set neighbor 192.168.6.5
    3. Configure OSPF.
      [edit protocols ospf area 0.0.0.0]user@B# set interface lo0.2 passiveuser@B# set interface ge-0/1/0.2user@B# set interface ge-0/1/1.5
    4. Configure a policy that accepts direct routes.

      Other useful options for this scenario might be to accept routes learned through OSPF or local routes.

      [edit policy-options policy-statement send-direct term 2]user@B# set from protocol directuser@B# set then accept
    5. Configure the router ID and the AS number.
      [edit routing-options]user@B# set router-id 192.163.6.4user@B# set autonomous-system 17

    Results

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

    user@B# show interfaces
    ge-0/1/0 {unit 2 {description to-A;family inet {address 10.10.10.2/30;}}}
    ge-0/1/1 {unit 5 {description to-C;family inet {address 10.10.10.5/30;}}}
    lo0 {unit 2 {family inet {address 192.163.6.4/32;}}}
    user@B# show policy-options
    policy-statement send-direct {term 2 {from protocol direct;then accept;}}
    user@B# show protocols
    bgp {group internal-peers {type internal;description “connections to A and C”;local-address 192.163.6.4;export send-direct;neighbor 192.168.40.4;neighbor 192.168.6.5;}}
    ospf {area 0.0.0.0 {interface lo0.2 {passive;}interface ge-0/1/0.2;interface ge-0/1/1.5;}}
    user@B# show routing-optionsrouter-id 192.163.6.4; autonomous-system 17;

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

    Configuring Device C

    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

    To configure internal BGP peer sessions on Device C:

    1. Configure the interfaces.
      [edit interfaces ge-0/1/0 unit 6]user@C# set description to-Buser@C# set family inet address 10.10.10.6/30
      [edit interfaces]user@C# set lo0 unit 3 family inet address 192.168.40.4/32
    2. Configure BGP.

      The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C.

      [edit protocols bgp group internal-peers]user@C# set type internaluser@C# set description “connections to A and B”user@C# set local-address 192.168.40.4user@C# set export send-directuser@C# set neighbor 192.163.6.4user@C# set neighbor 192.168.6.5
    3. Configure OSPF.
      [edit protocols ospf area 0.0.0.0]user@C# set interface lo0.3 passiveuser@C# set interface ge-0/1/0.6
    4. Configure a policy that accepts direct routes.

      Other useful options for this scenario might be to accept routes learned through OSPF or local routes.

      [edit policy-options policy-statement send-direct term 2]user@C# set from protocol directuser@C# set then accept
    5. Configure the router ID and the AS number.
      [edit routing-options]user@C# set router-id 192.168.40.4user@C# set autonomous-system 17

    Results

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

    user@C# show interfaces
    ge-0/1/0 {unit 6 {description to-B;family inet {address 10.10.10.6/30;}}}
    lo0 {unit 3 {family inet {address 192.168.40.4/32;}}}
    user@C# show policy-options
    policy-statement send-direct {term 2 {from protocol direct;then accept;}}
    user@C# show protocols
    bgp {group internal-peers {type internal;description “connections to A and B”;local-address 192.168.40.4;export send-direct;neighbor 192.163.6.4;neighbor 192.168.6.5;}}
    ospf {area 0.0.0.0 {interface lo0.3 {passive;}interface ge-0/1/0.6;}}
    user@C# show routing-optionsrouter-id 192.168.40.4;autonomous-system 17;

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

    Verification

    Confirm that the configuration is working properly.

    Verifying BGP Neighbors

    Purpose

    Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address.

    Action

    From operational mode, enter the show bgp neighbor command.

    user@A> show bgp neighbor
    Peer: 192.163.6.4+179 AS 17    Local: 192.168.6.5+58852 AS 17   
      Type: Internal    State: Established    Flags: Sync
      Last State: OpenConfirm   Last Event: RecvKeepAlive
      Last Error: None
      Export: [ send-direct ] 
      Options: Preference LocalAddress Refresh
      Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
      Number of flaps: 0
      Peer ID: 192.163.6.4     Local ID: 192.168.6.5       Active Holdtime: 90
      Keepalive Interval: 30         Peer index: 0   
      BFD: disabled, down
      NLRI for restart configured on peer: inet-unicast
      NLRI advertised by peer: inet-unicast
      NLRI for this session: inet-unicast
      Peer supports Refresh capability (2)
      Restart time configured on the peer: 120
      Stale routes from peer are kept for: 300
      Restart time requested by this peer: 120
      NLRI that peer supports restart for: inet-unicast
      NLRI that restart is negotiated for: inet-unicast
      NLRI of received end-of-rib markers: inet-unicast
      NLRI of all end-of-rib markers sent: inet-unicast
      Peer supports 4 byte AS extension (peer-as 17)
      Peer does not support Addpath
      Table inet.0 Bit: 10000
        RIB State: BGP restart is complete
        Send state: in sync
        Active prefixes:              0
        Received prefixes:            3
        Accepted prefixes:            3
        Suppressed due to damping:    0
        Advertised prefixes:          2
      Last traffic (seconds): Received 25   Sent 19   Checked 67  
      Input messages:  Total 2420   Updates 4       Refreshes 0     Octets 46055
      Output messages: Total 2411   Updates 2       Refreshes 0     Octets 45921
      Output Queue[0]: 0
    
    Peer: 192.168.40.4+179 AS 17   Local: 192.168.6.5+56466 AS 17   
      Type: Internal    State: Established    Flags: Sync
      Last State: OpenConfirm   Last Event: RecvKeepAlive
      Last Error: None
      Export: [ send-direct ] 
      Options: Preference LocalAddress Refresh
      Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
      Number of flaps: 0
      Peer ID: 192.168.40.4    Local ID: 192.168.6.5       Active Holdtime: 90
      Keepalive Interval: 30         Peer index: 1   
      BFD: disabled, down
      NLRI for restart configured on peer: inet-unicast
      NLRI advertised by peer: inet-unicast
      NLRI for this session: inet-unicast
      Peer supports Refresh capability (2)
      Restart time configured on the peer: 120
      Stale routes from peer are kept for: 300
      Restart time requested by this peer: 120
      NLRI that peer supports restart for: inet-unicast
      NLRI that restart is negotiated for: inet-unicast
      NLRI of received end-of-rib markers: inet-unicast
      NLRI of all end-of-rib markers sent: inet-unicast
      Peer supports 4 byte AS extension (peer-as 17)
      Peer does not support Addpath
      Table inet.0 Bit: 10000
        RIB State: BGP restart is complete
        Send state: in sync
        Active prefixes:              0
        Received prefixes:            2
        Accepted prefixes:            2
        Suppressed due to damping:    0
        Advertised prefixes:          2
      Last traffic (seconds): Received 7    Sent 21   Checked 24  
      Input messages:  Total 2412   Updates 2       Refreshes 0     Octets 45867
      Output messages: Total 2409   Updates 2       Refreshes 0     Octets 45883
      Output Queue[0]: 0

    Verifying BGP Groups

    Purpose

    Verify that the BGP groups are configured correctly.

    Action

    From operational mode, enter the show bgp group command.

    user@A> show bgp group
    Group Type: Internal    AS: 17                     Local AS: 17
      Name: internal-peers  Index: 0                   Flags: <Export Eval>
      Export: [ send-direct ] 
      Holdtime: 0
      Total peers: 2        Established: 2
      192.163.6.4+179
      192.168.40.4+179
      inet.0: 0/5/5/0
    
    Groups: 1  Peers: 2    External: 0    Internal: 2    Down peers: 0   Flaps: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0                 5          0          0          0          0          0

    Verifying BGP Summary Information

    Purpose

    Verify that the BGP configuration is correct.

    Action

    From operational mode, enter the show bgp summary command.

    user@A> show bgp summary
    Groups: 1 Peers: 2 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0                 5          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    192.163.6.4              17       2441       2432       0       0    18:18:52 0/3/3/0              0/0/0/0
    192.168.40.4             17       2432       2430       0       0    18:18:48 0/2/2/0              0/0/0/0

    Verifying That BGP Routes Are Installed in the Routing Table

    Purpose

    Verify that the export policy configuration is causing the BGP routes to be installed in the routing tables of the peers.

    Action

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

    user@A> show route protocol bgp
    inet.0: 7 destinations, 12 routes (7 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    10.10.10.0/30       [BGP/170] 07:09:57, localpref 100, from 192.163.6.4
                          AS path: I
                        > to 10.10.10.2 via ge-0/1/0.1
    10.10.10.4/30       [BGP/170] 07:09:57, localpref 100, from 192.163.6.4
                          AS path: I
                        > to 10.10.10.2 via ge-0/1/0.1
                        [BGP/170] 07:07:12, localpref 100, from 192.168.40.4
                          AS path: I
                        > to 10.10.10.2 via ge-0/1/0.1
    192.163.6.4/32      [BGP/170] 07:09:57, localpref 100, from 192.163.6.4
                          AS path: I
                        > to 10.10.10.2 via ge-0/1/0.1
    192.168.40.4/32     [BGP/170] 07:07:12, localpref 100, from 192.168.40.4
                          AS path: I
                        > to 10.10.10.2 via ge-0/1/0.1

    Example: Configuring Internal BGP Peering Sessions on Logical Systems

    This example shows how to configure internal BGP peer sessions on logical systems.

    Requirements

    In this example, no special configuration beyond device initialization is required.

    Overview

    In this example, you configure internal BGP (IBGP) peering sessions.

    In the sample network, the devices in AS 17 are fully meshed in the group internal-peers. The devices have loopback addresses 192.168.6.5, 192.163.6.4, and 192.168.40.4.

    Figure 3 shows a typical network with internal peer sessions.

    Figure 3: Typical Network with IBGP Sessions

    Typical
Network with IBGP Sessions

    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.

    set logical-systems A interfaces lt-0/1/0 unit 1 description to-Bset logical-systems A interfaces lt-0/1/0 unit 1 encapsulation ethernetset logical-systems A interfaces lt-0/1/0 unit 1 peer-unit 2set logical-systems A interfaces lt-0/1/0 unit 1 family inet address 10.10.10.1/30set logical-systems A interfaces lo0 unit 1 family inet address 192.168.6.5/32set logical-systems A protocols bgp group internal-peers type internalset logical-systems A protocols bgp group internal-peers local-address 192.168.6.5set logical-systems A protocols bgp group internal-peers export send-directset logical-systems A protocols bgp group internal-peers neighbor 192.163.6.4set logical-systems A protocols bgp group internal-peers neighbor 192.168.40.4set logical-systems A protocols ospf area 0.0.0.0 interface lo0.1 passiveset logical-systems A protocols ospf area 0.0.0.0 interface lt-0/1/0.1set logical-systems A policy-options policy-statement send-direct term 2 from protocol directset logical-systems A policy-options policy-statement send-direct term 2 then acceptset logical-systems A routing-options router-id 192.168.6.5set logical-systems A routing-options autonomous-system 17set logical-systems B interfaces lt-0/1/0 unit 2 description to-Aset logical-systems B interfaces lt-0/1/0 unit 2 encapsulation ethernetset logical-systems B interfaces lt-0/1/0 unit 2 peer-unit 1set logical-systems B interfaces lt-0/1/0 unit 2 family inet address 10.10.10.2/30set logical-systems B interfaces lt-0/1/0 unit 5 description to-Cset logical-systems B interfaces lt-0/1/0 unit 5 encapsulation ethernetset logical-systems B interfaces lt-0/1/0 unit 5 peer-unit 6set logical-systems B interfaces lt-0/1/0 unit 5 family inet address 10.10.10.5/30set logical-systems B interfaces lo0 unit 2 family inet address 192.163.6.4/32set logical-systems B protocols bgp group internal-peers type internalset logical-systems B protocols bgp group internal-peers local-address 192.163.6.4set logical-systems B protocols bgp group internal-peers export send-directset logical-systems B protocols bgp group internal-peers neighbor 192.168.40.4set logical-systems B protocols bgp group internal-peers neighbor 192.168.6.5set logical-systems B protocols ospf area 0.0.0.0 interface lo0.2 passiveset logical-systems B protocols ospf area 0.0.0.0 interface lt-0/1/0.2set logical-systems B protocols ospf area 0.0.0.0 interface lt-0/1/0.5set logical-systems B policy-options policy-statement send-direct term 2 from protocol directset logical-systems B policy-options policy-statement send-direct term 2 then acceptset logical-systems B routing-options router-id 192.163.6.4set logical-systems B routing-options autonomous-system 17set logical-systems C interfaces lt-0/1/0 unit 6 description to-Bset logical-systems C interfaces lt-0/1/0 unit 6 encapsulation ethernetset logical-systems C interfaces lt-0/1/0 unit 6 peer-unit 5set logical-systems C interfaces lt-0/1/0 unit 6 family inet address 10.10.10.6/30set logical-systems C interfaces lo0 unit 3 family inet address 192.168.40.4/32set logical-systems C protocols bgp group internal-peers type internalset logical-systems C protocols bgp group internal-peers local-address 192.168.40.4set logical-systems C protocols bgp group internal-peers export send-directset logical-systems C protocols bgp group internal-peers neighbor 192.163.6.4set logical-systems C protocols bgp group internal-peers neighbor 192.168.6.5set logical-systems C protocols ospf area 0.0.0.0 interface lo0.3 passiveset logical-systems C protocols ospf area 0.0.0.0 interface lt-0/1/0.6set logical-systems C policy-options policy-statement send-direct term 2 from protocol directset logical-systems C policy-options policy-statement send-direct term 2 then acceptset logical-systems C routing-options router-id 192.168.40.4set logical-systems C routing-options autonomous-system 17

    Device A

    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

    To configure internal BGP peer sessions on Device A:

    1. Configure the interfaces.
      [edit logical-systems A interfaces lt-0/1/0 unit 1]user@R1# set description to-Buser@R1# set encapsulation ethernetuser@R1# set peer-unit 2user@R1# set family inet address 10.10.10.1/30user@R1# set family inet address 192.168.6.5/32user@R1# upuser@R1# up[edit logical-systems A interfaces]user@R1# set lo0 unit 1 family inet address 192.168.6.5/32user@R1# exit[edit]user@R1# edit logical-systems B interfaces lt-0/1/0[edit logical-systems B interfaces lt-0/1/0]user@R1# set unit 2 description to-Auser@R1# set unit 2 encapsulation ethernetuser@R1# set unit 2 peer-unit 1user@R1# set unit 2 family inet address 10.10.10.2/30user@R1# set unit 5 description to-Cuser@R1# set unit 5 encapsulation ethernetuser@R1# set unit 5 peer-unit 6user@R1# set family inet address 10.10.10.5/30user@R1# up[edit logical-systems B interfaces]user@R1# set lo0 unit 2 family inet address 192.163.6.4/32user@R1# exit[edit]user@R1# edit logical-systems C interfaces lt-0/1/0 unit 6[edit logical-systems C interfaces lt-0/1/0 unit 6]set description to-Bset encapsulation ethernetset peer-unit 5set family inet address 10.10.10.6/30user@R1# upuser@R1# up[edit logical-systems C interfaces]set lo0 unit 3 family inet address 192.168.40.4/32
    2. Configure BGP.

      On Logical System A, the neighbor statements are included for both Device B and Device C, even though Logical System A is not directly connected to Device C.

      [edit logical-systems A protocols bgp group internal-peers]user@R1# set type internaluser@R1# set local-address 192.168.6.5user@R1# set export send-directuser@R1# set neighbor 192.163.6.4user@R1# set neighbor 192.168.40.4
      [edit logical-systems B protocols bgp group internal-peers]user@R1# set type internaluser@R1# set local-address 192.163.6.4user@R1# set export send-directuser@R1# set neighbor 192.168.40.4user@R1# set neighbor 192.168.6.5
      [edit logical-systems C protocols bgp group internal-peers]user@R1# set type internaluser@R1# set local-address 192.168.40.4user@R1# set export send-directuser@R1# set neighbor 192.163.6.4user@R1# set neighbor 192.168.6.5
    3. Configure OSPF.
      [edit logical-systems A protocols ospf area 0.0.0.0]user@R1# set interface lo0.1 passiveuser@R1# set interface lt-0/1/0.1
      [edit logical-systems A protocols ospf area 0.0.0.0]user@R1# set interface lo0.2 passiveuser@R1# set interface lt-0/1/0.2user@R1# set interface lt-0/1/0.5
      [edit logical-systems A protocols ospf area 0.0.0.0]user@R1# set interface lo0.3 passiveuser@R1# set interface lt-0/1/0.6
    4. Configure a policy that accepts direct routes.

      Other useful options for this scenario might be to accept routes learned through OSPF or local routes.

      [edit logical-systems A policy-options policy-statement send-direct term 2]user@R1# set from protocol directuser@R1# set then accept
      [edit logical-systems B policy-options policy-statement send-direct term 2]user@R1# set from protocol directuser@R1# set then accept
      [edit logical-systems C policy-options policy-statement send-direct term 2]user@R1# set from protocol directuser@R1# set then accept
    5. Configure the router ID and the autonomous system (AS) number.
      [edit logical-systems A routing-options]user@R1# set router-id 192.168.6.5user@R1# set autonomous-system 17
      [edit logical-systems B routing-options]user@R1# set router-id 192.163.6.4user@R1# set autonomous-system 17
      [edit logical-systems C routing-options]user@R1# set router-id 192.168.40.4user@R1# set autonomous-system 17

    Results

    From configuration mode, confirm your configuration by entering the show logical-systems command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

    user@R1# show logical-systems
    A {interfaces {lt-0/1/0 {unit 1 {description to-B;encapsulation ethernet;peer-unit 2;family inet {address 10.10.10.1/30;}}}lo0 {unit 1 {family inet {address 192.168.6.5/32;}}}}protocols {bgp {group internal-peers {type internal;local-address 192.168.6.5;export send-direct;neighbor 192.163.6.4;neighbor 192.168.40.4;}}ospf {area 0.0.0.0 {interface lo0.1 {passive;}interface lt-0/1/0.1;}}}policy-options {policy-statement send-direct {term 2 {from protocol direct;then accept;}}}routing-options {router-id 192.168.6.5;autonomous-system 17;}}
    B {interfaces {lt-0/1/0 {unit 2 {description to-A;encapsulation ethernet;peer-unit 1;family inet {address 10.10.10.2/30;}}unit 5 {description to-C;encapsulation ethernet;peer-unit 6;family inet {address 10.10.10.5/30;}}}lo0 {unit 2 {family inet {address 192.163.6.4/32;}}}}protocols {bgp {group internal-peers {type internal;local-address 192.163.6.4;export send-direct;neighbor 192.168.40.4;neighbor 192.168.6.5;}}ospf {area 0.0.0.0 {interface lo0.2 {passive;}interface lt-0/1/0.2;interface lt-0/1/0.5;}}}policy-options {policy-statement send-direct {term 2 {from protocol direct;then accept;}}}routing-options {router-id 192.163.6.4;autonomous-system 17;}}
    C {interfaces {lt-0/1/0 {unit 6 {description to-B;encapsulation ethernet;peer-unit 5;family inet {address 10.10.10.6/30;}}}lo0 {unit 3 {family inet {address 192.168.40.4/32;}}}}protocols {bgp {group internal-peers {type internal;local-address 192.168.40.4;export send-direct;neighbor 192.163.6.4;neighbor 192.168.6.5;}}ospf {area 0.0.0.0 {interface lo0.3 {passive;}interface lt-0/1/0.6;}}}policy-options {policy-statement send-direct {term 2 {from protocol direct;then accept;}}}routing-options {router-id 192.168.40.4;autonomous-system 17;}}

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

    Verification

    Confirm that the configuration is working properly.

    Verifying BGP Neighbors

    Purpose

    Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address.

    Action

    From the operational mode, enter the show bgp neighbor command.

    user@R1> show bgp neighbor logical-system A
    Peer: 192.163.6.4+179 AS 17    Local: 192.168.6.5+58852 AS 17   
      Type: Internal    State: Established    Flags: <Sync>
      Last State: OpenConfirm   Last Event: RecvKeepAlive
      Last Error: None
      Export: [ send-direct ] 
      Options: <Preference LocalAddress Refresh>
      Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
      Number of flaps: 0
      Peer ID: 192.163.6.4     Local ID: 192.168.6.5       Active Holdtime: 90
      Keepalive Interval: 30         Peer index: 0   
      BFD: disabled, down
      NLRI for restart configured on peer: inet-unicast
      NLRI advertised by peer: inet-unicast
      NLRI for this session: inet-unicast
      Peer supports Refresh capability (2)
      Restart time configured on the peer: 120
      Stale routes from peer are kept for: 300
      Restart time requested by this peer: 120
      NLRI that peer supports restart for: inet-unicast
      NLRI that restart is negotiated for: inet-unicast
      NLRI of received end-of-rib markers: inet-unicast
      NLRI of all end-of-rib markers sent: inet-unicast
      Peer supports 4 byte AS extension (peer-as 17)
      Peer does not support Addpath
      Table inet.0 Bit: 10000
        RIB State: BGP restart is complete
        Send state: in sync
        Active prefixes:              0
        Received prefixes:            3
        Accepted prefixes:            3
        Suppressed due to damping:    0
        Advertised prefixes:          2
      Last traffic (seconds): Received 16   Sent 1    Checked 63  
      Input messages:  Total 15713  Updates 4       Refreshes 0     Octets 298622
      Output messages: Total 15690  Updates 2       Refreshes 0     Octets 298222
      Output Queue[0]: 0
    
    Peer: 192.168.40.4+179 AS 17   Local: 192.168.6.5+56466 AS 17   
      Type: Internal    State: Established    Flags: <Sync>
      Last State: OpenConfirm   Last Event: RecvKeepAlive
      Last Error: None
      Export: [ send-direct ] 
      Options: <Preference LocalAddress Refresh>
      Local Address: 192.168.6.5 Holdtime: 90 Preference: 170
      Number of flaps: 0
      Peer ID: 192.168.40.4    Local ID: 192.168.6.5       Active Holdtime: 90
      Keepalive Interval: 30         Peer index: 1   
      BFD: disabled, down
      NLRI for restart configured on peer: inet-unicast
      NLRI advertised by peer: inet-unicast
      NLRI for this session: inet-unicast
      Peer supports Refresh capability (2)
      Restart time configured on the peer: 120
      Stale routes from peer are kept for: 300
      Restart time requested by this peer: 120
      NLRI that peer supports restart for: inet-unicast
      NLRI that restart is negotiated for: inet-unicast
      NLRI of received end-of-rib markers: inet-unicast
      NLRI of all end-of-rib markers sent: inet-unicast
      Peer supports 4 byte AS extension (peer-as 17)
      Peer does not support Addpath
      Table inet.0 Bit: 10000
        RIB State: BGP restart is complete
        Send state: in sync
        Active prefixes:              0
        Received prefixes:            2
        Accepted prefixes:            2
        Suppressed due to damping:    0
        Advertised prefixes:          2
      Last traffic (seconds): Received 15   Sent 22   Checked 68  
      Input messages:  Total 15688  Updates 2       Refreshes 0     Octets 298111
      Output messages: Total 15688  Updates 2       Refreshes 0     Octets 298184
      Output Queue[0]: 0

    Verifying BGP Groups

    Purpose

    Verify that the BGP groups are configured correctly.

    Action

    From the operational mode, enter the show bgp group command.

    user@A> show bgp group logical-system A
    Group Type: Internal    AS: 17                     Local AS: 17
      Name: internal-peers  Index: 0                   Flags: <Export Eval>
      Export: [ send-direct ] 
      Holdtime: 0
      Total peers: 2        Established: 2
      192.163.6.4+179
      192.168.40.4+179
      inet.0: 0/5/5/0
    
    Groups: 1  Peers: 2    External: 0    Internal: 2    Down peers: 0   Flaps: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0                 5          0          0          0          0          0

    Verifying BGP Summary Information

    Purpose

    Verify that the BGP configuration is correct.

    Action

    From the operational mode, enter the show bgp summary command.

    user@A> show bgp summary logical-system A
    Groups: 1 Peers: 2 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0                 5          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    192.163.6.4              17      15723      15700       0       0 4d 22:13:15 0/3/3/0              0/0/0/0
    192.168.40.4             17      15698      15699       0       0 4d 22:13:11 0/2/2/0              0/0/0/0

    Verifying That BGP Routes Are Installed in the Routing Table

    Purpose

    Verify that the export policy configuration is working.

    Action

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

    user@A> show route protocol bgp logical-system A
    inet.0: 7 destinations, 12 routes (7 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    10.10.10.0/30       [BGP/170] 4d 11:05:55, localpref 100, from 192.163.6.4
                          AS path: I
                        > to 10.10.10.2 via lt-0/1/0.1
    10.10.10.4/30       [BGP/170] 4d 11:05:55, localpref 100, from 192.163.6.4
                          AS path: I
                        > to 10.10.10.2 via lt-0/1/0.1
                        [BGP/170] 4d 11:03:10, localpref 100, from 192.168.40.4
                          AS path: I
                        > to 10.10.10.2 via lt-0/1/0.1
    192.163.6.4/32      [BGP/170] 4d 11:05:55, localpref 100, from 192.163.6.4
                          AS path: I
                        > to 10.10.10.2 via lt-0/1/0.1
    192.168.40.4/32     [BGP/170] 4d 11:03:10, localpref 100, from 192.168.40.4
                          AS path: I
                        > to 10.10.10.2 via lt-0/1/0.1

    Modified: 2014-07-11