Last Modified: Nov 07, 2022
Known Affected Versions:
11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4
12.1.0, 11.6.1, 11.5.4 HF2
Opened: Nov 12, 2015 Severity: 3-Major Related Article:
Related Article: K14147369
TMM might use a link-local IPv6 address when attempting to reach an external global address for traffic generated from TMM (for example, dns resolver, sideband connections, etc.).
Traffic might fail as its egresses from a link-local address instead of a global address.
- ECMP IPv6 routes to a remote destination where the next hop is a link local address. Typically this occurs with dynamic routing. - Have configured a virtual server that generates traffic from TMM (for example, dns resolver, sideband connections, etc.).
It might be possible to work around if the dynamic routing peer can announce the route from a global address instead of a link local. Use of static routes might also work around the issue.
TMM now uses the correct IPv6 global address when generating traffic to a remote address using ECMP routes via link-local next-hops.