Status in source: current.
Names: rtmMjSafi
Technical details
{
"smi_kind": "OBJECT-TYPE",
"definition": [
"rtmMjSafi",
"OBJECT-TYPE",
"SYNTAX",
"InetSubAddressType",
"MAX-ACCESS",
"read-create",
"STATUS",
"current",
"DESCRIPTION",
"\"Sub-address family indicating the type of routes that can be queried on the join. This field is only relevant for joins to BGP or PIM. Allowed values are none, unicast and multicast. An example use is where unicast and multicast topologies are different. In this scenario the system requires separate RTM instances to hold the unicast and multicast routing tables. In this case, ARI queries from PIM relate to the multicast routing table, but ARI queries from BGP could be either for the unicast or multicast routing table. If only a single sub-address family need be supported then this can be left with the default value of none. The value of this field must not be changed while the row status of this MIB is AMB_ROW_STATUS_ACTIVE and the admin status is AMB_ADMIN_STATUS_UP.\"",
"DEFVAL",
"{",
"none",
"}",
"::=",
"{",
"rtmMjEntry",
"9",
"}"
],
"syntax_tree": [
[
"row",
"InetSubAddressType"
],
null,
[
"MaxAccessPart",
"read-create"
],
[
"Status",
"current"
],
[
"DESCRIPTION",
"Sub-address family indicating the type of routes that can be queried on the join. This field is only relevant for joins to BGP or PIM. Allowed values are none, unicast and multicast. An example use is where unicast and multicast topologies are different. In this scenario the system requires separate RTM instances to hold the unicast and multicast routing tables. In this case, ARI queries from PIM relate to the multicast routing table, but ARI queries from BGP could be either for the unicast or multicast routing table. If only a single sub-address family need be supported then this can be left with the default value of none. The value of this field must not be changed while the row status of this MIB is AMB_ROW_STATUS_ACTIVE and the admin status is AMB_ADMIN_STATUS_UP."
],
null,
null,
null,
[
"DEFVAL",
"none"
]
]
}