Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Contrail] vRouter agent drops packet after restarting when LLGR and XMPP helper mode are enabled

0

0

Article ID: KB37121 KB Last Updated: 18 Jun 2021Version: 1.0
Summary:

This article explains why vRouter next hop 1 (Id:1 Type:Drop), when LLGR and XMPP helper mode is enabled and the agent is restarted. The issue is fixed in 2011L2.

Symptoms:

The route for a local interface does not have a valid next-hop (NH). It has a NH of 1 = drop. Snh_Inet4UcRouteReq introspect has a valid entry from LocalVmPort Peer. However, the invalid entry is coming from the controllers causing the issue. The discards counter is increasing in dropstats utility.

Recovery from this issue is sometimes successful by either an additional vRouter restart or a restart of the Contrail Controllers. Disabling the XMPP_helper always resolves this issue.

(vrouter-agent)[root@compute/]$ rt --get 192.168.17.11/32 --vrf 15
Match 192.168.17.11/32 in vRouter inet4 table 0/15/unicast

Flags: L=Label Valid, P=Proxy ARP, T=Trap ARP, F=Flood ARP
vRouter inet4 routing table 0/15/unicast
Destination PPL Flags Label Nexthop Stitched MAC(Index)
192.168.17.11/32 0 PT - 1 -

(vrouter-agent)[root@compute /]$ nh --get 1
Id:1 Type:Drop Fmly: AF_INET Rid:0 Ref_cnt:3889 Vrf:0
Flags:Valid, Etree Root,

Cause:

When LLGR and XMPP helper mode is enabled for vRouter agent, MPLS label from control node route update for local VM can have stale label from LLGR route update.

This behavior is caused by an incorrect sequence number in the agent route update to the control node for local VM port. With the helper enabled, the controller will not immediately withdraw routes when an agent goes down. In this scenario, the agent first advertises local routes to the controller with label x and sequence y. Once the agent restarts, it connects to a new set of controllers and advertises label z and sequence 0 to the new controllers. The old controller still has the route with the stale label x, which it advertises to the controllers and in turn gets advertised to the source agent. Since the agent does not have a label x, it marks the NH as invalid and the VM loses connectivity.

Fix in the code:

Add a route with correct label and sequence number from the route update for BGP peer path - https://gerrit.tungsten.io/r/c/tungstenfabric/tf-controller/+/64852/1/src/vnsw/agent/controller/controller_peer.cc
Update the sequence number in BGP peer path updates the sequence number in agent route update to control node - https://gerrit.tungsten.io/r/c/tungstenfabric/tf-controller/+/64852/1/src/vnsw/agent/oper/agent_route.cc

Solution:

Disable XMPP helper in 19xx and 20xx releases to prevent this problem.

Or

Upgrade to 2011L2 for the permanent fix.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search