Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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.

  1. List BGP routers with the following Contrail API request.

    bgp-router is created in Contrail for each control node, BGPaaS, and external BGP routers. These are visible from the following location, shown using the sample node setup.

    http: //<host ip address>:8082/bgp-routers

    Note:

    Throughout this procedure, replace <host ip address> with the correct location for your system to see the setup in your system.​

    Figure 1: Sample Output, BGP RoutersJSON structure of BGP routers with href URLs, fq_name lists for router identifiers, and uuid unique identifiers for network management.
  2. Verify the BGP peering.

    The following statement is entered to check the bgp_router_refs object on the API server to validate the peering on the sample setup.

    http: //<host ip address>:8082/bgp-router/1da579c5-0907-4c98-a7ad-37671f00cf60

    Figure 2: Sample Output, BGP Router ReferencesBGP router configuration with vendor contrail, AS number 64512, IP 10.204.216.16, port 179, inet-vpn and e-vpn families.
  3. Verify the command line arguments that are passed to the control-node.

    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.

  4. Validate the BGP neighbor config and the BGP peering config object available on the control node. The control node receives the configuration from Cassandra (starting with Contrail Networking Release 4.0) or from IF-MAP (earlier than Contrail Networking Release 4.0).

    http: //<host ip address>:8083/Snh_ShowBgpNeighborConfigReq?

    Figure 3: Sample Output, BGP Neighbor ConfigBGP neighbor configuration table with instance name, neighbor name, vendor, AS number, IP address, and address families.

    http: //<host ip address>:8083/Snh_ShowBgpPeeringConfigReq?

    Figure 4: Sample Output, BGP Peering ConfigScreenshot of a BGP peering configuration interface showing an empty table with columns instance_name, name, and neighbor_count, and a sidebar with sections sessions, valid attributes, and attributes.
  5. Check the BGP neighbor states on the control node.

    http: //<host ip address>:8083/Snh_ShowBgpNeighborSummaryReq

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

  1. Validate the presence of the routing instance for each virtual network in the sample system.

    http ://<host ip address>:8083/Snh_ShowRoutingInstanceReq?name=

    Note:

    Throughout this example, replace <host ip address> with the correct location for the control node on your system.

    Figure 5: Sample Output, Show Routing InstanceData table screenshot showing volumes default-domain:demo:vvl and default-domain:demo:vvl:vvl2 with import and export targets like target1:65121 and peers node1a, node2a, node1b, node2b.

    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.

  2. Validate a route in a given routing instance in the sample setup:

    http ://<host ip address>:8083/Snh_ShowRouteReq?x=default-domain:demo:vn1:vn1.inet.0

    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 6: Sample Output, Validate RouteRouting table screenshot showing routing instance default-dennis-demo-vni with 1 prefix and 2 paths. Primary path is active, no secondary or unusable paths. Route prefix 1.1.1.251/32 uses BGP protocol, last modified on 2021-10-10.

  3. Validate the l3vpn table.

    http: //<host ip address>:8083/Snh_ShowRouteReq?x=bgp.l3vpn.0

    Figure 7: Sample Output, Validate L3vpn TableRouting table with 4 prefixes in bgp.l3vpn.0; 2 primary and 2 secondary paths via XMPP; last modified timestamp shown.

    The following sample output has been scrolled horizontally to display the BGP path attributes of each route’s. 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 8: Sample Output, Validate L3vpn Table, ScrolledTable displaying network routing information with source nodes, AS path, next hop IPs, tunnel protocols, MPLS labels, replication status, primary routing tables, route communities, origin virtual networks, and flags.

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.

  1. Create a network policy to allow vn1 and vn2 traffic and associate the policy to the virtual networks.
    Figure 9: Create Policy WindowUser interface for creating a network policy with fields for policy name, rules, action, protocol, source network, source ports, direction, destination network, destination ports, apply service, and mirror to. Buttons for Cancel and Submit are at the bottom.
  2. Validate that the routing instances have the correct import_target configuration.

    http: //<host ip address>:8083/Snh_ShowRoutingInstanceReq?name=

    Figure 10: Sample Output, Validate Import TargetNetwork configuration interface showing two entities: default-domain:demo:vm1 and default-domain:demo:vm2 with IDs 4 and 5, import/export targets 64512:1 and 64512:2.
  3. Validate that the routes are imported from VRF.

    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 11: Sample Output, Route ImportRouting table screenshot showing instance default-domain:demo-vn2:vn2 with table name default-domain:demo-vn2:vn2.inet.0. Displays 4 prefixes, 4 paths with 3 primary and 3 secondary, 0 ineligible. Routes include prefixes like 1.1.1.253/32 and 2.2.2.253/32 with protocols XMPP and BGP.

Debugging Peering with an MX Series Router

This section sets up an example BGP MX Series peer and provides some troubleshooting scenarios.

  1. Set the Global AS number of the control-node for an MX Series BGP peer, using the Contrail WebUI (eBGP).
    Figure 12: Edit Global ASN WindowUser interface for editing Global ASN with number 54321 entered. Buttons: Cancel and Save.
  2. Configure the eBGP peer for the MX Series router. Use the Contrail Web UI or Python provisioning.
    Figure 13: Create BGP Peer WindowConfiguration interface for creating BGP peer with fields for Hostname, Autonomous System, Address, Router ID, BGP Port, Address Family, Control Node or BGP Peer, Vendor ID, Available Peers, Configured Peers, and Save button.

    Configuring the MX Series BGP peer with the Python provision utility:

  3. Configure a control-node peer on the MX Series router, using Junos CLI:

