
214
routing table and a VR, but not across VRs. The switch supports route leaking only through static routes. The
switch does not support inter- VRF packet forwarding by connecting a wire between ports belonging to
different VR instances
7.9.2.
Adding Leaked Routes
Connected routes in one router that are leaked into another VR are referred to as leaked host routes. To
add leaked host routes, specify the next-hop interface but not the next-hop address. For leaked routes that
are not directly connected (static or dynamic routes), the next-hop address must to be specified in addition
to the next- hop interface. The next-hop interface is specified to identify the outgoing VR interface. If the
next-hop interface is unspecified, the route is treated as an internal route to the VR.
Internal routes within a router that are added with only a next-hop interface value (and no next-hop
address value) are supported only over unnumbered interfaces.
7.9.3.
Using Leaked Routes
The line rate forwarding continues to work the same for leaked route destinations in a router as for the
internal routes in the router. For bidirectional traffic to work between VRs using leaked routes, the
corresponding routes should be leaked between the VRs.
7.9.4.
CPU-Originated Traffic
For CPU-originated traffic from different applications (ping, traceroute, syslog, IP helper) that may use the
leaked routes to access the destination or shared service, the following conditions are required to ensure
proper operation:
1.
The source IP address in the originated packets must be mentioned with the source IP option (e.g., ping
with source option).
2.
In the router where the CPU traffic originates, the route for the source option matching network must
be leaked into the virtual router where the next-hop belongs so that the return traffic is directed to the
traffic- originating router
7.9.5.
VRF Features Support
Table 7-11 lists features and details how they are supported by VRF Lite:
Feature
VRF Support
Network Management
Network management includes the ability to manage the switch via CLI and
SNMP. Network management is supported only via the default router.
Administrators cannot log into the switch and manage the switch via one of the IP
addresses on the non-default VR.
The Service Port and the Network Port are always associated with the default
router, so the customers are able to manage the switch via these interfaces.
Summary of Contents for QuantaMesh QNOS5
Page 1: ...QuantaMesh Ethernet Switch Configuration Guide QNOS5 NOS Platform ...
Page 209: ...209 Table 7 8 IPv6 Neighbor Discovery Settings ...
Page 226: ...226 Table 8 2 L3 Multicast Defaults ...
Page 254: ...254 Appendix A Term and Acronyms Table 9 5 Terms and Acronyms ...