Adds a static route to the specified routing table.
| ipNetmask | Specifies an IP address/mask length. |
| ip_addr | Specifies an IP address. |
| mask | Specifies a subnet mask. |
| gateway | Specifies a gateway IP address. |
| bfd | Enables Bidirectional Forwarding Detection (BFD) protection for the route. |
| metric | Specifies a cost metric. |
| multicast | Adds the specified route to the multicast routing table. |
| multicast-only | Adds the specified route to the multicast routing table. This option is provided for backward compatibility with releases prior to ExtremeXOS release 12.1. |
| unicast | Adds the specified route to the unicast routing table. |
| unicast-only | Adds the specified route to the unicast routing table. This option is provided for backward compatibility with releases prior to ExtremeXOS Release 12.1. |
| vlan | Specifies the egress VLAN name used for an Inter-VR route. |
| vrname | Specifies the VR or VRF to which the route is added. |
If you do not specify a VR or VRF, the current VR context is used.
Use a mask value of 255.255.255.255 to indicate a host entry.
The gateway address must be present on a directly attached subnet, or the following message appears:
ERROR: Gateway is not on directly attached subnet
The gateway address must be different from loop back address or local addresses, or the following message appears:
ERROR: Gateway cannot be local or loop back address
Note
Although dynamic unicast routes can be captured in the multicast routing table, unicast static routes cannot be captured in the multicast routing table. To create a static route for the multicast routing table, you must specify the multicast option.This command can add BFD protection to a link only when the BFD client at each end of the link is enabled (see the configure iproute add (IPv4) command).
Once the BFD session is established, the operational status of the route reflects the operational status of the BFD session.
To remove BFD protection for a static route, enter this command without the BFD keyword.
Beginning in ExtremeXOS 15.6, the egress VLAN name may now be a VLAN belonging to a VR different from the VR of the static route itself. When the VRs differ, Inter-VR routing of hardware and software forwarded packets is performed.
The following example adds a static address to the routing table in the current VR context:
configure iproute add 10.1.1.0/24 123.45.67.1
In the following example of an Inter-VR routing scenario, VLAN v1 belongs to VR vr1, and VLAN v2 belongs to VR vr2. The final two commands add Inter-VR routes between VR vr1 and VR vr2. The resulting behavior is that IPv4 unicast packets originating in VR vr1, and a destination IP address in subnet 52.0.0.0/8, are forwarded to gateway 20.1.1.2 belonging to VLAN v2 in VR vr2 per the first Inter-VR route. Reverse packets originating in VR vr2 with a destination IP address in subnet 51.0.0.0/8 are forwarded to gateway 10.1.1.2 belonging to VLAN v1 in VR vr1 per the second Inter-VR route. The vr vr_name of the static route command refers to which VR's route table the route is added.
create vr "vr1" create vr "vr2" create vlan "v1" vr vr1 create vlan "v2" vr vr2 configure vlan v1 tag 10 configure vlan v2 tag 20 configure vlan v1 add ports 1 tagged configure vlan v2 add ports 2 tagged configure vlan v1 ipaddress 10.1.1.1/8 configure vlan v2 ipaddress 20.1.1.1/8 enable ipforwarding vlan v1 enable ipforwarding vlan v2 configure iproute add 52.0.0.0/8 20.1.1.2 vlan v2 vr vr1 configure iproute add 51.0.0.0/8 10.1.1.2 vlan v1 vr vr2
The Inter-VR routing example above is for packets routed through a gateway to a remote subnet. Inter-VR routing can also be accomplished to/from a host adjacent to the switch, such as hosts in the switch‘s IPv4 ARP cache, by adding a /32 host route. In the example network above, to have packets from VR1 route to a host/server in VR2 directly on the 20.1.1.1/8 subnet, such as 20.1.1.66, the following CLI command can be used by specifying 20.1.1.66/32:
configure iproute add 20.1.1.66/32 20.1.1.66 vlan v2 vr vr1
This command was first available in ExtremeXOS 10.1.
Beginning in ExtremeXOS 15.6, the egress VLAN name may now be a VLAN belonging to a VR different from the VR of the static route itself.
This command is available on all platforms with Layer 3 support.
Print
this page
Email this topic
Feedback
View PDF
Download EPUB