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.

Note: The image displayed is truncated to fit this page. On the console screen you can scroll horizontally to see more columns and data.

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

http ://nodea22.example.com:8083/Snh_ShowRoutingInstanceReq?name= 

Note: Throughout this example, replace nodea22.example.com with the correct location for the control node on your system.

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.

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

http ://nodea22.example.com8083/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.

Sample Output, Validate Route:

3. Validate the l3vpn table.

http: //nodea22.example.com:8083/Snh_ShowRouteReq?x=bgp.l3vpn.0

Sample Output, Validate L3vpn Table:

The following sample output has been scrolled horizontally to display the BGP path attributes of each route.  

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 policies.

The label (MPLS) and tunnel encap columns can be used for debugging data path issues.

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.

1. Create a network policy to allow vn1 and vn2 traffic and associate the policy to the virtual networks.
   
   
2. Validate that the routing instances have the correct import_target configuration.
   
   http: //nodea22.example.com:8083/Snh_ShowRoutingInstanceReq?name=
   
   Sample Output, Validate Import Target:
   
   
   
   
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.

Sample Output, Route Import:

1. Check the BGP peer UVE.

http: //nodea20.example.com: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.

3. Fix the 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: //nodea20.example.com:8081/analytics/uves/bgp-peers

1. Verify the routes in the public.inet.0 table.

http: //nodea20.example.com:8083/Snh_ShowRouteReq?x=default-domain:admin:public:public.inet.0

1. Launch a virtual machine (11.2.3.253 in the sample case) in the public network and verify the route in the public.inet.0 table.
   http: //nodea20.example.com:8083/Snh_ShowRouteReq?x=default-domain:admin:public:public.inet.0
   
   
2. Verify the route in the bgp.l3vpn.0 table.

   http: //nodea20.example.com:8083/Snh_ShowRouteReq?x=bgp.l3vpn.0
   
   

    

   Check the Route in the MX Series Router
   
   

   Use Junos CLI show commands from the router to check the route.
   
   

   run show route table public.inet.0

   public.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)

   + = Active Route, - = Last Active, * = Both

    

   0.0.0.0/0          *[Static/5] 15w6d 08:50:34

                       > to 10.204.218.254 via ge-1/0/1.0

   10.204.218.0/24    *[Direct/0] 15w6d 08:50:35

                       > via ge-1/0/1.0

   10.204.218.1/32    *[Local/0] 15w6d 08:50:51

                         Local via ge-1/0/1.0

   10.204.219.225/32  *[BGP/170] 01:13:34, localpref 100, from 10.204.216.45

                         AS path: ?, validation-state: unverified

                       > via gr-1/0/0.32771, Push 16

                       [BGP/170] 01:13:34, localpref 100, from 10.204.217.16

                         AS path: ?, validation-state: unverified

                       > via gr-1/0/0.32771, Push 16

   11.2.3.253/32      *[BGP/170] 00:03:20, localpref 100, from 10.204.216.16

                         AS path: ?, validation-state: unverified

                       > via gr-1/0/0.32769, Push 16



    

   run show route table bgp.l3vpn.0 receive-protocol bgp 10.204.216.16 detail

   bgp.l3vpn.0: 92 destinations, 130 routes (92 active, 0 holddown, 0 hidden)

   * 10.204.216.70:1:11.2.3.253/32 (1 entry, 0 announced)

        Import Accepted

        Route Distinguisher: 10.204.216.70:1

        VPN Label: 16

        Nexthop: 10.204.216.70

        Localpref: 100

        AS path: ?

        Communities: target:64512:1 target:64512:10003 unknown iana 30c unknown iana 30c unknown type 8004 value fc00:1 unknown type 8071 value fc00:4