WIP : Definitions for types and entities in the routing module #211
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fredi-raspall
force-pushed
the
fredi/routing
branch
4 times, most recently
from
7167a05 to
d7f9fa7
Compare
Signed-off-by: Fredi Raspall <[email protected]>
We may centralize error definitions here. Signed-off-by: Fredi Raspall <[email protected]>
Fredi-raspall
force-pushed
the
fredi/routing
branch
5 times, most recently
from
c9257ef to
728e03e
Compare
This module models the state used to represent interfaces in
some interface table (Iftable).
Interfaces:
- are identified by an ifindex (u32).
- have a mandatory name, and optional description
- have operational and administrative state, that should mirror
the actual state of real interfaces (e.g. kernel devices)
- have type-specific information (e.g. vlan tag in 802.1q)
- can have an arbitrary number of IPv4 and IPv6 addresses.
- can be attached / detached to / from a VRF.
Interface attachment is an exclusive membership property:
an interface may be attached to only one VRF. In this commit,
attachment is represented as an optional Arc<> to a dummy VRF
object type (to be re-defined). Once the VRFs are defined,
the Option<> wrapping the Arc<VRF> may be removed if we always
assume the presence of a default VRF to which interfaces are
implicitly attached by default.
Concurrency: not addressed yet. The IfTable may be wrapped
with a RwLock, since it may be modified by some mgmt interface
(to create interfaces), or the interface manager, and by the RPC
with the control-plane, to add/remove addresses.
The Arc<Vrf> is meant to avoid the need to perform a lookup
in order to access the VRF that an interface is attached to.
However, the access to Interfaces (other than from the IfTable)
is not yet addressed.
Signed-off-by: Fredi Raspall <[email protected]>
Iptrie will be used to implement a routing table. Ipnet provides definitions for Ip prefixes that help some conversions. Signed-off-by: Fredi Raspall <[email protected]>
Iptrie defines trait IpPrefix and types Ipv4Prefix and Ipv6Prefix, but no common type to represent both types of prefixes, as the trie implementations use either one type or another. This module defines a single type (enum) 'Prefix' valid for both Ipv4 and Ipv6 prefixes so that: - we don't depend (too much) on Ipv4Prefix and Ipv6Prefix - we can define a version-neutral APIs based on 'Prefix' Signed-off-by: Fredi Raspall <[email protected]>
The Encapsulation type represents a packet encapsulation and will be part of a next-hop. Signed-off-by: Fredi Raspall <[email protected]>
The RmacStore is the entity that stores the router macs associated with remote SVIs. For a given VTEP address and Vni, it stores a MAC address. This table is needed in order to set the destination MAC of the inner frame encapsulated in VxLAN. Signed-off-by: Fredi Raspall <[email protected]>
Add minimal definitions for adjacency and adjacency table. We'll use the adjacency table to map directly connected next-hops to MAC addresses for the L2 dst MAC re-write. This table should play the role of an ARP/neigh cache, and we may populate it from the kernel neighbor system, or via netlink. Signed-off-by: Fredi Raspall <[email protected]>
The next-hop module implements a next-hop store of shared next-hop
objects. The model is as follows.
- next-hop objects (type Nhop) are identified by a key (NhopKey),
which contains the information that uniquely identifies a next-hop.
The NhopKey object is defined because the next-hop must have
interior mutability and having a specific type simplifies the code.
- next-hop objects are shared in that many routes may refer to the
same next-hops. This is to be exploited in two ways.
1) by storing next-hop information once, thereby saving memory.
2) since next-hops are shared, their resolution may be greatly
expedited. E.g. if 10K routes share the same next-hop, a
single resolution is needed (instead of 10k).
- sharing is accomplished with multiple ownership, storing Nhops
wrapped into an Rc<> that gets cloned (refcounted) by every
route using it.
- The speedup/caching in resolution, which may not be initially
exploited as the resolution itself is external to this module,
may be achieved by allowing Nhops to have 'resolving' references
to other next-hops such that, once a next-hop is resolved, any
other next-hop referring to (resolving via) it may be
automatically resolved. This way, to resolve 10K routes, a single
next-hop may be resolved and, to resolve that single next-hop,
a small update to its references may produce the same effect
instead of N LPM operations. None of this is shown in this
commit but can be inferred.
Signed-off-by: Fredi Raspall <[email protected]>
Signed-off-by: Fredi Raspall <[email protected]>
Signed-off-by: Fredi Raspall <[email protected]>
Fredi-raspall
force-pushed
the
fredi/routing
branch
from
c337163 to
53b64f5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is super WIP and lacks the routing part (coming soon).
Opening this PR to get early feedback as suggested by @mvachhar and because there's some overlap with the work of the interface manager w.r.t modeling interfaces and neigh cache. @daniel-noland let's go over this at some point.
I'll be massively squashing fixes....