Содержание
- Debugging BGP Peering and Route Exchange in Contrail
- Example Cluster
- Verifying the BGP Routers
- Example
- Verifying the Route Exchange
- Debugging Route Exchange with Policies
- Debugging Peering with an MX Series Router
- Debugging a BGP Peer Down Error with Incorrect Family
- Configuring MX Peering (iBGP)
- Checking Route Exchange with an MX Series Peer
- Checking the Route in the MX Series Router
- BGP Session and Route Flaps
- Understanding BGP Session Resets
- Example: Preventing BGP Session Flaps When VPN Families Are Configured
- Requirements
- Overview
- Topology
- Configuration
- CLI Quick Configuration
- Procedure
- Procedure
- Procedure
- Verification
- Bringing Down the EBGP Session
- Verifying That the IBGP Sessions Remain Up
- See Also
- Understanding Damping Parameters
- See Also
- Example: Configuring BGP Route Flap Damping Parameters
- Requirements
- Overview
- Configuration
- Procedure
- Verification
- Causing Some Routes to Flap
- Checking the Route Flaps
- Verifying Route Flap Damping
- Displaying the Details of a Damped Route
- Verifying That Default Damping Parameters Are in Effect
- Filtering the Damping Information
- See Also
- Example: Configuring BGP Route Flap Damping Based on the MBGP MVPN Address Family
- Requirements
- Overview
- Topology
- Configuration
- CLI Quick Configuration
Debugging BGP Peering and Route Exchange in Contrail
Use the troubleshooting steps and guidelines in this topic when you have errors with Contrail BGP peering and route exchange.
Example Cluster
Examples in this document refer to a virtual cluster that is set up as follows:
Verifying the BGP Routers
Use this procedure to launch various introspects to verify the setup of the BGP routers in your system.
Use this procedure to launch various introspects to verify the setup of the BGP routers in your system.
All of the configured control nodes and external BGP routers are visible from the following location, shown using the sample node setup.
Throughout this procedure, replace with the correct location for your system to see the setup in your system.
Figure 1: Sample Output, BGP Routers:
The following statement is entered to check the bgp_router_refs object on the API server to validate the peering on the sample setup.
Figure 2: Sample Output, BGP Router References:
On the control-node, use ps aux | grep control-node to see the arguments that are passed to the control-node.
Example
The hostname is the bgp-router name. Ensure that the bgp-router config can be found for the hostname, using the procedure in Step 1.
Validate the BGP neighbor config and the BGP peering config object.
Figure 3: Sample Output, BGP Neighbor Config:
Figure 4: Sample Output, BGP Peering Config:
Figure 5: Sample Output, BGP Neighbor States:
If the peer is not in an established state, check the last_error and the flap_count. Debug the BGP state machine by using information displayed in the output, such as last_state and last_event.
The image displayed is truncated to fit this page. On the console screen you can scroll horizontally to see more columns and data.
Verifying the Route Exchange
The following two virtual networks are used in the sample debugging session for route exchange.
Example Procedure for Verifying Route Exchange
- Validate the presence of the routing instance for each virtual network in the sample system.
Throughout this example, replace with the correct location for the control node on your system.
Figure 6: Sample Output, Show Routing Instance:
In the sample output, you can see the import_target and the export_target configured on the routing instance. Also shown are the xmpp peers ( vroutes) registered to the table.
The user can click on the inet table of the required routing instance to display the routes that belong to the instance.
Use the information in Step 2 to validate a route.
Validate a route in a given routing instance in the sample setup:
In the following sample output (truncated), the user can validate the BGP paths for the protocol and for the source of the route to verify which XMPP agent or vRouter has pushed the route. If the path source is BGP, the route is imported to the VRF table from a BGP peer, either another control-node or an external bgp router such as an MX Series router. BGP paths are displayed in the order of path selection.
Figure 7: Sample Output, Validate Route:
Validate the l3vpn table.
Figure 8: Sample Output, Validate L3vpn Table:
The following sample output has been scrolled horizontally to display the BGP path attributes of each route. policies.
The extended community (communities column), determines the VRF table to which this VPN route is imported. The origin_vn shows the virtual network where this route was created, information useful for applying ACL
The label (MPLS) and tunnel encap columns can be used for debugging data path issues.
Figure 9: Sample Output, Validate L3vpn Table, Scrolled:
Debugging Route Exchange with Policies
This section uses the sample output and the sample vn1 and vn2 to demonstrate methods of debugging route exchange with policies.
- Create a network policy to allow vn1 and vn2 traffic and associate the policy to the virtual networks. Figure 10: Create Policy Window
Figure 11: Sample Output, Validate Import Target:
Use the BGP path attribute to check the replication status of the path. The route from the destination VRF should be replicated and validate the origin-vn.
Figure 12: Sample Output, Route Import:
Debugging Peering with an MX Series Router
This section sets up an example BGP MX Series peer and provides some troubleshooting scenarios.
- Set the Global AS number of the control-node for an MX Series BGP peer, using the Contrail WebUI (eBGP). Figure 13: Edit Global ASN Window
Configuring the MX Series BGP peer with the Python provision utility:
Debugging a BGP Peer Down Error with Incorrect Family
Use this procedure to identify and resolve errors that arise from families mismatched configurations.
This example uses locations at http: // : . Be sure to replace with the correct address for your environment.
Search for the MX Series BGP peer by name in the list.
In the sample output, families is the family advertised by the peer and configured_families is what is provisioned. In the sample output, the families configured on the peer has a mismatch, thus the peer doesn’t move to an established state. You can verify it in the peer UVE.
Figure 15: Sample BGP Peer UVE
set protocols bgp group contrail-control-nodes family inet-vpn unicast
After committing the CLI configuration, the peer comes up. Verify this with UVE.
Figure 16: Sample Established BGP Peer UVE
Configuring MX Peering (iBGP)
- Edit the Global ASN. Figure 17: Edit Global ASN Window
Configuring the MX Series BGP peer with the Python provision utility:
python ./provision_mx.py —router_name mx—router_ip —router_asn 64512 —api_server_ip —api_server_port 8082 —oper add —admin_user admin —admin_password
Verify the peer from UVE.
Figure 19: Sample Established IBGP Peer UVE
Figure 20: Sample Established IBGP Peer Introspect Window
Checking Route Exchange with an MX Series Peer
- Check the route table in the bgp.l3vpn.0 table. Figure 21: Routing Instance Route Table
Figure 23: Routing Instance Public IPv4 Route Table
http: // :8083/ Snh_ShowRouteReq?x=default-domain:admin:public:public.inet.0
Figure 24: Virtual Machine Routing Instance Public IPv4 Route Table
Figure 25: BGP Routing Instance Route Table
Checking the Route in the MX Series Router
Use Junos CLI show commands from the router to check the route.
Источник
BGP Session and Route Flaps
Understanding BGP Session Resets
Certain configuration actions and events cause BGP sessions to be reset (dropped and then reestablished).
If you configure both route reflection and VPNs on the same routing device, the following modifications to the route reflection configuration cause current BGP sessions to be reset:
Adding a cluster ID—If a BGP session shares the same autonomous system (AS) number with the group where you add the cluster ID, all BGP sessions are reset regardless of whether the BGP sessions are contained in the same group.
Creating a new route reflector—If you have an internal BGP (IBGP) group with an AS number and create a new route reflector group with the same AS number, all BGP sessions in the IBGP group and the new route reflector group are reset.
Changing configuration statements that affect BGP peers, such as renaming a BGP group, resets the BGP sessions.
If you change the address family specified in the [edit protocols bgp family] hierarchy level, all current BGP sessions on the routing device are dropped and then reestablished.
Example: Preventing BGP Session Flaps When VPN Families Are Configured
This example shows a workaround for a known issue in which BGP sessions sometimes go down and then come back up (in other words, flap) when virtual private network (VPN) families are configured. If any VPN family (for example, inet-vpn , inet6-vpn , inet-mpvn , inet-mdt , inet6-mpvn , l2vpn , iso-vpn , and so on) is configured on a BGP master instance, a flap of either a route reflector (RR) internal BGP (IBGP) session or an external BGP (EBGP) session causes flaps of other BGP sessions configured with the same VPN family.
Requirements
Before you begin:
Configure router interfaces.
Configure an interior gateway protocol (IGP).
Overview
When a router or switch is configured as either a route reflector (RR) or an AS boundary router (an external BGP peer) and a VPN family (for example, the family inet-vpn unicast statement) is configured, a flap of either the RR IBGP session or the EBGP session causes flaps of all other BGP sessions that are configured with the family inet-vpn unicast statement. This example shows how to prevent these unnecessary session flaps.
The reason for the flapping behavior is related to BGP operation in Junos OS when originating VPN routes.
BGP has the following two modes of operation with respect to originating VPN routes:
If BGP does not need to propagate VPN routes because the session has no EBGP peer and no RR clients, BGP exports VPN routes directly from the instance .inet.0 routing table to other PE routers. This behavior is efficient in that it avoids the creation of two copies of many routes (one in the instance .inet.0 table and one in the bgp.l3vpn.0 table).
If BGP does need to propagate VPN routes because the session has an EBGP peer or RR clients, BGP first exports the VPN routes from the instance .inet.0 table to the bgp.l3vpn.0 table. Then BGP exports the routes to other PE routers. In this scenario, two copies of the route are needed to enable best-route selection. A PE router might receive the same VPN route from a CE device and also from an RR client or EBGP peer.
The route export is not performed if the route in instance .inet.0 is a secondary route. In Junos OS, a route is only exported one time from one routing table as a primary route to another routing table as a secondary route. Because the route in instance .inet.0 is already a secondary route, it is not allowed to be moved again to the bgp.l3vpn.0 table, as needed to be advertised. The route does not reach the bgp.l3vpn.0 table and thus is not advertised. One workaround is to send the routes that should be advertised to inet.0 so that they are advertised.
When, because of a configuration change, BGP transitions from needing two copies of a route to not needing two copies of a route (or the reverse), all sessions over which VPN routes are exchanged go down and then come back up. Although this example focuses on the family inet-vpn unicast statement, the concept applies to all VPN network layer reachability information (NLRI) families. This issue impacts logical systems as well. All BGP sessions in the master instance related to the VPN NLRI family are brought down to implement the table advertisement change for the VPN NLRI family. Changing an RR to a non-RR or the reverse (by adding or removing the cluster statement) causes the table advertisement change. Also, configuring the first EBGP session or removing the EBGP session from the configuration in the master instance for a VPN NLRI family causes the table advertisement change.
The way to prevent these unnecessary session flaps is to configure an extra RR client or EBGP session as a passive session with a neighbor address that does not exist. This example focuses on the EBGP case, but the same workaround works for the RR case.
When a session is passive, the routing device does not send Open requests to a peer. Once you configure the routing device to be passive, the routing device does not originate the TCP connection. However, when the routing device receives a connection from the peer and an Open message, it replies with another BGP Open message. Each routing device declares its own capabilities.
Topology
Figure 1 shows the topology for the EBGP case. Router R1 has an IBGP session with Routers R2 and R3 and an EBGP session with Router R4. All sessions have the family inet-vpn unicast statement configured. If the R1-R4 EBGP session flaps, the R1-R2 and R1-R3 BGP sessions flap also.
Figure 2 shows the topology for the RR case. Router R1 is the RR, and RouterВ R3 is the client. Router R1 has IBGP sessions with Routers R2 and R3. All sessions have the familyВ inet-vpn unicast statement configured. If the R1-R3 session flaps, the R1-R2 and R1-R4 sessions flap also.
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.
Procedure
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 Junos OS CLI User Guide.
To configure the EBGP scenario:
Configure one or more VPN families.
Configure the EBGP session.
Configure the IBGP sessions.
(Optional) Configure BGP so that it generates a syslog message whenever a BGP peer makes a state transition.
Enabling the log-updown statement causes BGP state transitions to be logged at warning level.
Procedure
Step-by-Step Procedure
To verify that unnecessary session flaps are occurring:
Run the show bgp summary command to verify that the sessions have been established.
Deactivate the EBGP session.
Run the show bgp summary command to view the session flaps.
Procedure
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 Junos OS CLI User Guide.
To prevent unnecessary BGP session flaps:
Add a passive EBGP session with a neighbor address that does not exist in the peer autonomous system (AS).
Run the show bgp summary command to verify that the real sessions have been established and the passive session is idle.
Verification
Confirm that the configuration is working properly.
Bringing Down the EBGP Session
Purpose
Try to cause the flap issue after the workaround is configured.
Action
Verifying That the IBGP Sessions Remain Up
Purpose
Make sure that the IBGP sessions do not flap after the EBGP session is deactivated.
Action
See Also
Understanding Damping Parameters
BGP route flapping describes the situation in which BGP systems send an excessive number of update messages to advertise network reachability information. BGP flap damping is a method of reducing the number of update messages sent between BGP peers, thereby reducing the load on these peers, without adversely affecting the route convergence time for stable routes.
Flap damping reduces the number of update messages by marking routes as ineligible for selection as the active or preferable route. Marking routes in this way leads to some delay, or suppression , in the propagation of route information, but the result is increased network stability. You typically apply flap damping to external BGP (EBGP) routes (routes in different ASs). You can also apply flap damping within a confederation, between confederation member ASs. Because routing consistency within an AS is important, do not apply flap damping to internal BGP (IBGP) routes. (If you do, it is ignored.)
There is an exception that rule. Starting in Junos OS Release 12.2, you can apply flap damping at the address family level. In a Junos OS Release 12.2 or later installation, when you apply flap damping at the address family level, it works for both IBGP and EBGP.
By default, route flap damping is not enabled. Damping is applied to external peers and to peers at confederation boundaries.
When you enable damping, default parameters are applied, as summarized in Table 1.
Decay half-life—Number of minutes after which an arbitrary value is halved if a route stays stable.
Maximum hold-down time for a route, in minutes.
Reuse threshold—Arbitrary value below which a suppressed route can be used again.
1 through 20,000
Cutoff (suppression) threshold—Arbitrary value above which a route can no longer be used or included in advertisements.
1 through 20,000
To change the default BGP flap damping values, you define actions by creating a named set of damping parameters and including it in a routing policy with the damping action. For the damping routing policy to work, you also must enable BGP route flap damping.
See Also
Example: Configuring BGP Route Flap Damping Parameters
This example shows how to configure damping parameters.
Requirements
Before you begin, configure router interfaces and configure routing protocols.
Overview
This example has three routing devices. Device R2 has external BGP (EBGP) connections with Device R1 and Device R3.
Device R1 and Device R3 have some static routes configured for testing purposes, and these static routes are advertised through BGP to Device R2.
Device R2 damps routes received from Device R1 and Device R3 according to these criteria:
Damp all prefixes with a mask length equal to or greater than 17 more aggressively than routes with a mask length between 9 and 16.
Damp routes with a mask length between 0 and 8, inclusive, less than routes with a mask length greater than 8.
Do not damp the 10.128.0.0/9 prefix at all.
The routing policy is evaluated when routes are being exported from the routing table into the forwarding table. Only the active routes are exported from the routing table.
Figure 3 shows the sample network.
CLI Quick Configuration shows the configuration for all of the devices in Figure 3.
The section #d179e76__d179e263 describes the steps on Device R2.
Configuration
Procedure
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
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 Junos OS CLI User Guide.
To configure damping parameters:
Configure the interfaces.
Configure the BGP neighbors.
Create and configure the damping parameter groups.
Configure the damping policy.
Enable damping for BGP.
Apply the policy as an import policy for the BGP neighbor.
You can refer to the same routing policy one or more times in the same or different import statements.
Configure an export policy.
Apply the export policy.
Configure the autonomous system (AS) number.
Results
From configuration mode, confirm your configuration by issuing 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.
Causing Some Routes to Flap
Purpose
To verify your route flap damping policy, some routes must flap. Having a live Internet feed almost guarantees that a certain number of route flaps will be present. If you have control over a remote system that is advertising the routes, you can modify the advertising router’s policy to effect the advertisement and withdrawal of all routes or of a given prefix. In a test environment, you can cause routes to flap by clearing the BGP neighbors or by restarting the routing process on the BGP neighbors, as shown here.
Action
From operational mode on Device R1 and Device R3, enter the restart routing command.
Use this command cautiously in a production network.
Meaning
On Device R2, all of the routes from the neighbors are withdrawn and re-advertised.
Checking the Route Flaps
Purpose
View the number of neighbor flaps.
Action
From operational mode, enter the show bgp summary command.
Meaning
This output was captured after the routing process was restarted on Device R2’s neighbors four times.
Verifying Route Flap Damping
Purpose
Verify that routes are being hidden due to damping.
Action
From operational mode, enter the show route damping suppressed command.
Meaning
The output shows some routing instability. Eleven routes are hidden due to damping.
Displaying the Details of a Damped Route
Purpose
Display the details of damped routes.
Action
From operational mode, enter the show route damping suppressed 172.16.192.0/20 detail command.
Meaning
This output indicates that the displayed route has a mask length that is equal to or greater than /17, and confirms that it has been correctly mapped to the aggressive damping profile. You can also see the route’s current (and last) figure of merit value, and when the route is expected to become active if it remains stable.
Verifying That Default Damping Parameters Are in Effect
Purpose
Locating a damped route with a /16 mask confirms that the default parameters are in effect.
Action
From operational mode, enter the show route damping suppressed detail | match 0/16 command.
Meaning
Routes with a /16 mask are not impacted by the custom damping rules. Therefore, the default damping rules are in effect.
To repeat, the custom rules are as follows:
Damp all prefixes with a mask length equal to or greater than 17 more aggressively than routes with a mask length between 9 and 16.
Damp routes with a mask length between 0 and 8, inclusive, less than routes with a mask length greater than 8.
Do not damp the 10.128.0.0/9 prefix at all.
Filtering the Damping Information
Purpose
Use OR groupings or cascaded piping to simplify the determination of what damping profile is being used for routes with a given mask length.
Action
From operational mode, enter the show route damping suppressed command.
Meaning
When you are satisfied that your EBGP routes are correctly associated with a damping profile, you can issue the clear bgp damping operational mode command to restore an active status to your damped routes, which will return your connectivity to normal operation.
See Also
Example: Configuring BGP Route Flap Damping Based on the MBGP MVPN Address Family
This example shows how to configure an multiprotocol BGP multicast VPN (also called Next-Generation MVPN) with BGP route flap damping.
Requirements
This example uses Junos OS Release 12.2. BGP route flap damping support for MBGP MVPN, specifically, and on an address family basis, in general, is introduced in Junos OS Release 12.2.
Overview
BGP route flap damping helps to diminish route instability caused by routes being repeatedly withdrawn and readvertised when a link is intermittently failing.
This example uses the default damping parameters and demonstrates an MBGP MVPN scenario with three provider edge (PE) routing devices, three customer edge (CE) routing devices, and one provider (P) routing device.
Topology
Figure 4 shows the topology used in this example.
On PE Device R4, BGP route flap damping is configured for address family inet-mvpn . A routing policy called dampPolicy uses the nlri-route-type match condition to damp only MVPN route types 3, 4, and 5. All other MVPN route types are not damped.
This example shows the full configuration on all devices in the CLI Quick Configuration section. The Configuring Device R4 section shows the step-by-step configuration for PE Device R4.
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.
Источник
Complete Software Guide for Junos
show bgp neighbor
neighbor-address
2088
®
OS for EX Series Ethernet Switches, Release 10.3
NLRI that peer supports restart for: inet-unicast inet6-unicast
NLRI that restart is negotiated for: inet-unicast inet6-unicast
NLRI of received end-of-rib markers: inet-unicast inet6-unicast
NLRI of all end-of-rib markers sent: inet-unicast inet6-unicast
Table inet.0 Bit: 10000
RIB State: restart is complete
Send state: in sync
Active prefixes: 4
Received prefixes: 6
Suppressed due to damping: 0
Table inet6.0 Bit: 20000
RIB State: restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 2
Suppressed due to damping: 0
Last traffic (seconds): Received 3
Input messages:
Total 9
Output messages: Total 7
Output Queue[0]: 0
Output Queue[1]: 0
Trace options: detail packets
Trace file: /var/log/bgpgr size 131072 files 10
user@host> show bgp neighbor 192.168.4.222
Peer: 192.168.4.222+4902 AS 65501 Local: 192.168.4.221+179 AS 65500
Type: External
State: Established
Last State: OpenConfirm
Last Error: Cease
Export: [ export-policy ] Import: [ import-policy ]
Options: <Preference HoldTime AddressFamily PeerAS PrefixLimit Refresh>
Address families configured: inet-unicast inet-multicast
Holdtime: 60000 Preference: 170
Number of flaps: 4
Last flap event: RecvUpdate
Error: ‘Cease’ Sent: 5 Recv: 0
Peer ID: 10.255.245.6
Keepalive Interval: 20000
BFD: disabled, down
Local Interface: fxp0.0
NLRI advertised by peer: inet-unicast inet-multicast
NLRI for this session: inet-unicast inet-multicast
Peer supports Refresh capability (2)
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes:
Received prefixes:
Accepted prefixes:
Suppressed due to damping:
Advertised prefixes:
Table inet.2 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes:
Received prefixes:
Accepted prefixes:
Suppressed due to damping:
Advertised prefixes:
Last traffic (seconds): Received 357
Input messages:
Total 4 Updates 2
Sent 3
Checked 3
Updates 6
Refreshes 0
Updates 3
Refreshes 0
Flags: <Sync>
Last Event: RecvKeepAlive
Local ID: 10.255.245.5
Peer index: 0
8
10
10
0
3
0
0
0
0
0
Sent 357
Checked 357
Refreshes 0
Octets 211
Copyright © 2010, Juniper Networks, Inc.
Octets 403
Octets 365
Active Holdtime: 60000
In this post, I’m going to explain how to establish a BGP peering session between Juniper QFX Series Switches and VMware NSX Edge Service Gateway. VMware NSX provides many features and services, one of which is dynamic routing via the use of an ESG. Typically, ESGs are placed at the edge of your virtual infrastructure to act as a gateway. There are two primary deployment options, stateful HA or non-stateful ECMP. In this example, we’re looking at the ECMP deployment option.
Overview
We have a pair of Juniper QFX5110 switches that we will configure to enable EBGP peering with each NSX Edge Gateway. We also have a pair of NSX Edge Gateway devices that are placed at the edge of a virtualized infrastructure. Each QFX has a /31 point-to-point network to each ESG. These networks are enabled via 802.1q subinterfaces which provide connectivity across the underlying blade chassis interconnect modules.
Topology
IP | AS Deets
We’ll start by configuring BGP on our NSX Edge Gateways.
ESG1
Global Routing Configuration
Via global settings for ESG1, we need to set a Router ID. The router ID is used to identify from where a packet is received.
ESG1 > Manage > Routing > Global Configuration > Dynamic Routing Configuration
BGP Settings
Here we need to configure a couple of global BGP options. Firstly, we need to enable BGP, then we need to enable Graceful Restart to help preserve forwarding state whilst BGP restarts. Lastly, we set the local AS for ESG1. As we are using EBGP for the peering, each BGP enabled device in this setup will be configured with a unique private AS number.
ESG1 > Manage > Routing > BGP > BGP Configuration
BGP Neighbors
Next up we need to setup two new BGP neighbor sessions, one to QFX1 and the other to QFX2. To do this we need to define the remote peer neighbor address and remote peer AS. Note. as we are using EBGP, and we are also peering with the network interface address, the default EBGP TTL of 1 is ok. We also untick the “remove private as” setting as this can cause issues with routing loops etc. In most scenarios, we want to maintain full visibility of the AS path unless this was a direct peering with a transit provider.
ESG1 > Manage > Routing > BGP > Neighbors
QFX1 Peering:
QFX2 Peering:
ESG2
Now let’s carry out similar steps on ESG2 but with slightly different variables.
Global Routing Configuration
Router ID
ESG2 > Manage > Routing > Global Configuration > Dynamic Routing Configuration
BGP Settings
Enable BGP, GRES and configure local AS.
ESG2 > Manage > Routing > BGP > BGP Configuration
BGP Neighbors
Configure BGP neighbors
ESG2 > Manage > Routing > BGP > Neighbors
QFX1 Peering:
QFX2 Peering:
QFX
Now let’s configure BGP on our Juniper QFX devices. A routing-instance named NSX is created and within the routing-instance, a BGP group named NSX is also created. Local-as, neighbor address and peer-as are defined.
QFX1
admin@QFX1> show configuration routing-instances NSX protocols bgp group NSX
type external;
description "BGP PEERS TO NSX ESG";
local-as 65103;
graceful-restart;
neighbor 172.16.16.137 {
peer-as 65121;
}
neighbor 172.16.16.139 {
peer-as 65122;
}
QFX2
admin@QFX2> show configuration routing-instances NSX protocols bgp group NSX
type external;
description "BGP PEERS TO NSX ESG";
local-as 65104;
graceful-restart;
neighbor 172.16.16.141 {
peer-as 65121;
}
neighbor 172.16.16.143 {
peer-as 65122;
}
Tuning
Unfortunately, NSX does not yet support BFD which is used for ultra-fast network failure detection. This is important when considering most blade chassis’ contain some kind of interconnect module. This interconnect module means that we quite often cannot rely on a link down event in order to tear down a BGP peering and withdraw the respective BGP prefixes. Until BFD is supported, our only option is to tune the BGP timers. Juniper has a default keepalive timer of 30 seconds and a holdtime of 90 seconds. NSX has a default keepalive of 60 seconds and holdtime of 180 seconds. Meaning a full 180 seconds must pass before the session is declared dead.
We’re going to amend these default values to enable faster detection of a failed peer.
NSX
ESG1
ESG1 > Manage > Routing > BGP > Neighbors
QFX1 Peering:
QFX2 Peering:
ESG2
ESG2 > Manage > Routing > BGP > Neighbors
QFX1 Peering:
QFX2 Peering:
QFX
On each QFX we only need to define the hold-time for the BGP sessions with the NSX ESGs. The keepalive interval is set to 1 by default when the hold-time is set to 3.
QFX1
admin@QFX1> show configuration routing-instances NSX protocols bgp group NSX
type external;
description "BGP PEERS TO NSX ESG";
hold-time 3;
local-as 65103;
graceful-restart;
neighbor 172.16.16.137 {
peer-as 65121;
}
neighbor 172.16.16.139 {
peer-as 65122;
}
QFX2
admin@QFX2> show configuration routing-instances NSX protocols bgp group NSX
type external;
description "BGP PEERS TO NSX ESG";
hold-time 3;
local-as 65104;
graceful-restart;
neighbor 172.16.16.141 {
peer-as 65121;
}
neighbor 172.16.16.143 {
peer-as 65122;
}
Verification
So lets now verify that BGP has been established between the Juniper QFX switches and the NSX Edge Gateways. There is a lot of very useful information that can be gleaned from the output, although all we’re really looking to verify is that the state is Estalished and ensure the Holdtime is negotiated to 3 seconds.
QFX1
ESG1 BGP Peering:
admin@QFX1> show bgp neighbor 172.16.16.137
Peer: 172.16.16.137+53807 AS 65121 Local: 172.16.16.136+179 AS 65103
Description: BGP PEERS TO NSX ESG
Group: NSX Routing-Instance: NSX
Forwarding routing-instance: NSX
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Cease
Options:
Holdtime: 3 Preference: 170 Local AS: 65103 Local System AS: 0
Number of flaps: 3
Last flap event: RestartTimeout
Error: 'Hold Timer Expired Error' Sent: 2 Recv: 0
Error: 'Cease' Sent: 1 Recv: 0
Peer ID: 172.16.16.137 Local ID: 172.16.16.26 Active Holdtime: 3
Keepalive Interval: 1 Group index: 4 Peer index: 0 SNMP index: 8
I/O Session Thread: bgpio-0 State: Enabled
BFD: disabled, down
Local Interface: ae3.301
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)
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI peer can save forwarding state: 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 does not support LLGR Restarter or Receiver functionality
Peer supports 4 byte AS extension (peer-as 65121)
Peer does not support Addpath
Table NSX.inet.0 Bit: 50001
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 1186345 Sent 785394 Checked 1186345
Input messages: Total 789358 Updates 2 Refreshes 0 Octets 14997874
Output messages: Total 870249 Updates 2 Refreshes 0 Octets 16534817
Output Queue[4]: 0 (NSX.inet.0, inet-unicast)
ESG2 BGP Peering:
admin@QFX1> show bgp neighbor 172.16.16.139
Peer: 172.16.16.139+36326 AS 65122 Local: 172.16.16.138+179 AS 65103
Description: BGP PEERS TO NSX ESG
Group: NSX Routing-Instance: NSX
Forwarding routing-instance: NSX
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Hold Timer Expired Error
Options:
Holdtime: 3 Preference: 170 Local AS: 65103 Local System AS: 0
Number of flaps: 2
Last flap event: RestartTimeout
Error: 'Hold Timer Expired Error' Sent: 2 Recv: 0
Peer ID: 172.16.16.139 Local ID: 172.16.16.26 Active Holdtime: 3
Keepalive Interval: 1 Group index: 4 Peer index: 1 SNMP index: 10
I/O Session Thread: bgpio-0 State: Enabled
BFD: disabled, down
Local Interface: ae3.302
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)
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
Restart flag received from the peer: Restarting
NLRI that peer supports restart for: inet-unicast
NLRI peer can save forwarding state: inet-unicast
NLRI that peer saved forwarding 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 does not support LLGR Restarter or Receiver functionality
Peer supports 4 byte AS extension (peer-as 65122)
Peer does not support Addpath
Table NSX.inet.0 Bit: 50001
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 1186903 Sent 785952 Checked 1186903
Input messages: Total 788709 Updates 2 Refreshes 0 Octets 14985543
Output messages: Total 869491 Updates 2 Refreshes 0 Octets 16520415
Output Queue[4]: 0 (NSX.inet.0, inet-unicast)
QFX2
ESG1 BGP Peering:
admin@QFX2> show bgp neighbor 172.16.16.141
Peer: 172.16.16.141+16527 AS 65121 Local: 172.16.16.140+179 AS 65104
Description: BGP PEERS TO NSX PE ESG
Group: NSX Routing-Instance: NSX
Forwarding routing-instance: NSX
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options:
Holdtime: 3 Preference: 170 Local AS: 65104 Local System AS: 0
Number of flaps: 0
Peer ID: 172.16.16.137 Local ID: 172.16.16.27 Active Holdtime: 3
Keepalive Interval: 1 Group index: 5 Peer index: 1 SNMP index: 8
I/O Session Thread: bgpio-0 State: Enabled
BFD: disabled, down
Local Interface: ae3.303
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)
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI peer can save forwarding state: 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 does not support LLGR Restarter or Receiver functionality
Peer supports 4 byte AS extension (peer-as 65121)
Peer does not support Addpath
Table NSX.inet.0 Bit: 50001
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 1187053 Sent 217102 Checked 1187053
Input messages: Total 217090 Updates 2 Refreshes 0 Octets 4124782
Output messages: Total 239357 Updates 1 Refreshes 0 Octets 4547828
Output Queue[4]: 0 (NSX.inet.0, inet-unicast)
ESG2 BGP Peering:
admin@QFX2> show bgp neighbor 172.16.16.143
Peer: 172.16.16.143+40691 AS 65122 Local: 172.16.16.142+179 AS 65104
Description: BGP PEERS TO NSX PE ESG
Group: NSX Routing-Instance: NSX
Forwarding routing-instance: NSX
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options:
Holdtime: 3 Preference: 170 Local AS: 65104 Local System AS: 0
Number of flaps: 0
Peer ID: 172.16.16.139 Local ID: 172.16.16.27 Active Holdtime: 3
Keepalive Interval: 1 Group index: 5 Peer index: 0 SNMP index: 10
I/O Session Thread: bgpio-0 State: Enabled
BFD: disabled, down
Local Interface: ae3.304
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)
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI peer can save forwarding state: 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 does not support LLGR Restarter or Receiver functionality
Peer supports 4 byte AS extension (peer-as 65122)
Peer does not support Addpath
Table NSX.inet.0 Bit: 50001
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 1187177 Sent 217227 Checked 1187177
Input messages: Total 217226 Updates 2 Refreshes 0 Octets 4127366
Output messages: Total 239495 Updates 1 Refreshes 0 Octets 4550450
Output Queue[4]: 0 (NSX.inet.0, inet-unicast)
ESG1
QFX1 Peering:
ESG1> show ip bgp neighbors 172.16.16.136
BGP neighbor is 172.16.16.136, remote AS 65103,
BGP state = Established, up
Hold time is 3, Keep alive interval is 1 seconds
Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast:advertised and received
Graceful restart Capability:advertised and received
Restart remain time: 0
Received 110 messages, Sent 107 messages
Default minimum time between advertisement runs is 30 seconds
For Address family IPv4 Unicast:advertised and received
Index 2 Identifier 0xbd200044
Route refresh request:received 0 sent 2
Prefixes received 1 sent 1 advertised 1
Connections established 1, dropped 2
Local host: 172.16.16.137, Local port: 53807
Remote host: 172.16.16.136, Remote port: 179
QFX2 Peering:
ESG1> show ip bgp neighbors 172.16.16.140
BGP neighbor is 172.16.16.140, remote AS 65104,
BGP state = Established, up
Hold time is 3, Keep alive interval is 1 seconds
Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast:advertised and received
Graceful restart Capability:advertised and received
Restart remain time: 0
Received 159 messages, Sent 143 messages
Default minimum time between advertisement runs is 30 seconds
For Address family IPv4 Unicast:advertised and received
Index 3 Identifier 0xbd200044
Route refresh request:received 0 sent 3
Prefixes received 1 sent 1 advertised 1
Connections established 5, dropped 42
Local host: 172.16.16.141, Local port: 16527
Remote host: 172.16.16.140, Remote port: 179
ESG2
QFX1 Peering:
ESG2> show ip bgp neighbors 172.16.16.138
BGP neighbor is 172.16.16.138, remote AS 65103,
BGP state = Established, up
Hold time is 3, Keep alive interval is 1 seconds
Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast:advertised and received
Graceful restart Capability:advertised and received
Restart remain time: 0
Received 118 messages, Sent 107 messages
Default minimum time between advertisement runs is 30 seconds
For Address family IPv4 Unicast:advertised and received
Index 2 Identifier 0xbd200044
Route refresh request:received 0 sent 2
Prefixes received 1 sent 1 advertised 1
Connections established 3, dropped 6151
Local host: 172.16.16.139, Local port: 53807
Remote host: 172.16.16.138, Remote port: 179
QFX2 Peering:
ESG2> show ip bgp neighbors 172.16.16.142
BGP neighbor is 172.16.16.142, remote AS 65104,
BGP state = Established, up
Hold time is 3, Keep alive interval is 1 seconds
Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast:advertised and received
Graceful restart Capability:advertised and received
Restart remain time: 0
Received 154 messages, Sent 139 messages
Default minimum time between advertisement runs is 30 seconds
For Address family IPv4 Unicast:advertised and received
Index 3 Identifier 0xbd200044
Route refresh request:received 0 sent 3
Prefixes received 1 sent 1 advertised 1
Connections established 5, dropped 42
Local host: 172.16.16.143, Local port: 16527
Remote host: 172.16.16.142, Remote port: 179
Beware, RPF 
Beware, NSX Edge Gateways are enabled with RPF (Reverse Path Filtering) by default. If you follow most reference architectures for an ECMP NSX Edge setup then you’ll probably not be aware of this (or bothered). As we are using two separate interfaces to connect to each QFX switch, as opposed to a shared transit network, ingress and egress traffic may well flow via a different path. You must disable RPF on each of the uplink interfaces in order to avoid losing legit traffic.
Today, we will learn to configure eBGP on Juniper Router. We will be using a simple point-to-point topology to keep the tutorial simple and to the point. So, let’s get started.
Every BGP configuration is done by following 2 steps. In first step, we need to tell, who we are by mentioning Autonomous System Number (ASN) and Router ID.
routing-options {
router-id 1.1.1.1;
autonomous-system 65001;
}
In the second step, we need to configure to establish a session with neighbors.
protocols {
bgp {
group Session-to-R1 {
type external;
neighbor 1.1.1.2 {
peer-as 65002;
}
}
}
}
Configuring eBGP on Juniper Devices
Let’s configure these by following below network topology.
First of all, we will configure the IP addresses of the interface for both of the Routers as per the topology.
R1: set interfaces ge-0/0/0 unit 0 family inet address 1.1.1.1/30 set interfaces ge-0/0/1 unit 0 family inet address 10.1.1.1/24
R2: set interfaces ge-0/0/0 unit 0 family inet address 1.1.1.2/30 set interfaces ge-0/0/1 unit 0 family inet address 172.16.0.1/24
Commit your configuration, and do basic check up.
[edit] root@R1# commit commit complete
Below, is my verification from R1 end. My both interfaces are UP and i can ping Router R2, from R1.
[edit] root@R1# run show interfaces terse | match ge- ge-0/0/0 up up ge-0/0/0.0 up up inet 1.1.1.1/30 ge-0/0/1 up up ge-0/0/1.0 up up inet 10.1.1.1/24 [edit] root@R1# [edit] root@R1# run ping 1.1.1.2 PING 1.1.1.2 (1.1.1.2): 56 data bytes 64 bytes from 1.1.1.2: icmp_seq=0 ttl=64 time=16.820 ms 64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=3.746 ms 64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=3.899 ms 64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=6.043 ms ^C --- 1.1.1.2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.746/7.627/16.820/5.385 ms [edit] root@R1#
Now, let’s move for BGP configuration. In the first step, I will be announcing ASN and Router-IDs.
R1: set routing-options autonomous-system 65001 set routing-options router-id 1.1.1.1
R2: set routing-options autonomous-system 65002 set routing-options router-id 1.1.1.2
In the second step, I will configure bgp session with remote end and commit the changes.
R1: set protocols bgp group BGP-to-R2 neighbor 1.1.1.2 peer-as 65002 set protocols bgp group BGP-to-R2 type external
Here, we are saying that, our BGP type is external, which means it’s eBGP. We will configure internal bgp (iBGP) in another article.
Now, we will check bgp session summary by using “run show bgp summary“. You will see, session status is Active. It’s because remote end, still not configured and R1 actively trying to establish the session.
R1:
[edit]
root@R1# run show bgp summary
Groups: 1 Peers: 1 Down peers: 1
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
1.1.1.2 65002 5741 5740 0 1 5 Active
[edit]
root@R1#
So, let’s configure R2 end and commit the changes.
R2: set protocols bgp group BGP-to-R1 neighbor 1.1.1.1 peer-as 65001 set protocols bgp group BGP-to-R1 type external
After completing the configuration in R2 ends, here is the final verification from R1.
[edit]
root@R1# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
0 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
1.1.1.2 65002 3 2 0 1 18 0/0/0/0 0/0/0/0
“run show bgp neighbor ” is another important command to verify bgp session and it will help to do the troubleshoot if needed.
[edit]
root@R1# run show bgp neighbor 1.1.1.2
Peer: 1.1.1.2+49742 AS 65002 Local: 1.1.1.1+179 AS 65001
Group: Session-to-R1 Routing-Instance: master
Forwarding routing-instance: master
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Cease
Options:
Holdtime: 90 Preference: 170
Number of flaps: 2
Last flap event: Stop
Error: 'Hold Timer Expired Error' Sent: 1 Recv: 0
Error: 'Cease' Sent: 2 Recv: 0
Peer ID: 1.1.1.2 Local ID: 1.1.1.1 Active Holdtime: 90
Keepalive Interval: 30 Group index: 0 Peer index: 0 SNMP index: 0
I/O Session Thread: bgpio-0 State: Enabled
BFD: disabled, down
Local Interface: ge-0/0/0.0
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)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
Restart flag received from the peer: Notification
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 does not support LLGR Restarter functionality
Peer supports 4 byte AS extension (peer-as 65002)
Peer does not support Addpath
Table inet.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Accepted prefixes: 0
Suppressed due to damping: 0
Advertised prefixes: 0
Last traffic (seconds): Received 159812 Sent 577 Checked 159812
Input messages: Total 24 Updates 1 Refreshes 0 Octets 504
Output messages: Total 22 Updates 0 Refreshes 0 Octets 422
Output Queue[1]: 0 (inet.0, inet-unicast)
[edit]
root@R1#
If you check routes list, you will not find any routes from the remote end. It’s because, we have not announced any routes yet.
[edit]
root@R1# run show route
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.0/30 *[Direct/0] 1d 19:52:28
> via ge-0/0/0.0
1.1.1.1/32 *[Local/0] 1d 19:52:28
Local via ge-0/0/0.0
10.1.1.0/24 *[Direct/0] 1d 19:52:28
> via ge-0/0/1.0
10.1.1.1/32 *[Local/0] 1d 19:52:28
Local via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 1d 20:14:26
MultiRecv
[edit]
root@R1#
So, let’s announce routes from both ends.
R1: set policy-options policy-statement BGP-Export term 1 from route-filter 10.1.1.0/24 exact set policy-options policy-statement BGP-Export term 1 then accept set policy-options policy-statement BGP-Import term 1 from route-filter 172.16.0.0/24 exact set policy-options policy-statement BGP-Import term 1 then accept set protocols bgp group BGP-to-R2 import BGP-Import set protocols bgp group BGP-to-R2 export BGP-Export
R2: set policy-options policy-statement BGP-Export term 1 from route-filter 172.16.0.0/24 exact set policy-options policy-statement BGP-Export term 1 then accept set policy-options policy-statement BGP-Import term 1 from route-filter 10.1.1.0/24 exact set policy-options policy-statement BGP-Import term 1 then accept set protocols bgp group BGP-to-R1 import BGP-Import set protocols bgp group BGP-to-R1 export BGP-Export
Now, verify final output of “run show bgp summary”.
[edit]
root@R1# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
1 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
1.1.1.2 65002 61 59 0 2 25:42 1/1/1/0 0/0/0/0
You can see, we announced 1 route and received 1 route. You also can run “run show route” to verify.
[edit]
root@R1# run show route
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.0/30 *[Direct/0] 1d 20:06:55
> via ge-0/0/0.0
1.1.1.1/32 *[Local/0] 1d 20:06:55
Local via ge-0/0/0.0
10.1.1.0/24 *[Direct/0] 1d 20:06:55
> via ge-0/0/1.0
10.1.1.1/32 *[Local/0] 1d 20:06:55
Local via ge-0/0/1.0
172.16.0.0/24 *[BGP/170] 00:03:52, localpref 100
AS path: 65002 I, validation-state: unverified
> to 1.1.1.2 via ge-0/0/0.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
ff02::2/128 *[INET6/0] 1d 20:28:53
MultiRecv
[edit]
root@R1#
So, our bgp session are established and we have routes in our routing table. Now, let’s ping from Bob‘s pc to Johns pc.
Bob> ping 172.16.0.100 84 bytes from 172.16.0.100 icmp_seq=1 ttl=62 time=15.025 ms 84 bytes from 172.16.0.100 icmp_seq=2 ttl=62 time=6.166 ms 84 bytes from 172.16.0.100 icmp_seq=3 ttl=62 time=23.729 ms 84 bytes from 172.16.0.100 icmp_seq=4 ttl=62 time=7.194 ms Bob>
Success!