Debugging a BGP Peer Down Error with Incorrect Family

Use this procedure to identify and resolve errors that arise from families mismatched configurations.

Note:

This example uses locations at http: //<host ip address>:. Be sure to replace <host ip address> with the correct address for your environment.

  1. Check the BGP peer UVE.

    http: //<host ip address>:8081/analytics/uves/bgp-peers

  2. 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 14: Sample BGP Peer UVEBGP peer info: state Idle, last state Idle, local ASN 54321, peer ASN 12345, peer address 10.204.216.253, peer type external, hold time 90 seconds.
  3. Fix the families mismatch in the sample by updating the configuration on the MX Series router, using Junos CLI:

    set protocols bgp group contrail-control-nodes family inet-vpn unicast

  4. After committing the CLI configuration, the peer comes up. Verify this with UVE.

    http: //<host ip address>:8081/analytics/uves/bgp-peers

    Figure 15: Sample Established BGP Peer UVEBGP peer info: State is Established from OpenConfirm. Last event fsm::EvBgpUpdate. Peer type external, local ASN 54321, peer ASN 12345. Address family IPv4:Vpn.
  5. Verify the peer status on the MX Series router, using Junos CLI:

Configuring MX Peering (iBGP)

  1. Edit the Global ASN.
    Figure 16: Edit Global ASN WindowEdit Global ASN dialog with a field labeled Global ASN containing 64512 and buttons Cancel and Save.
  2. Configure the MX Series IBGP peer, using Contrail WebUI or Python provisioning.
    Figure 17: Create BGP Peer WindowConfiguration interface for creating a BGP peer with fields for Hostname, Address, BGP Port, Autonomous System, Router ID, Address Family, Control Node or BGP Peer, Vendor ID, and peer management options.

    Configuring the MX Series BGP peer with the Python provision utility:

    python ./provision_mx.py --router_name mx--router_ip <ip address> --router_asn 64512 --api_server_ip <ip address> --api_server_port 8082 --oper add --admin_user admin --admin_password <password> --admin_tenant_name admin

  3. Verify the peer from UVE.

    http ://<host ip address>:8081/analytics/uves/bgp-peers

    Figure 18: Sample Established IBGP Peer UVEBGP session data: state is Established from OpenConfirm; peer type is internal with ASN 64512; peer IP is 10.204.216.253.
  4. You can verify the same information at the HTTP introspect page of the control node (8443 in this example).

    http: //<host ip address>:8083/Snh_BgpNeighborReq?ip_address=&domain=

    Figure 19: Sample Established IBGP Peer Introspect WindowBGP neighbor table with peer IP 10.204.216.253, established state, and iBGP type. Local ASN is 64512, sync state in sync.

Checking Route Exchange with an MX Series Peer

  1. Check the route table in the bgp.l3vpn.0 table.
    Figure 20: Routing Instance Route TableRouting table with instance default-domain:default-project:ip-fabric:__default__, table bgp.l3vpn.0, 2 prefixes, 2 paths, 2 primary, 0 secondary, 0 infeasible. Routes: 10.204.216.253:5:0.0.0.0/8 and 10.204.216.253:5:10.204.218.0/24.
  2. Configure a public virtual network.
    Figure 21: Routing Instance Route TableRouting table with instance default-domain:default-project:ip-fabric:__default__, table bgp.l3vpn.0, 2 prefixes, 2 paths, 2 primary, 0 secondary, 0 infeasible. Routes: 10.204.216.253:5:0.0.0.0/8 and 10.204.216.253:5:10.204.218.0/24.
  3. Verify the routes in the public.inet.0 table.

    http: //<host ip address>:8083/Snh_ShowRouteReq?x=default-domain:admin:public:public.inet.0

    Figure 22: Routing Instance Public IPv4 Route TableScreenshot of a routing table showing instance default-domain:admin:public:public with 2 prefixes, 2 paths, 0 primary paths, 2 secondary paths, and 0 infeasible paths. Routes include 0.0.0.0/0 and 10.204.218.0/24.
  4. Launch a virtual machine in the public network and verify the route in the public.inet.0 table.

    http: //<host ip address>:8083/ Snh_ShowRouteReq?x=default-domain:admin:public:public.inet.0

    Figure 23: Virtual Machine Routing Instance Public IPv4 Route TableScreenshot of a routing table showing routing instances, table names, prefixes, paths, and protocols like BGP and IGP for network management.
  5. Verify the route in the bgp.l3vpn.0 table.

    http: //<host ip address>:8083/Snh_ShowRouteReq?x=bgp.l3vpn.0

    Figure 24: BGP Routing Instance Route TableTable showing routing information: Routing instance is default-domain:default-project:ip-fabric:default. Routing table name is bgp.l3vpn.0. Contains 3 prefixes, 3 paths, 2 primary paths, 1 secondary path, 0 infeasible paths. Routes listed are 10.204.216.253:5:0.0.0.0/0, 10.204.216.253:5:10.204.218.0/24, 10.204.216.70:11:1.2.3.253/32.

Checking the Route in the MX Series Router

Use Junos CLI show commands from the router to check the route. These commands assume that the routing instance with the imported route table from Contrail is configured on the MX Series router, either manually or by using Device Manager.