Split VRF Identifier for Unicast RPF Validation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current network devices supporting multiple VRFs and unicast RPF face challenges in enforcing RPF to drop source addresses not from the internal network, as route leaking across VRF instances contaminates routing tables with both internal and external routes, lacking a method to validate source addresses effectively.
Innovation Solution
The network device is configured to perform split VRF operations by assigning distinct RPF and forwarding VRF identifiers to each interface, enabling the enforcement of unicast RPF by performing separate lookups for source and forwarding VRF identifiers within the packet processing pipeline, ensuring valid source addresses are from the internal network.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If route leaking is performed across multiple VRF instances to enable RPF validation, then RPF can validate source addresses, but the routing table becomes contaminated with both internal and external routes making it impossible to enforce RPF to drop non-internal source addresses
Solution Approach 1:
The patent divides the routing table into separate VRF-specific routing tables. Each VRF instance maintains its own isolated routing table, preventing route leaking between VRFs. This segmentation allows RPF to validate source addresses against the appropriate VRF-specific routing table without contamination from other VRF routes, resolving the contradiction between RPF validation capability and routing table cleanliness.
2Adaptability or versatility
If multiple VRF instances are supported on the same network device, then network virtualization is enabled, but enforcing RPF to drop non-internal source addresses becomes challenging due to route leaking
Solution Approach 1:
The patent segments the routing infrastructure into multiple isolated VRF instances, each with its own routing table. This segmentation enables network virtualization while maintaining strict boundaries that prevent route leaking. RPF can then reliably validate source addresses within each VRF context without interference from other VRF routes, simultaneously achieving both network virtualization and reliable source address validation.
Solution Approach 2:
The patent introduces VRF-specific routing tables as intermediaries between the RPF validation process and the routing information. These intermediary routing tables provide a clean, isolated view of routes specific to each VRF instance, allowing RPF to validate source addresses accurately without being affected by routes from other VRFs, thus enabling both multi-VRF support and reliable source validation.
3Device complexity
If a single routing table is used across multiple VRF instances, then device complexity is reduced, but RPF cannot distinguish between internal and external routes for proper source address validation
Solution Approach 1:
The patent segments the single routing table into multiple VRF-specific routing tables. This segmentation increases the structural complexity of the routing system but enables RPF to accurately validate source addresses by referencing only the relevant VRF-specific routes. The precision gain in source address validation outweighs the moderate increase in routing table structure complexity.
Solution Approach 2:
The patent applies local quality by creating routing tables with properties specific to each VRF instance. Each VRF routing table contains only the routes relevant to that particular VRF, providing localized routing information. This allows RPF to perform accurate source address validation within each VRF context while maintaining clear distinction between internal and external routes specific to each virtual network.
Data Source
AI summary
A network device or a system can be configured to support split virtual routing and forwarding (VRF) for unicast reverse path forwarding (RPF). A method is provided that includes receiving a data packet, performing VRF mapping lookup to identify a forwarding VRF identifier and a source VRF identifier, storing at least the source VRF identifier and a VRF profile as metadata, passing the packet through one or more stages in a packet processing pipeline, extracting the source VRF identifier from the metadata, performing RPF lookup based on the extracted source VRF identifier or the forwarding VRF identifier based on the extracted VRF profile from the metadata and a source address of the packet, selectively dropping the packet, performing forwarding lookup based on the forwarding VRF identifier and a destination address of the packet, and selectively forwarding the packet.