The OCID of the compartment the DRG is in. The DRG route table is always in the same compartment as the DRG.
Defined tags for this resource. Each key is predefined and scoped to a namespace. Example: {@code {"foo-namespace": {"bar-key": "value"}}}
A user-friendly name. Does not have to be unique, and it's changeable. Avoid entering confidential information.
The OCID of the DRG the DRG that contains this route table.
Simple key-value pair that is applied without any predefined name, type or scope. Exists for cross-compatibility only. Example: {@code {"bar-key": "value"}}
The OCID of the DRG route table.
The OCID of the import route distribution used to specify how incoming route advertisements from referenced attachments are inserted into the DRG route table.
If you want traffic to be routed using ECMP across your virtual circuits or IPSec tunnels to your on-premises network, enable ECMP on the DRG route table to which these attachments import routes.
The DRG route table's current state.
The date and time the DRG route table was created, in the format defined by RFC3339.
Example: {@code 2016-08-25T21:10:29.600Z}
All routing inside the DRG is driven by the contents of DRG route tables. DRG route tables contain rules which route packets to a particular network destination, represented as a DRG attachment. The routing decision for a packet entering a DRG is determined by the rules in the DRG route table assigned to the attachment-of-entry.
Each DRG attachment can inject routes in any DRG route table, provided there is a statement corresponding to the attachment in the route table's {@code importDrgRouteDistribution}. You can also insert static routes into the DRG route tables.
The DRG route table is always in the same compartment as the DRG. There must always be a default DRG route table for each attachment type.