Description

In Contrail networking, when troubleshooting routing issues on a compute node peer with gateway router indirectly via controller, you will see different "route types". For example, route type "BGP", "XMPP", "Local", "ServiceChain" and etc. Route type provides basic information about where the route is learned from.

This article will explain what is a "ServiceChain" type of route is and how it is generated.

Solution

There is an In-network-nat service chaining setup with 2 port-tuples configured. With this setup, there are 2 routing instances (RI), among others: left RI and right RI. These are the basic parameters in use.

  • left VN: 10.10.10.0/24
  • right VN: 20.20.20.0/24
  • left VMI in port-tuple1: 10.10.10.3/32
  • left VMI in port-tuple2: 10.10.10.4/32
  • right VMI in port-tuple1: 20.20.20.3/32
  • right VMI in port-tuple2: 20.20.20.4/32

The goal is to examine the route leak behavior and identify the type of routes after it is leaked from right RI to left RI.

Right VMI route in right RI

First,check one of the VMI routes in the right RI: 

    default-domain:pings:tenant-pings-net2:tenant-pings-net2.inet.0: 3 destinations, 8 routes (4 primary, 4 secondary, 0 infeasible)

    20.20.20.3/32, age: 1:37:16.994209, last_modified: 2020-Jun-05 16:26:53.952806  <---
        [XMPP|bcomp79] age: 1:37:16.997907, localpref: 100, nh: 172.18.79.79, encap: ['gre', 'udp'], label: 20, AS path: None
        [BGP|172.18.101.103] age: 1:37:16.995901, localpref: 100, nh: 172.18.79.79, encap: ['gre', 'udp'], label: 20, AS path: None

So this VMI route is learned:

  • Via XMPP, from compute named `bcomp79`. The nexthop IP confirmed the same.
  • Via BGP, from the other control node. The reason is that each compute node is typically peering with 2 controllers.

Right VMI route in left RI

With service chain, route leak will happen between the left and right routing instance. With the `in-network-nat` type of service chain, routes in right RI will leak to left RI by default, but not vice versa. For the same right VMI route, it will also show up in the left RI: 

default-domain:pings:tenent-pings-net:tenent-pings-net.inet.0: 6 destinations, 20 routes (4 primary, 16 secondary, 0 infeasible)

20.20.20.3/32, age: 0:40:59.492165, last_modified: 2020-Jun-05 16:31:53.792869
    [ServiceChain|None] age: 0:40:59.493650, localpref: 200, nh: 172.18.79.79, encap: ['gre', 'udp'], label: 31, AS path: None  <---
    [ServiceChain|None] age: 0:40:59.493873, localpref: 200, nh: 172.18.102.80, encap: ['gre', 'udp'], label: 39, AS path: None <---
    [BGP|172.18.101.103] age: 0:40:59.492535, localpref: 200, nh: 172.18.79.79, encap: ['gre', 'udp'], label: 31, AS path: None
    [BGP|172.18.101.103] age: 0:40:59.492654, localpref: 200, nh: 172.18.102.80, encap: ['gre', 'udp'], label: 39, AS path: None

Here are the highlights of this route:

  • The route is leaked by control node, and marked as type "ServiceChain". The original route type "XMPP" is replaced.
  • The orignal nexthop (NH), which is compute node `bcomp79` only, is replaced with two ECMP nexthops, pointing to `bcomp79` and `bcomp80` respectively. There are the compute nodes where the two service VMs are running. This is load balancing implementation of the service chain.