Configuring Layer 3 Features

Configuring vRouter Services

A Virtual Router (vRouter) is an important part of fabric functionality. For example, for a VLAN to communicate with other VLANs, or networks external to the fabric, it may need a vRouter that spans the internal and the external network. vRouter commands can only be executed at the fabric level by the fabric administrator.

 

Informational Note:

 For switches with ONVL, the only available VNET is a global VNET created when a fabric is created for the first time. Use tab complete in the CLI to display the VNET and continue the configuration. However, some white box switches support multiple VNETs. Please refer to the Release Notes for the supported platforms.

Routing protocols essentially work the same way on virtual routers as physical routers. Detailed information about routing protocols is not covered in this overview.

Configuring BGP on a vRouter

Border Gateway Protocol (BGP) is a path-vector protocol and is the most commonly used routing protocol on the Internet. It advertises the paths required to reach a certain destination. BGP is also a protocol that sits on top of TCP, and is simpler than Open Shortest Path First (OSPF). In Figure 1  Configuring BGP for Two VLANs, you want network traffic from the source host to reach the destination host. But when different VLANs are configured, the source host traffic is not aware of the route between the source host and the destination host. However, there is a VLAN that spans VLAN 33 and VLAN 55. You solve this problem by configuring BGP in the same Autonomous System (AS) 100 that sends traffic over VLAN 35. This allows the source host to learn the route to the destination host.

Using a loopback address for peering is useful when there are multiple paths between the BGP peers which would otherwise tear down the BGP session if the physical interface used for establishing the session goes down. It also allows the vRouters running BGP with multiple links between them to load balance over the available paths.

Figure 1:

BGP-topology.png

 Configuring BGP for Two VLANs

This example assumes that you have two VLANs, VLAN33 and VLAN55. Also, that you have added ports to the configuration.

Begin by configuring vRouter1, a software vRouter, on VLAN 33 with the BGP information:

CLI network-admin@switch > vrouter-create name vrouter1  fabricname-global router-type hardware bgp-as 100 bgp-redist-connected-metric none

Additional BGP parameters include the following:

Add the IP addresses and VLANs:

CLI network-admin@switch > vrouter-interface-add vrouter-name vrouter1 ip 10.16.35.33/24 vlan 35

CLI network-admin@switch > vrouter-interface-add vrouter-name vrouter1 ip 10.16.33.1/24 vlan 33

Add the BGP information:

CLI network-admin@switch > vrouter-bgp-add vrouter-name vrouter1 neighbor 10.16.35.55 remote-as 100

CLI network-admin@switch > vrouter-bgp-add vrouter-name vrouter1 network 10.16.33.0/24

Display the interface information for vrouter1:

CLI network-admin@switch > vrouter-interface-show format all layout vertical

vrouter-name:   vrouter1

nic:            eth1.33

ip:             10.9.100.100/16

assignment:     static

mac:            66:0e:94:30:c6:92

vlan:           33

vxlan:          0

if:             data

alias-on:       

exclusive:      no

nic-config:     enable

nic-state:      up

secondary-macs:

vrouter-name:   vrouter1

nic:            eth2.33

ip:             192.168.42.11/24

assignment:     static

mac:            66:0e:94:30:25:5e

vlan:           33

vxlan:          0

if:             data

alias-on:       

exclusive:      no

nic-config:     enable

nic-state:      up

secondary-macs:

 

If you want to filter IP hosts, you can add prefix lists to the BGP configuration. See Configuring Prefix Lists for BGP and OSPF.

Then, configure vRouter2 on VLAN 55:

CLI network-admin@switch > vrouter-create name vrouter2  fabricname-global router-type hardware bgp-as 100 bgp-redist-connected-metric none

Add the IP addresses and VLANs:

CLI network-admin@switch > vrouter-interface-add vrouter-name vrouter2 ip 10.16.35.55/24 vlan 35

CLI network-admin@switch > vrouter-interface-add vrouter-name vrouter2 ip 10.16.55.1/24 vlan 55

Then add the BGP information:

CLI network-admin@switch > vrouter-bgp-add vrouter-name vrouter2 neighbor 10.16.35.33 remote-as 100

CLI network-admin@switch > vrouter-bgp-add vrouter-name vrouter2 network 10.16.55.0/24

And finally, add the loopback address:

CLI network-admin@switch > vrouter-loopback-interface-add vrouter-name vrouter1 index 5 ip 1.1.1.1

The index value is a number that uniquely identifies the vRouter in the AS.

Display the vRouter BGP configuration:

CLI network-admin@switch > vrouter-bgp-show format all layout vertical

vrouter-name:           vrouter33

ip:                     10.16.35.55

neighbor:               10.16.35.55

remote-as:              100

next-hop-self:          no

route-reflector-client: no

override-capability:    no

soft-reconfig-inbound:  no

max-prefix-warn-only:   no

vrouter-name:           vrouter33

ip:                     10.16.33.0

network:                10.16.33.0/24

vrouter-name:           vrouter55

ip:                     10.16.35.33

neighbor:               10.16.35.33

remote-as:              100

next-hop-self:          no

route-reflector-client: no

override-capability:    no

soft-reconfig-inbound:  no

max-prefix-warn-only:   no

vrouter-name:           vrouter55

ip:                     10.16.55.0

network:                10.16.55.0/24

 

To reset BGP neighbors, use the vrouter-bgp-neighbor-reset command.

To display BGP neighbors, use the vrouter-bgp-neighbor-show command.

CLI network-admin@switch > vrouter-bgp-neighbor-show

vrouter-name: vrouter1

neighbor:     10.9.100.201

ver:          4

remote-as:    100

msg_rcvd:     11

msg_sent:     19

tblver:       0

inQ:          0

outQ:         0

up/down:      00:54:04

state/pfxrcd: Connect

vrouter-name: vrouter2

neighbor:     10.9.100.101

ver:          4

remote-as:    100

msg_rcvd:     12

msg_sent:     18

tblver:       0

inQ:          0

outQ:         0

up/down:      00:53:37

state/pfxrcd: Connect

Additional BGP Parameters

There are additional BGP parameters that you can use to optimize your BGP network. Add any of the following parameters:

Support for BGP SNMP MIBs

You now enable or disable SNMP MIBs for BGP configurations by using the command, vrouter-create, or vrouter-modify:

CLI network-admin@switch > vrouter-create name-string bgp-snmp|no-bgp-snmp bgp-snmp-notification|no-bgp-snmp-notification

Support for AS and AS Prepending and BGP

You can prepend one or more autonomous system (AS) numbers at the beginning of an AS path. The AS numbers are added at the beginning of the path after the actual AS number from which the route originates has been added to the path. Prepending an AS path makes a shorter AS path look longer and therefore less preferable to BGP.

The BGP best path algorithm determines how the best path to an autonomous system (AS) is selected. The AS path length determines the best path when all of the following conditions are met:

There are multiple potential routes to an AS.

When these conditions are met, the AS path length is used as the tie breaker in the best path algorithm. When two or more routes exist to reach a particular prefix, BGP prefers the route with the shortest AS Path length.

If you have multi-homing to one or more service providers, you may prefer for incoming traffic take a particular path to reach your network. Perhaps you have two connections, but one costs less than the other. Or you might have one fast connection and another, much slower connection that you only want to use as a backup if your primary connection is down. AS path prepending is an easy method that you can use to influence inbound routing to your AS.

Netvisor OS has new parameters for the vrouter-route-map-* commands:

vrouter-route-map-add

as-path-prepend integer

Specify a value between 1 and 4,294,967,295.

as-path-prepend-last-as integer

Specify a value between 1 and 10.

as-path-exclude integer

Specify a value between 1 and 4,294,967,295.

vrouter-route-map-show

as-path-prepend integer

Displays a value between 1 and 4,294,967,295.

as-path-prepend-last-as integer

Displays a value between 1 and 10.

as-path-exclude integer

Displays a value between 1 and 4,294,967,295.

Bidirectional Forwarding Detection Support for IPv6 BGP Neighbor and IPv6 Static Routes

This feature adds bidirectional forwarding detection for IPv6 BGP neighbor and provides support for IPv6 BGP NBR reachability detection by using BFD protocol. When a BFD session goes from UP to DOWN, BFD informs BGP to bring the neighbor (NBR) down, until BFD returns to an UP state.

You create the BFD session by adding the bfd parameter to the vRouter configuration using the bfd parameter for the command, vrouter-bgp-modify. IPv6 BFD sessions for BGP NBRs are hosted in Netvisor. The BFD session is started when you add the bfd parameter the BGP vRouter configuration.

vrouter-bgp-neighbor-show

vrouter-name      neighbor    ver remote-as msg_rcvd msg_sent up/down  state/pfxrcd

------------      ----------- --- --------- -------- -------- ------ --------------

vr10              2002:100::2 4   51000     189      193             00:00:49 0

 

multi-protocol

--------------

ipv6-unicast

 

Netvisor supports IPv6 static route reachability detection using BFD protocol. Add IPv6 BFD session by specifying two end point IPv6 addresses, a source IPv6 address and a destination IPv6 address. The source IPv6 address must be a known local IPv 6 address. When a BFD session is up, Netvisor assesses all the IPv6 static routes configured with a gateway or a BFD destination IPv6 address matching the destination IPv6 address of the BFD session. When a match is found, this static route is installed in Routing Information Database (RIB) and Forwarding Information Database (FIB).

vrouter-static-bfd-show

vrouter-name src-ip                    dst-ip                    type

------------ ------------------------- ------------------------- ----------

vr10         2006:100::2               2002:100::2               multi-hop

Support for Border Gateway Protocol (BGP) Communities

A BGP community is a group of prefixes that share some common property and can be configured with the BGP community attribute. The BGP Community attribute is an optional transitive attribute of variable length. The attribute consists of a set of four octet values that specify a community. The community attribute values are encoded with an Autonomous System (AS) number in the first two octets, with the remaining two octets defined by the AS. A prefix can have more than one community attribute. A BGP speaker that sees multiple community attributes in a prefix can act based on one, some or all the attributes. A router has the option to add or modify a community attribute before the router passes the attribute on to other peers.

The local preference attribute is an indication to the AS which path is preferred in order to reach a certain network. When there are multiple paths to the same destination, the path with the higher preference is preferred (the default value of the local preference attribute is 100).

Common Community Attributes

For example to set the community attribute, no-export, to all route prefixes matching prefix subnet100, use the following syntax:

vrouter-route-map-add vrouter-name vr1 name rmap1 seq 10 action permit match-prefix subnet100 community-attribute no-export

 

To set the community attribute, 65002:200 to all route prefixes matching prefix subnet100, use the following syntax:

vrouter-route-map-add vrouter-name vr1 name peer vr2 action permit seq 20 match-prefix subnet99 community-attribute-generic 65002:200

Community Lists

BGP community list is a user defined BGP communities attribute list. The BGP community list can be used for matching or manipulating BGP communities attribute in updates. This is used on the receive side of the BGP updates to match what is set in the received updates. Community lists can be used in route-map with match-community keyword to apply any policy on the receive side.

To set the community list permitting the community value 300 for AS 65002, use the following syntax:

vrouter-community-list-add vrouter-name vr2 style standard name clist300 action permit community-attribute 65002:300

 

To set an expanded community list that denies updates with community values 1 through 99 in autonomous System 50000, use the following syntax:

vrouter-community-list-add vrouter-name vr1 style expanded name c199 action deny community-attribute 50000:[0-9][0-9]

The Netvisor commands for vrouter-route-maps-* support additional parameters for BGP communities:

vrouter-route-map-add

match-community match-community-string

Specify the community string to match. (BGP only)

exact-match|no-exact-match

Specify if the community string is an exact match or not. (BGP only)

community-attribute-generic community-attribute-generic-string

Specify a generic community attribute such as AA:NN. (BGP only)

additive|no-additive

Specify if a given community is appended to existing communities value.

comm-list-del vrouter community-list name 

Specify if you want to remove community values from BGP community attributes.

New commands support creating BGP Communities:

vrouter-community-list-add

vrouter-name name-string

Specify a vRouter to add the community list.

Add the following community list parameters:

style standard|expanded

Specify the style of the community list.

name name-string

Specify a name for the community list.

action permit|deny

Specify the action for the community list.

community-attribute community-attribute-string

Specify the community attribute.

vrouter-community-list-remove

vrouter-name name-string

Specify a vRouter to remove the community list.

Add the following community list parameters:

style standard|expanded

Specify the style of the community list.

name name-string

Specify a name for the community list.

action permit|deny

Specify the action for the community list.

community-attribute community-attribute-string

Specify the community attribute.

vrouter-community-list-show

vrouter-name name-string

Displays the vRouter name.

Add the following community list parameters:

style standard|expanded

Displays the style of the community list.

name name-string

Displays a name for the community list.

action permit|deny

Displays the action for the community list.

community-attribute community-attribute-string

Displays the community attribute.

 

Configuring Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) is a robust link-state interior gateway protocol (IGP). It uses the concept of Areas which allows further segmentation on the network.

OSPF uses link-state information to make routing decisions, and make route calculations using the shortest path first (SPF) algorithm. Each vRouter configured for OSPF floods link-state advertisements throughout the area that contains information about the interfaces attached to the router and routing metrics.

You can add more configuration options, such as hello intervals, for OSPF using the vrouter-interface-config commands. In addition, you can add stub or not-so-stubby areas to the OSPF configuration.

You can also manually change the OSPF cost for the configuration. Cost is the metric used by OSPF to judge the feasibility of a path. If you specify 0 as the cost, the vRouter automatically calculates the cost based on the bandwidth of the interface.


 

Informational Note:   For switches with ONVL, the only available VNET is a global VNET created when a fabric is created for the first time. Use tab complete in the CLI to display the VNET and continue the configuration.

In this example, you configure OSPF for two vRouters with an area of 5. The network has the following configuration:

Figure 2: OSPF

OSPF-topology.png

1. First, create the vRouter for 33, vrouter1.

CLI network-admin@switch > vrouter-create name vrouter1  fabricname-global router-type hardware

2. Add vRouter interfaces to the vRouter:

CLI network-admin@switch > vrouter-interface-add vrouter-name vrouter1 ip 10.16.35.1 netmask 24 vlan 35 if data nic-enable

CLI network-admin@switch > vrouter-interface-add vrouter-name vrouter1 ip 10.16.55.1 netmask 24 vlan 55 if data nic-enable

3. Add the subnets, 10.16.35.0/24 and 10.16.45.0/24, to VLAN33 with the area 0:

CLI network-admin@switch > vrouter-ospf-add vrouter-name vrouter1 network 10.16.35.0/24 ospf-area 0

4. Add the second IP address with the area 0.

CLI network-admin@switch > vrouter-ospf-add vrouter-name vrouter1 network 10.16.55.0/24 ospf-area 0

5. Add interfaces for OSPF hello intervals of 30 seconds:

CLI network-admin@switch > vrouter-interface-config-add name vrouter1 nic eth0.35 ospf-hello-interval 30 ospf-cost 0

CLI network-admin@switch > vrouter-interface-config-add name vrouter1 nic eth0.55 ospf-hello-interval 30 ospf-cost 0

If you specify 0 as the cost value, the vRouter calculates the OSPF cost automatically based on the bandwidth of the interface.

When you modify the OSPF hello interval, the ospf-dead-interval is automatically reset to 4 times the hello interval.

 

6. Display the configuration by using the vrouter-ospf-show command:

CLI network-admin@switch > vrouter-ospf-show layout vertical

vrouter-name:            vrouter1

network:                 10.16.35.0

netmask:                 24

ospf-area:               0

vrouter-name:            vrouter1

network:                 10.16.55.0

netmask:                 24

ospf-area:               0

stub-area:               11

stub-type:               stub

ospf-hello-interval:     30

metric:                  34

 

The metric value can reflect the cost of routes advertised as OSPF routes. It may also reflect the cost of routes advertised with other protocols.

Display Default Timers for OSPF Configurations

Netvisor now allows you to display default timers for OSPF configurations. To add a timer or modify an existing timer, use the following commands:

vrouter-interface-config-add

ospf-retransmit-interval seconds

Specify the OSPF retransmit interval from 3 to 65535 seconds. The default is 5 seconds. (IPv4 orIPv6)

 

vrouter-interface-config-modify

ospf-retransmit-interval seconds

Specify the OSPF retransmit interval from 3 to 65535 seconds. The default is 5 seconds. (IPv4 orIPv6)

 

A new command displays the OSPF configuration for an interface:

vrouter-ospf-interface-show

 

i

vrouter-name name-string

Displays the name of the vRouter.

Specify any of the following optional OSPF parameters:

nic vrouter interface nic

Displays the name of the vNIC.

nic-state down|up

Displays the vNIC state.

l3-port l3-port-number

Displays the Layer 3 port numbers.

ip ip-address

Displays the IPv4 address of the interface.

netmask netmask

Displays the netmask of the IPv6 address.

broadcast ip-address

Displays the broadcast IP address.

area ip-address

Displays the area ID for the interface in IPv4 format.

mtu mtu-number

Displays MTU for the interface.

mtu-mismatch-detection|
no-mtu-mismatch-detection

Displays if MTU mismatch detection is configured.

router-id ip-address

Displays the router ID as an IP address.

network-type point-to-point|broadcast|loopback

Displays the OSPF network type.

state down|loopback|waiting|point-to-point|dr-other|backup|dr

Displays OSPF interface state.

dr-id ip-address

Displays the designated router ID.

dr-ip ip-address

Displays the designated router IP address.

bdr-id ip-address

Displays the backup designated router ID.

bdr-ip ip-address

Displays the designated router IP address.

priority priority-number

Displays the priority.

cost cost-number

Displays the cost.

hello hello-number(s)

Displays the hello-interval in seconds.

dead dead-number(s)

Displays the dead time in seconds.

retransmit retransmit-number(s)

Displays the retransmit interval time in seconds.

hello-due hello-due-string

Displays the hello due in.

neighbor neighbor-number

Displays the neighbor count.

adjacent adjacent-number

Displays the adjacent number count.

vrouter-ospf6-interface-show

i

vrouter-name name-string

Displays the name of the vRouter.

Specify any of the following optional OSPF parameters:

nic vrouter interface nic

Displays the name of the vNIC.

nic-state down|up

Displays the vNIC state.

l3-port l3-port-number

Displays the Layer 3 port numbers.

link-local ip-address

Displays the IPv6 link-local IP address.

ip6 ip-address

Displays the IPv6 address of the interface.

netmask-ip6 netmask

Displays the netmask of the IP address.

area ip-address

Displays the area ID for the interface in IPv4 format.

mtu mtu-number

Displays MTU for the interface.

mtu-mismatch-detection|
no-mtu-mismatch-detection

Displays if MTU mismatch detection is configured.

state down|loopback|waiting|point-to-
point|dr-other|backup|dr

Displays OSPF interface state.

dr-id ip-address

Displays the designated router ID.

bdr-id ip-address

Displays the backup designated router ID.

priority priority-number

Displays the priority.

cost cost-number

Displays the cost.

hello hello-number(s)

Displays the hello-interval in seconds.

dead dead-number(s)

Displays the dead time in seconds.

retransmit retransmit-number(s)

Displays the retransmit interval time in seconds.

if-scoped-lsa if-scoped-lsa-number

Displays the number of interface LSAs scoped for the area.

ls-update ls-update-number

Displays the number of pending LSAs for LSUpdate.

ls-ack ls-ack-number 

Displays the number of pending LSAs for LSAck.

 

Adding Areas and Prefix Lists to OSPF

You can now configure OSPF areas as a stub area, stub-no-summary area, or a not so stubby area (NSSA). Stub areas see detailed routing information from other areas, but only summary information about networks outside of the AS. Stub-no-summary areas summarize external routes and routes from other areas. Routers in this type of area only see routing information local to their area. Not so stubby areas (NSSA) connects to the external network by introducing a Link State Advertisement (LSA) used within the area to carry external routes originating with boundary routers connected to this area.

To add a stub area to vRouter, vrouter-ospf, with area 100, use the following command:

CLI network-admin@switch > vrouter-ospf-area-add vrouter-name vrouter-ospf area 100 stub-type stub

The parameter, stub-type, is a required parameter.

In addition, you can add prefix lists to filter host IP addresses. To add prefix lists to OSPF areas, see Configuring Prefix Lists for BGP and OSPF.

BFD Support for OSPF Fault Direction 

Bidirectional Forwarding Detection (BFD) can now be used for OSPF fault detection. This feature provides fast failure detection when there is an intermediate device between two non-adjacent OSPF neighbors. BFD provides fast failure detection between two nodes and notifies any protocol (OSPF) of this event to make it converge much faster than with default timers in protocols. Because OSPF hello timers may not be fast enough for detecting neighbor loss, you can use BFD to establish a BFD connection with the OSPF neighbor and bring an OSPF neighbor down as soon as BFD detects an issue.

Note that BFD is used for down detection only. This means that regular OSPF neighbor discovery and state machine transitions are not affected by enabling BFD.

You can enable BFD on all OSPF interfaces at the global level or on a specific interface. By default, BFD is disabled globally and on all interfaces, with individual interface configuration taking precedence over the global setting.


 

Informational Note:  BFD is not supported for OSPFv6.

New Command Options

Setting the vrouter global OSPF level:

To enable OSPF BFD per vRouter on global OSPF level:

CLI network-admin@switch > vrouter-modify name vrouter-name 

vrouter-modify

modify a vrouter

one or more of the following options:

 

ospf-bfd-all-if|no-ospf-bfd-all-if

enables or disables BFD protocol for fault detection on all OSPF interface. Default is disabled.

Setting the Interface (nic) OSPF level:

To enable OSPF BFD per interface If there is no interface configuration :

CLI network-admin@switch > vrouter-interface-config-add vrouter-name nic .

vrouter-interface-config-add

Add an interface configuration to a vRouter VNIC name.

one or more of the following options:

 

nic vrouter interface nic

Specify the name of the VNIC.

[ospf-bfd] default|enable|disable

Enable BFD protocol support for OSPF fault detection.

To enable OSPF BFD per interface if a interface configuration already exists:

CLI network-admin@switch > vrouter-interface-config-modify vrouter-name name nic nic ospf-bfd enable|disable|default

vrouter-interface

Modify an interface configuration to a vRouter

 

 

One or more of the following options:

Specify the name of the VNIC.

ospf-bfd enable|disable|default

Enables or disables the BFD protocol for fault detection on all OSPF interface. Default is disabled.

Displaying the OSPF BFD Configuration State

To display the configuration state of OSPF BFD, use these show commands:

CLI network-admin@switch > vrouter-show

CLI network-admin@switch > vrouter-interface-show


 

Informational Note:  There are no changes to the commands: vrouter-ospf-neighbor-show and vrouter-bfd-neighbor-show

Support for Route Maps for OSPF Routes

Route maps are the only way to associate a redistribute metric or metric-type for OSPFv3 and currently, you cannot configure metrics for OSPF. In this release, you can now define a route map to prevent OSPF routes from being added to the routing table. This filtering happens at the moment when OSPF is installing the route in the routing table.

Before you configure route maps, configure a list of prefixes using the following command:

vrouter-prefix-list-add

 

Use the following set of commands to configure route maps for OSPF:

vrouter-route-map-add

vrouter-name name-string

Specify the name of the vRouter service.

name name-string

Specify the name for the route map.

seq integer

Specify the sequence number as an integer between 1 and 4294967295.

action permit|deny

Specify the route map action as permit or deny.

match-prefix vrouter prefix-list name-string

Specify the name of the prefix list used for the route map.

community-attribute unset|none|no-export|no-advertise|
internet|local-AS

Specify the community attribute for the route map.

local-pref integer

Specify the local preference as an integer between -1 and 4294967295.

metric none

Specify the metric as none.

metric-type 1|2

Specify the metric type as 1 or 2.

 

vrouter-route-map-remove

vrouter-name name-string

Specify the name of the vRouter service.

name name-string

Specify the name for the route map.

seq integer

Specify the sequence number as an integer between 1 and 4294967295.

vrouter-route-map-show

vrouter-name name-string

Displays the name of the vRouter service.

name name-string

Displays the name for the route map.

seq integer

Displays the sequence number as an integer between 1 and 4294967295.

action permit|deny

Displays the route map action as permit or deny.

match-prefix vrouter prefix-list name-string

Displays the name of the prefix list used for the route map.

community-attribute unset|none|no-export|no-advertise|
internet|local-AS

Displays the community attribute for the route map.

local-pref integer

Displays the local preference as an integer between -1 and 4294967295.

metric none

Displays the metric as none.

metric-type 1|2

Displays the metric type as 1 or 2.

Support for OSPF SNMP MIBs

You now enable or disable SNMP MIBs for OSPF configurations by using the command, vrouter-create, or vrouter-modify:

CLI network-admin@switch > vrouter-create name-string ospf-snmp|no-ospf-snmp ospf-snmp-notification|no-ospf-snmp-notification

Adding Default Route Information Settings for OSPF Routing

An OSPF vRouter, by default, does not generate a default route into the OSPF domain. In order for OSPF to generate a default route, you must explicitly configure the vRouter with this information.

There are two ways to inject a default route into a normal area.

1. If the ASBR already has the default route in the routing table, you can advertise the existing 0.0.0.0/0 into the OSPF domain with the ospf-default-information parameter.

2. If the ASBR doesn't have a default route, you can add the keyword always to the ospf-default-information command.

 

The OSPF vRouter advertises a default route into the OSPF domain, even if a route to 0.0.0.0 is configured. Another benefit of adding always keyword is that it can add stability to the internetwork. For example, if the ASBR is learning a default route from another routing domain such as RIP and this route is flapping, then without specifying always keyword, each time the route flaps, the ASBR sends a new Type 5 LSA into the OSPF domain causing instability inside the OSPF domain. With the always keyword, the ASBR always advertises the default route inside the OSPF domain, and the flapping of the default route from the RIP domain does not cause any instability inside the OSPF domain.

When you configure the metric type, you can use the parameters described for the vrouter- commands for configuring a route map.

These parameters control default route generation for IPv4 and IPv6 default routes.

vrouter-create

ospf-default-information none|originate|always

Specify if you want to use the default route information for OSPF.

none — no default route is generated.

originate — the default route is generated only if a default route is present in the routing table.

always — the default route is generated even if no default route is present in the routing table.

ospf-default-info-originate-metric none

Specify the metric for the default route.

ospf-default-info-originate-metric-type 1|2

Specify the metric type as 1 or 2.

vrouter-modify

ospf-default-information none|originate|always

Specify if you want to use the default route information for OSPF.

none — no default route is generated.

originate — the default route is generated only if a default route is present in the routing table.

always — the default route is generated even if no default route is present in the routing table.

ospf-default-info-originate-metric none

Specify the metric for the default route.

ospf-default-info-originate-metric-type 1|2

Specify the metric type as 1 or 2.

ospf-default-info-originate-route-map vrouter route-map name

Specify the OSPF default information route map.

vrouter-show

ospf-default-information none|originate|always

Displays the default route information for OSPF.

none — no default route is generated.

originate — the default route is generated only if a default route is present in the routing table.

always — the default route is generated even if no default route is present in the routing table.

ospf-default-info-originate-metric none

Displays the metric for the default route.

ospf-default-info-originate-metric-type 1|2

Displays the metric type as 1 or 2.

ospf-default-info-originate-route-map vrouter route-map name

Displays the OSPF default information route map.

Adding Metric and Metric Type for Route Maps

Route maps are the only way to associate a redistribute metric and metric-type for OSPFv3 and the metrics are not configurable using the current OSPF commands. Route maps are another method to configure metric and metric-type on routers. Configuration of metrics and metric-type for OSPFv3 requires route maps.

vrouter-route-map-add

metric none

Specify a metric for the route map.

metric-type none|1|2

Specify the metric type.

The new parameters also apply to the vrouter-route-map-modify and vrouter-route-map-show commands.

You can also specify metrics and route maps for vRouters configured as OSPF and BGP vRouters.

vrouter-modify

bgp-redist-static-route-map vrouter route-map name

Specify the route map for BGP redistribution of static routes.

bgp-redist-connected-route-map vrouter route-map name

Specify the route map for BGP redistribution of connected routes.

bgp-redist-ospf-route-map vrouter route-map name

Specify the route map for BGP redistribution of OSPF routes.

ospf-redist-static-route-map vrouter route-map name

Specify the route map for OSPF redistribution of static routes.

ospf-redist-connected-route-map vrouter route-map name

Specify the route map for OSPF redistribution of connected routes.

ospf-redist-bgp-route-map vrouter route-map name

Specify the route map for OSPF redistribution of BGP routes.

 

Configuring Routing Information Protocol (RIP)

Routing Information Protocol (RIP) is the oldest routing protocol and provides networking information to routers. Routers need to know what networks are available and how the distance required to reach it.

RIP is a distance vector protocol, and uses hop counts to determine distance and destination. Every 30 seconds, RIP sends routing information to UDP port 50. If the router is default gateway, it advertises itself by sending 0.0.0.0 with a metric of 1.

Figure 3:I RIP

RIP-example-topology.png

1. Create vRouter1 on VLAN33:

CLI network-admin@switch > vrouter-create name vrouter1  fabricname-global router-type hardware

You can also specify how RIP routes are distributed using the parameter, rip-redistribute

static|connected|ospf|bgp.

2. Add network 10.16.33.0/24 to vrouter1:

CLI network-admin@switch > vrouter-rip-add vrouter-name vrouter1 network 10.16.33.0/24 metric 2

3. Add network 10.16.35.0/24 to vrouter1:

CLI network-admin@switch > vrouter-rip-add vrouter-name vrouter1 network 10.16.55.0/24 metric 2

4. To view the configuration, use the vrouter-rip-show command. This displays all RIP routes configured using the vrouter-rip-add command.

To view RIP routes not configured using the vrouter-rip-add command, use the
vrouter-rip-routes-show command.

Configuring Static Routes

vRouters forward packets using either routing information from route tables manually configured or routing information calculated using dynamic routing algorithms.

Static routes define explicit paths between two vRouters and are not automatically updated. When network changes occur, you have to reconfigure static routes. Static routes use less bandwidth than dynamic routes.

Figure 5: Configuring a Static Route

static-route-example-topology.png

In this example, you configure a static route on vRouter1 for the network, 172.16.10.10/24 with a gateway IP address, 172.16.20.1:

CLI network-admin@switch > vrouter-static-route-add vrouter-name vrouter1 network 172.16.10.10/24 gateway-ip 172.16.20.1

Support for Bidirectional Forwarding Detection on Static Routes

This version of Netvisor OS provides support for static route reachability detection using Bidirectional Forwarding Detection (BFD) protocol. A static route entry is installed in the Routing Information Database (RIB) only if BFD is able to communicate with the gateway. After installation, BFD periodically monitors reachability and removes the route if connectivity is lost.

When a Netvisor OS vRouter is configured as a gateway, Netvisor OS sends out BFD hellos periodically to specified neighbors. Static BFD sessions are configurable for this purpose.

Currently when a static route is created, a route entry is installed in RIB regardless of the reachability of the gateway. By making static routes conditional over BFD, neighborship formation alleviates this problem.

Netvisor OS now provides new parameters to configure static BFD sessions between a Netvisor OS vRouter and any remote routers supporting BFD. The vRouter sends out periodic BFD packets to these neighbors, so that the routers can determine if the Netvisor OS vRouter, acting as a gateway, is alive or not.

If the BFD destination IP address matches with a static route gateway IP address, that static route is considered BFD enabled. This means that this static route is installed in the RIB only if the BFD session is up. The BFD sessions are on a per gateway basis, in that different static routes using the same gateway, use the same BFD session to determine connectivity.

If the BFD session goes down, all such static routes are removed from RIB. The source address for the BFD session is the interface address of any vRouter interface (vnic) or a loopback interface.

BFD timers can be specified for the vRouter interface or the loopback interface.

CLI Commands

vrouter-static-bfd-add

Add a static BFD session

vrouter selector:

 

vrouter-name name-string

Specify the name of the vRouter service configuration to add BFD

the following static-bfd arguments:

 

src-ip ip-address

Specify the source IP address for the BFD session.

dst-ip ip-address

Specify the destination IP address for the BFD session.

type single-hop|multi-hop

Specify the BFD type.

vrouter-static-bfd-remove

Remove a static BFD session

 

vrouter selector:

 

vrouter-name name-string

Specify the name of the vRouter service configuration to add BFD.

the following static-bfd arguments:

 

src-ip ip-address

Specify the source IP address for the BFD session.

dst-ip ip-address

Specify the destination IP address for the BFD session.

vrouter-static-bfd-show

Displays a static BFD session

vrouter selector:

 

vrouter-name name-string

Displays the name of the vRouter service configuration to add BFD

the following static-bfd arguments:

 

src-ip ip-address

Displays the source IP address for the BFD session

dst-ip ip-address

Displays the destination IP address for the BFD session

type single-hop|multi-hop

BFD type

 

The source IP address is a vRouter interface (vnic) or a loopback interface.

CLI network-admin@switch > vrouter-static-bfd-show

vrouter-name src-ip         dst-ip    type       

------------ -------------- --------- ----------

vr1          100.1.1.1      200.1.1.1 single-hop

vr1          100.1.1.1      201.1.1.1 multi-hop

 

The vrouter-static-route-show command is modified to show if a route is BFD-enabled or not. If BFD is configured, the configured source IP for that session is displayed.

Example output of static routes configured with BFD:

CLI network-admin@switch > vrouter-static-route-show

vrouter-name network      gateway-ip distance bfd        bfd-src-ip

------------ ------------ ---------- -------- ---        ---------

vr1          101.1.1.0/24 201.1.1.1  1        single-hop 100.1.1.1

vr1          102.1.1.0/24 202.1.1.1  1        multi-hop  100.1.1.1

vr1          103.1.1.0/24 203.1.1.1  1                            

 

In addition, the existing command, vrouter-bfd-neighbor-show displays any static BFD neighbor information.

The existing commands, vrouter-interface-config-add and vrouter-interface-config-modify can be used to configure BFD timers.

Adding IPv6 Link-Local Addresses for Static Routing

IPv6 link-local addresses have a specific prefix fe80::/10 and are relevant only on the local link. This makes it possible to have the same link-local address on multiple IPv6 interfaces. If you add a static route reachable through a link-local address, you must specify the outgoing interface.

A new parameter now allows you to specify the interface for the static route:

vrouter-static-route-add

vrouter-name name-string

Specify the name of the vRouter service.

network ip-address

Specify the IP subnet of the network that you want to add a static router.

netmask netmask

Specify the netmask of the IP subnet.

gateway-ip ip-address

Specify the IP address of the gateway that you want to route packets destined for the network IP address.

bfd-dst-ip ip-address

Specify the destination IP address for BFD monitoring.

distance number

Specifies the administrative distance in a number from 0 to 255.

0  — Connected interface

1 — Static route

110 — OSPF

120 — RIP

200 — Internal BGP

interface vrouter interface nic

Specify the vRouter interface for the static route.

You can remove or display the state using the commands, vrouter-static-route-remove, and vrouter-static-route-show.

Support for IPv6 Hardware Routing (EA)

Currently Netvisor ONE supports IPv6 natively only, which means IPv6 cannot co-exist with IPv4 on the same interface and no encapsulation.

Netvisor ONE now supports OSPFv3 and BGP-Multiprotocol with IPv6 unicast and static routing as Control Plane protocols. vRouter interfaces can be configured with globally scoped IPv6 addresses.

vrouter-interface-add vrouter-name vrouter-1 ip 2200:1111:2222:3333::1/64 vlan 100

The link-local IPv6 address is created automatically by Netvisor ONE when a new IPv6 interface is created, and is the same IPv6 address for all vRouter interfaces.

After the creation of a new globally scoped IPv6 address, the IPv6 address is installed as the host route in the hardware. Both global and link-local addresses are present in the Layer 2 and Layer 3 tables.

OSPFv3 always uses the link-local IP address as the next-hop IP address for any route. .For IPv6 to obtain the correct router interface, an interface index is used for a new route added to the RIB.

Network nodes may use the link-local IP address instead of the global IP address to reach the vRouter interface. OSPF unicast packets use the link-local IP address.

When a BGP peer sends an update message for a route, it may include the link-local and global IP address as the next hop. Netvisor ONE accepts only the globally scoped IP address. The BGP peer can receive the link-local IP address as the next hop if the peer is directly connected.

Static routing is also supported by using the globally scoped IP address.

To support VRRP, the interface is added in the same manner as IPv4 interfaces:

Prefix lists are also supported by added the parameter anyv6 to the vrouter-prefix-list-add command.

CLI (network-admin@Spine1)>vrouter-show

name:                                              vr0

type:                                              vrouter

scope:                                             fabric

vnet:                                              vnet0

vnet-service:                                      dedicated

state:                                             enabled

router-type:                                       hardware

hw-router-mac:                                     66:0e:94:bf:e2:ab

cluster-active-active-routing:                     enable

hw-vrid:                                           0

hw-vrrp:                                           1

bgp-as:                                            200

router-id:                                         1.1.1.1

protocol-multi:                                    none

bgp-redistribute:                                  static,connected

 

CLI (network-admin@Spine1)>vrouter-interface-show

vrouter-name:                                      vrouter1

nic:                                               eth0.200

ip:                                                2200::1/16

assignment:                                        static

mac:                                               66:0e:94:bf:e2:ab

vnet:                                              vnet0

vlan:                                              200

vlan-type:                                         public

if:                                                data

vm-nic-type:                                       none

exclusive:                                         no

nic-config:                                        

nic:                                               enable

state:                                             up

 

CLI (network-admin@Spine1)>vrouter-routes-show

vrouter-name   network      type        interface    next-hop     distance                  metric

------------   ---------    ---------   ---------    --------     --------                  ------

vr0            2200::/16    connected   eth0.200                                                  

vr0            2211::/24    connected   eth0.211                                                  

vr0            2222::/64    bgp         eth0.211     2211::2      0                               

vr0            fe80::/10    connected   eth0.200                                                  

Configuration Examples

OSPFv3 on a Hardware Router

CLI (network-admin@Spine1)>vlan-create id 200 scope fabric ports 9

CLI (network-admin@Spine1)>vlan-create id 211 scope fabric

CLI (network-admin@Spine1)>vnet-create name vnet0 scope fabric vlans 200

CLI (network-admin@Spine1)>vrouter-create name vr0 vnet vnet0 router-type hardware router-id 1.1.1.1 hw-vrrp-id 1

CLI (network-admin@Spine1)>vrouter-interface-add vrouter-name vr0 ip 2200::1/64 vlan 200

CLI (network-admin@Spine1)>vrouter-interface-add vrouter-name vr0 ip 2211::1/64 vlan 211

CLI (network-admin@Spine1)>vrouter-ospf6-add vrouter-name vr0 nic eth0.200 ospf6-area 0.0.0.0

CLI (network-admin@Spine1)>vrouter-ospf6-add vrouter-name vr0 nic eth0.211 ospf6-area 0.0.0.0

 

BGP-Multiprotocol with IPv6 Unicast Peers Distributing IPv6 Prefixes 

CLI network-admin@switch > vlan-create id 200 scope fabric ports 9

CLI network-admin@switch > vlan-create id 211 scope fabric

CLI network-admin@switch > vnet-create name vnet0 scope fabric vlans 200

CLI network-admin@switch > vrouter-create name vr0 vnet vnet0 router-type hardware router-id 1.1.1.1 hw-vrrp-id 1

CLI network-admin@switch > vrouter-interface-add vrouter-name vr0 ip 2200::1/16 vlan 200

CLI network-admin@switch > vrouter-interface-add vrouter-name vr0 ip 2211::1/24 vlan 211

CLI network-admin@switch > vrouter-modify name vr0 bgp-as 200 no-bgp-ipv4-unicast

CLI network-admin@switch > vrouter-modify name vr0 bgp-redistribute static,connected

CLI network-admin@switch > vrouter-bgp-add vrouter-name vr0 neighbor 2211::2 remote-as 222 multi-protocol ipv6-unicast

CLI network-admin@switch > vrouter-bgp-add vrouter-name vr0 neighbor 2211::3 remote-as 233 multi-protocol ipv6-unicast

CLI network-admin@switch > vrouter-bgp-network-add vrouter-name vr0 network 2200::/64

CLI network-admin@switch > vrouter-bgp-network-add vrouter-name vr0 network 2211::/64

IPv6 and Prefix Lists

CLI network-admin@switch > vrouter-prefix-list-add vrouter-name vr0 name block200 action deny prefix 2200::/16 seq 95

vrouter-bgp-add vrouter-name vr0 neighbor 2211::2 remote-as 222 multi-protocol ipv6-unicast prefix-list-out block200

Static Route

vrouter-static-route-add vrouter-name vr0 network 7777::/64 gateway-ip 2200::9 distance 20

 

IPv6 Neighbor Discovery Process Support and Optimization

The IPv6 Neighbor Discovery Process (NDP) uses ICMPv6 messages and solicited-node multicast addresses to determine the link-layer address of a neighbor on the same network (local link), verify the reachability of a neighbor, and keep track of neighboring routers. NDP provides the same functionality as ARP in an IPv4 network. NDP has additional features such as autoconfiguration of IPv6 addresses and duplicate address detection (DAD).

In an IPv6 Layer 3 network, a Netvisor OS vRouter can be configured as a First Hop Router and send Router Advertisements to announce the presence, host configuration parameters, routes, and on-link prefixes. In a Layer 2 network, Netvisor OS can enable NDP optimization to prevent flooding of neighbor solicitation messages.

Supported NDP Messages

Neighbor Solicitation messages (ICMPv6 Type 135) are sent on the local link by nodes attempting to discover the link-layer addresses of other nodes on the local link. The Neighbor Solicitation message is sent to the solicited-node multicast address. The source address in the neighbor solicitation message is the IPv6 address of the node sending the Neighbor Solicitation message. The Neighbor Solicitation message also includes the link-layer address of the source node.

After receiving a Neighbor Solicitation message, the destination node replies by sending a Neighbor Advertisement message (ICPMv6 Type 136) on the local link. The source address in the Neighbor Advertisement message is the IPv6 address of the node sending the Neighbor Advertisement message; the destination address is the IPv6 address of the node that sent the Neighbor Solicitation message. The data portion of the Neighbor Advertisement message includes the link-layer address of the node sending the Neighbor Advertisement message.

After the source node receives the Neighbor Advertisement, the source node and destination node can communicate.

Neighbor Solicitation messages are also used to verify the reachability of a neighbor after the link-layer address of a neighbor is identified. When a node wants to verifying the reachability of a neighbor, the destination address in a Neighbor Solicitation message is the unicast address of the neighbor.

Neighbor Advertisement messages are also sent when there is a change in the link-layer address of a node on a local link. When there is such a change, the destination address for the Neighbor Advertisement is the all-nodes multicast address.

Router Advertisement messages (ICMPv6 Type 134) are periodically sent out each IPv6 configured interface of security appliance. The Router Advertisement messages are sent to the all-nodes multicast address.

Router Advertisement messages typically include the following information:

Router Advertisements are also sent in response to Router Solicitation messages (ICMPv6 Type 133). Router Solicitation messages are sent by hosts at system startup so that the host can immediately auto-configure without waiting for the next scheduled router advertisement message. Because Router Solicitation messages are usually sent by hosts at system startup, and the host does not have a configured unicast address, the source address in Router Solicitation messages is usually the unspecified IPv6 address (0:0:0:0:0:0:0:0). If the host has a configured unicast address, the unicast address of the interface sending the Router Solicitation message is used as the source address in the message. The destination address in Router Solicitation messages is the all-routers multicast address with a scope of the link. When a Router Advertisement is sent in response to a Router Solicitation message, the destination address in the Router Advertisement message is the unicast address of the source of the Router Solicitation message.

You can configure the following settings for router advertisement messages:

Unless otherwise noted, Netvisor uses the Router Advertisement message settings specific to an interface.

To configure NDP, use the vrouter-interface-config-add command:

CLI network-admin@switch > vrouter-interface-config-add

nd-suppress-ra|no-nd-suppress-ra

Control the transmission of IPv6 Router Advertisements

v6-ra-prefix ip-address

IPv6 prefix to include in Router Advertisement

prefix-netmask netmask

IPv6 prefix netmask

autoconf|no-autoconf

given prefix can be used for IPv6 autoconf

ra-interval mseconds

Time interval between IPv6 router advertisements

ra-lifetime seconds

Time for which router is considered as default router

Displaying Hardware Routes History

You can display the history of hardware routes in the RIB table. This is useful when troubleshooting hardware routing on the network.

CLI (network-admin@spine1)>vrouter-rib-history-show time 15:30

 

time     caller    reason ip          prelen nexthop     flags              vlan intf_ip     intf_id

-------- --------- ------ ----------- ------ ----------- ------------------ ---- ----------- ---

15:29:41 router-if add    10.16.111.0  24     10.16.111.1 in-hw,local-subnet 111  10.16.111.1        

15:29:43 router-if add   10.16.100.0  24    10.16.100.1 in-hw,local-subnet 100  10.16.100.1 1

 

You can also modify the settings for collecting the history:

CLI (network-admin@spine1)>vrouter-rib-history-settings-modify

 

Configuring MTU Parameters for vRouter Interfaces

Support for IPv4 and IPv6 addresses requires configuring the MTU parameter differently for each type of IP address. By default MTU is set at 1500 for the VNICs. For IPv4 addresses, the Maximum Transmission Unit (MTU) the range is to 68 to 9216, but the range for IPv6 addresses is 1280-9216. However, Netvisor displays the MTU range as 68-9216 which is supported by IPv4 addresses. But if you configure an IPv6 interface with an MTU value outside of the 1280-9216 for IPv6 addresses, Netvisor returns an error.

In the case of interfaces configured with IPv4 and IPv6 addresses (dual-stack), Netvisor limits the MTU range to 1280-9216. The following special rules apply to dual-stack interfaces:

Support for IPv4 and IPv6 on a vRouter Interface

You can now add IPv4 and IPv6 addresses to a vRouter interface. If you enable or disable the interface, both IPv4 and IPv6 are affected. Routing protocols can be enabled or configured independently using the IP address.

When you add a vRouter interface, you can configure it with two IP addresses, IPv4 and IPv6:

vrouter-interface-add vrouter-name name-string vlan vlan-id ip ip-address netmask netmask assigment none|dhcp ip2 ip-address netmask2 netmask assigment none|dhcp|dchpv6

 

You can display the IP addresses:

vrouter-interface-show vrouter-name name-string vlan vlan-id ip ip-address netmask netmask assignment none|dhcp|dchpv6 ip2 ip-address netmask2 netmask assignment none|dhcp|dchpv6

 

To migrate the interface from a single stack to a dual stack, the following commands are used:

vrouter-interface-ip-add

vrouter-name name-string

Specify the name of the vRouter.

nic nic-string

Specify the virtual NIC assigned to the interface.

ip ip-address

Specify the IP address assigned to the interface.

netmask netmask

Specify the netmask of the IP address.

Specify any of the following options

vnet vnet-name

Specify the VNET assigned to the vRouter.

l2-net l2-net name

Specify the Layer 2 interface.

 

vrouter-interface-ip-remove

vrouter-name name-string

Specify the name of the vRouter.

nic nic-string

Specify the virtual NIC assigned to the interface.

ip ip-address

Specify the IP address assigned to the interface.

 

vrouter-interface-ip-show

vrouter-name name-string

Specify the name of the vRouter.

nic nic-string

Specify the virtual NIC assigned to the interface.

ip ip-address

Specify the IP address assigned to the interface.

netmask netmask

Specify the netmask of the IP address.

Specify any of the following options

vnet vnet-name

Specify the VNET assigned to the vRouter.

l2-net l2-net name

Specify the Layer 2 interface.

IPv6 Support for vRouter Loopback Addresses

Netvisor OS now supports IPv4 and IPv6 addresses on the same loopback interface.

When you configure a loopback interface, you can optionally associate a vRouter interface to the configuration. If you do not associate a vRouter interface, Netvisor selects the first non-VRRP vRouter interface. Netvisor uses the loopback interface for a vRouter as a host route in the Forwarding Information Database (FIB) for packets received from any port and routes them to the correct vRouter.

If there is no vRouter interface configured, the loopback interface is unreachable on the network. When you add the first vRouter interface, the loopback interface is reachable.

If you remove the associated vRouter interface, Netvisor selects the next available vRouter interface.

Netvisor does not support multiple vRouter loopback interfaces for IPv6 addresses.

To add an IPv4 address to a loopback interface for vRouter, vr1, use the following syntax:

vrouter-loopback-interface-add vrouter-name vr1 ip 99.1.1.1

 

To add an IPv6 vRouter loopback interface to vRouter, vr1, use the following syntax:

vrouter-loopback-interface-add vrouter-name vr1 ip 2999:1000::1

 

To display the vRouter loopback interface, use the vrouter-loopback-interface-show command:

vrouter-loopback-interface-show

vrouter-name     index ip           router-if

174 ------------ ----- ------------ ---------

175 vr1          1     99.1.1.1     eth0.100

176 vr1          2     2999:1000::1 eth0.100

 

vrouter-routes-show

vrouter-name network           type       interface next-hop                  distance

------------ ---------------- --------- --------- ------------------------- --------

vr1          10.1.1.0/24      connected eth0.100

vr1          10.1.1.0/24      connected eth0.100

vr1          20.1.1.0/24      ospf      eth0.121  12.1.1.2                  110

vr1          88.1.1.1/32      ospf      eth0.121  12.1.1.2                  110

vr1          99.1.1.1/32       connected lo                                                  

vr1          2100:100::/64     connected eth0.100                                            

vr1          2121:100::/64     connected eth0.121                                            

vr1          2200:100::/64    ospf6     eth0.121  fe80::640e:94ff:fe4d:d0c8 110

vr1          2888:1000::1/128 ospf6     eth0.121  fe80::640e:94ff:fe4d:d0c8 110

vr1          2999:1000::1/128  connected lo                                                  

vr1          fe80::/64        connected eth0.121

 

metric

------

 

 

20

20

 

 

 

10

10

 

Configuring Prefix Lists for BGP and OSPF

Prefix lists allow you to permit or deny host IP addresses from route distribution in BGP and OSPF configurations. To configure prefix lists for BGP, this example assumes that you have a vRouter configured for BGP, vrouter-bgp, and you want to deny the IP address, 172.26.0.0 with the netmask 255.255.0.0, sequence number 5, and minimum prefix length 17 bits:

CLI network-admin@switch > vrouter-prefix-list-add vrouter-name vrouter-bgp name deny-bits action deny prefix 172.26.0.0 netmask 255.255.0.0 seq 5 min-prefix-len 17

This prefix list rejects any subnets of 172.26.0.0/16 with prefixes 17 bits or longer. For example, the subnets 172.26.16.9/30 and 172.26.101.0/24 are rejected from route distribution.

The sequence number allows you to insert or remove new lines in a prefix list as well as at the beginning or end. It is recommended that you increment the sequence numbers by 10 so you can easily add or subtract lists from the configuration. See also:

Configuring Packet Relay for DHCP Servers

You can configure a vRouter to relay DHCP requests from local clients to a centralized DHCP server. Because the initial DHCP request arrives from a client that typically does not have an IP address, the client must find the DHCP server using a Layer 2 broadcast.

The DHCP server needs information before the server can allocate an IP address to the client. It must know the subnet and the MAC address of the client. The DHCP server needs the subnet information to ensure that the IP address that the client receives can work on the client’s subnet. The MAC address is necessary so that the DHCP server can find any information that is unique to the client.

When you configure the vRouter as a DHCP proxy, the vRouter converts the local broadcast packet from the client to a unicast packet and forwards it to the server.

Because the DHCP client does not have an IP address when it sends the DHCP request packet, the client uses the IP address, 0.0.0.0, as the source IP address and the general broadcast address 255.255.255.255 for the destination.

The vRouter replaces the source address with the IP address assigned to the interface where the request is received, and replaces the destination IP address with the address you specify in the vRouter packet-relay command.

To configure packet-relay for a DHCP server with the IP address 172.16.21.34 and vRouter interface eth11.100, use the following syntax:

CLI network-admin@switch > vrouter-packet-relay add vrouter-name vrouter-dhcp forward-proto dhcp forward-ip 172.16.21.34 nic eth11.100

Once you add the configuration, you cannot modify it. If you make a mistake or want to add a new configuration, you must use the vrouter-packet-relay-remove command.

Configuring Hardware Routing for a vRouter

YCreate interfaces on hardware routers and map them to virtual NICs in the vRouter zone. Currently, only one hardware vRouter is supported with .

The supported protocols are as follows:

To create a hardware router on a vRouter, hwtest, use the following command:

CLI network-admin@switch > vrouter-create hwtest router-type hardware

Use the same commands as software routing to add protocols and interfaces.

Support for Displaying Quagga Routing and Debug Information for vRouters

This feature provides a new vRouter command to display the output of any Quagga routing and debug information from the Netvisor OS command line interface(CLI).

 

CLI (network-admin@Spine1) > help vrouter-vtysh-cmd

vrouter-vtysh-cmd        display output of a Quagga show command

        name name-string name of service config                  

        cmd cmd-string   any Quagga show/debug/undebug/no debug command

Show Output Examples

CLI (network-admin@Spine1) > vrouter-vtysh-cmd name vr1 cmd "show ip route"

Codes: K - kernel route, C - connected, S - static, R - RIP,

      O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel,

       > - selected route, * - FIB route

 

C>* 100.1.1.0/24 is directly connected, eth1.100

C>* 127.0.0.0/8 is directly connected, lo0

CLI (network-admin@Spine1) > vrouter-vtysh-cmd name vr1 cmd "show running-config"

Building configuration...

 

Current configuration:

!

hostname vr1

log file zebra.log

!

password zebra

enable password zebra

!

interface eth1.100

ipv6 nd suppress-ra

multicast

no link-detect

!

interface lo0

no link-detect

!

ip forwarding

ipv6 forwarding

!

line vty

!

end

 

For this feature, only show commands are allowed as legal values in the CLI.

CLI (network-admin@manojtn) > vrouter-vtysh-cmd name vr1 cmd "config t"

vrouter-vtysh-cmd: Illegal value for "cmd"

vrouter-vtysh-cmd: Legal values: commands starting with show, in quotes

Viewing Quagga Logs   

Quagga logs files, such as Zebra, OSPF, OSPF6, BGP, BFD and RIP can be viewed directly from the console using the Netvisor OS CLI. Because Quagga log files accumulate on the switch, you may want to clear a particular log file so they do not create space issues.

New Commands

Use this command to view Quagga logs files directly from your console:

CLI network-admin@switch > vrouter-log-show vrouter-name vrouter-name protocol 

vrouter-log-show

Displays vrouter protocol logs

one or more of the following options:

vrouter-name vrouter-name

Specify name of the vRouter.

protocol zebra|ospf|ospf6|bgp|bfd|rip

Specify the name of the protocol files to view.

 

 

Use this command to clear Quagga files from a specific protocol log file:

CLI network-admin@switch > vrouter-log-clear

vrouter-log-clear

Clears vrouter protocol logs from a protocol log file

one or more of the following options:

vrouter-name vrouter name

Specify the name of the vRouter service.

 protocol zebra|ospf|ospf6|bgp|bfd|rip

Specify the name of the log file to clear.

 

 

Configuring Multicast Listener Discovery (MLD)

In IPv4, Layer 2 switches can use IGMP snooping to limit the flooding of multicast traffic by dynamically configuring Layer 2 interfaces so that multicast traffic is forwarded to only those interfaces associated with IP multicast address. In IPv6, MLD snooping performs a similar function. With MLD snooping, IPv6 multicast data is selectively forwarded to a list of ports that want to receive the data, instead of being flooded to all ports in a VLAN. This list is constructed by snooping IPv6 multicast control packets.

MLD is a protocol used by IPv6 multicast routers to discover the presence of multicast listeners (nodes configured to receive IPv6 multicast packets) on its directly attached links and to discover which multicast packets are of interest to neighboring nodes. MLD is derived from the IGMP protocol. MLD version 1 (MLDv1) is equivalent to IGMPv2, and MLD version 2 (MLDv2) is equivalent to IGMPv3. MLD is a subprotocol of Internet Control Message Protocol version 6 (ICMPv6), and MLD messages are a subset of ICMPv6 messages, identified in IPv6 packets by a preceding Next Header value of 58.

The switch can snoop on both MLDv1 and MLDv2 protocol packets and bridge IPv6 multicast data based on destination IPv6 multicast MAC addresses. The switch can be configured to perform MLD snooping and IGMP snooping simultaneously.

To display MLD routers on the network, use the mld-router-show command:

CLI network-admin@switch > mld-router-show

group-ip:                

node-ip:                 

vlan:                    

port:                    

source:                  

node-type:               

expires:                 

The show ouput displays the following information:

To display MLD group membership on the network, use the mld-show command:

CLI network-admin@switch > mld-show

group-ip:                

node-ip:                 

vlan:                    

port:                    

source:                  

node-type:               

expires:                 

The show ouput displays the following information:

To enable or disable MLD snooping or modify the scope, use the mld-snooping-modify command:

CLI network-admin@switch > mld-snooping-modify

To modify the scope from fabric to local, use the following syntax:

CLI network-admin@switch > mld-snooping-modify scope fabric

To display information about MLD snooping, use the mld-snooping-show command.

Configuring an IGMP Querier IP Address

You can configure an IGMP querier IP address for a VLAN or as a global IGMP querier. The IGMP querier sends IGMP General Query messages. on the network.

If no querier IP address is specified, then 0.0.0.0 is the default value. There can be an unique querier IP for each VLAN, or you can configure the same Querier IP address for all the VLANs participating in IGMP snooping. The Querier IP address should have a local scope and every switch should have a unique Querier IP address.  

With a valid source IP address on IGMP Query packets, the VLAN, where Query is received, is added to an IGMP Snoop switch list, and is now reflected in the igmp-switches-show output and the IGMP queries are sent to the peer Switch as well. This is to solicit a report from the hosts listening on the peer switch.

Use these Netvisor OS commands to configure an IGMP querier IP address.

igmp-querier-ip-modify

Modify IGMP Querier IP configuration

querier-ip ip-address

Specify the Snooping Querier IP address

vlans-on-querier-ip vlan-list

Specify the VLAN map.

 

 

igmp-querier-ip-show

Display IGMP Querier IP config

querier-ip is

Specify the Snooping Querier IP address

vlans-on-querier-ip vlan-list

VLAN MAP

 

 

Multicast Listener Discovery (MLD) Snooping per VLAN

MLD snooping provides support per individual VLANs. In addition to current global enable and disable support, you can do the following using the mld-snooping-modify command:

Command Options

Use these command options for the mld-snooping-modify command:

CLI network-admin@switch > mld-snooping-modify

mld-snooping-modify

Enables or disables Multicast Listener Discovery (MLD) snooping

 one or more of the following options:

 

scope local|fabric

Specify the MLDsnooping scope - fabric or local

enable|disable

Enable or disable MLD snooping

mldv1-vlans vlan-list

Specify the VLANs to enable snooping and use MLDv1 protocol. Default: none

mldv2-vlans vlan-list

Specify the VLANs on which to enable snooping and use MLDv2 protocol. Default 1 - 4092

snoop-linklocal-vlans vlan-list

Allow snooping of link-local groups(ff02::/16) on these vlans. Default 1 - 4092

 snoop-nd-vlans vlan-list

Allow snooping of ND SN Multicast addresses (ff02::1:ff/104) on these vlans. Default 1 - 4092

 

These command options replace these Netvisor OS versions earlier than 2.5.2 command options:

Command Options, versions earlier than 2.5.2

Replaced by Command Options, version 2.5.2

version v1

mldv1-vlans 1-4092

mldv2-vlans none

version v2

mldv1-vlans none

mldv2-vlans 1-4092

snoop-linklocal enable

snoop-linklocal-vlans 1-4092

snoop-linklocal disable

snoop-linklocal-vlans none

snoop-nd enable

snoop-nd-vlans 1-4092

snoop-nd disable

snoop-nd-vlans none


 

Informational Note:  Backward compatibility is supported. Existing configurations automatically upgrade to the new format.

Show Output

The mld-snooping-modify show format all command displays the following sample output:

CLI network-admin@switch > mld-snooping-show format all

switch:

Name of Switch

enable:

no

mldv1-vlans:

none

mldv2-vlans:

1-4092

snoop-linklocal-vlans:

1-4092

snoop-nd-vlans:

1-4092

-managed-vlans:

none

interop-v1-vlans:

none

vlans:

1-4092

Creating MLD Static Sources and Static Groups

To determine how to forward multicast traffic, a switch with MLD snooping enabled maintains information about the following interfaces in its multicast forwarding table:

The switch learns about these interfaces by monitoring MLD traffic. If an interface receives MLD queries, the switch adds the interface to the multicast forwarding table as a multicast-router interface. If an interface receives membership reports for a multicast group, the switch adds the interface to the multicast forwarding table as a group-member interface.

Table entries for interfaces that the switch learns about are subject to aging. For example, if a learned multicast-router interface does not receive MLD queries within a certain interval, the switch removes the entry for that interface from the multicast forwarding table.

You can create MLD static sources using IPv6 addresses and then create static groups using the static sources.

To create an MLD static source for IPv6 address, ff02::1:ff11:111 as the group, and IPv6 2001:db8::2:1 as the source on VLAN 25, port 44-45, use the following syntax:

CLI network-admin@switch > mld-static-source-create source-ip 2001:db8::2:1 group-ip ff02::1:ff11:111 vlan 25 ports 44-45

The parameter, ports, is an optional parameter. You can delete an MLD static source, but you cannot modify the parameters. To display MLD static sources, use the mld-static-source-show command.

To create an MLD static group for IPv6 address, ff02::1:ff11:1111, on VLAN 25, ports 44-45, use the mld-static-group-create command:

CLI network-admin@switch > mld-static-group-create group-ip ff02::1:ff11:1111 vlan 25 ports 44-45

You can delete an MLD static group, but you cannot modify the parameters. To display MLD static groups, use the mld-static-group-show command.

Displaying MLD Statistics for a VLAN

To display MLD statistics for a VLAN, use the mld-stats-show command:

CLI network-admin@switch > mld-stats-show

switch:

vlan:

v1-queries:

v2-queries:

v1-member-reports:

v1-done-group:

v2-member-reports:

queries-sent:

drops:

ignored:

 

Configuring Virtual Router Redundancy Protocol

Virtual Router Redundancy Protocol (VRRP) is an election protocol that enables virtual routing functions for a master or standby routing infrastructure for a given IP address. A virtual router is defined by a virtual router identifier (VRID) and a virtual router IP address (VIP). The scope of the virtual routers is restricted to a single VLAN.

VRRP provides information on the state of a virtual router, not the routes processed and exchanged by the router. It increases the availability and reliability of routing paths by automatic gateway selections on an IP subnetwork.

VRRP provides rapid transition from master to standby and from standby to master. The master router sends advertisements every second. If the master VRRP advertisements are not received within a window of time, three (3) seconds, then the standby virtual router becomes the master virtual router and begins performing routing for the virtual router. If the master router becomes active again, it can become the master again or allow the standby to continue as the master router. The role depends on the value assigned to VRRP priority.

vRouter interfaces now support both IPv4 and IPv6 addresses.

Configuring VRRP Priority

The Priority is a value used by the VRRP router for master election. The valid priority range for a virtual router is from 1 to 254. 1 is the lowest priority and 254 is the highest priority. The default value for standby routers is 100. Higher values indicate higher priority for the virtual router.

Configuring the VRRP ID

The Virtual Router Identifier is a configurable value between 1 and 255. There is no default value.

Example Configuration

In this example, you have the following configurations on two switches (SW1 and SW2) on the network:

1. On SW1, configure a vRouter:

CLI network-admin@switch > vrouter-create name vrrp-rtr1 vnet vrrp-router router-type hardware enable

2. Add the first vRouter interface:

CLI network-admin@switch > vrouter-interface-add vrouter-name vrrp-rtr1 ip 192.168.11.3 netmask 24 vlan 100 if data

3. Use the vrouter-interface-show command to see the name of the interface:

CLI network-admin@switch > CLI network-admin@switch > vrouter-interface-show format all layout vertical

vrouter-name: vrrp-rtr1

nic: eth0.100

ip: 192.168.11.3/24

assignment: static

mac: 66:0e:94:dd:18:c4

vlan: 100

vxlan: 0

if: data

alias-on:

exclusive: no

nic-config: enable

nic-state: up

 

4. Create the VRRP interface:

CLI network-admin@switch > CLI (server-switch)>vrouter-interface-add vrouter-name vrrp-rtr1 ip 192.168.11.2 netmask 24 vlan 100 if data vrrp-id 10 vrrp-primary eth0.100 vrrp-priority 100

5. Create the vRouter and interfaces on SW2:

CLI network-admin@switch > CLI network-admin@switch > vrouter-create name vrrp-rtr2 vnet vrrp-router router-type hardware dedicated-vnet-service

6. Add the vRouter interface:

CLI network-admin@switch > CLI network-admin@switch > vrouter-interface-add vrouter-name vrrp-rtr2 ip 192.168.11.4 netmask 24 vlan 100 if data

7. Use the vrouter-interface-show command to see the name of the interface:

CLI network-admin@switch > CLI network-admin@switch > vrouter-interface-show format all layout vertical

vrouter-name: vrrp-router2

nic: eth2.100

ip: 192.168.11.3/24

assignment: static

mac: 66:0e:94:21:a9:6c

vlan: 100

vxlan: 0

if: data

alias-on:

exclusive: no

nic-config: enable

nic-state: up

 

8. Create the VRRP interface:

CLI network-admin@switch > CLI network-admin@switch > vrouter-interface-add vrouter-name vrrp-rtr2 ip 192.168.11.2 netmask 24 vlan 100 if data vrrp-id 10 vrrp-primary eth0.100 vrrp-priority 50

9. Display the information about the VRRP setup:

CLI network-admin@switch > CLI network-admin@switch > vrouter-interface-show format all layout vertical

vrouter-name: vrrp-router1

nic: eth0.100

ip: 192.168.11.3/24

assignment: static

mac: 66:0e:94:dd:18:c4

vlan: 100

vxlan: 0

if: data

alias-on:

exclusive: no

nic-config: enable

nic-state: up

vrouter-name: vrrp-router1

nic: eth1.100

ip: 192.168.11.2/24

assignment: static

mac: 00:00:5e:00:01:0a

vlan: 100

vxlan: 0

if: data

alias-on:

exclusive: no

nic-config: enable

nic-state: up

vrrp-id: 10

vrrp-primary: eth1.100

vrrp-priority: 100

vrrp-state: master

vrouter-name: vrrp-router2

nic: eth3.100

ip: 192.168.11.4/24

assignment: static

mac: 66:0e:94:21:54:07

vlan: 100

vxlan: 0

if: data

alias-on:

exclusive: no

nic-config: enable

nic-state: up

vrouter-name: vrrp-router2

nic: eth3.100

ip: 192.168.11.2/24

assignment: static

mac: 00:00:5e:00:01:0a

vlan: 100

vxlan: 0

if: data

alias-on:

exclusive: no

nic-config: enable

nic-state: down

Pluribus Networks Configuration Guide

pluribusnetworks.com 87

vrrp-id: 10

vrrp-primary: eth3.100

vrrp-priority: 50

vrrp-state: slave

 

When you intentionally disable the VRRP interface, the slave interface becomes the master interface:

vrouter-name: vrrp-router2

nic: eth3.100

ip: 192.168.11.1/24

assignment: static

mac: 00:00:5e:00:01:0a

vlan: 100

vxlan: 0

if: data

alias-on:

exclusive: no

nic-config: enable

nic-state: up

vrrp-id: 10

vrrp-primary: eth3.100

vrrp-priority: 50

vrrp-state: master

 

When you re-enable the VRRP interface, it becomes the master again, and the second interface returns to the slave:

vrouter-name: vrrp-router2

nic: eth3.100

ip: 192.168.11.2/24

assignment: static

mac: 00:00:5e:00:01:0a

vlan: 100

vxlan: 0

if: data

alias-on:

exclusive: no

nic-config: enable

nic-state: down

vrrp-id: 10

vrrp-primary: eth3.100

vrrp-priority: 50

vrrp-state: slave

 

Layer 3 Table Validation

Layer 3 entries can become unsynchronized between the software table and the hardware table. This is useful when routes are modified while the routes are updating on the network. This feature adds parameters to the l3-setting-modify command to automatically check Layer 3 entries:

CLI network-admin@switch > l3-setting-modify

one or more of the following options:

 

aging-time seconds

Specify the aging-time for Layer 3 entries, use 0 to disable aging.

convergence-time seconds

Specify the unicast convergence time on bootup (seconds)

l3-checker|no-l3-checker

Specify if you want to check Layer 3 consistency

l3-checker-interval duration: #d#h#m#

Specify the interval for Layer 3 consistency checker

l3-checker-fix|
no-l3-checker-fix

Enable fixing of inconsistent entries

 

Two commands are available to manually check and fix Layer 3 inconsistencies:

CLI network-admin@switch > l3-check-fix

CLI network-admin@switch > l3-check-show

 

Using an L3 Network to Establish the Netvisor OS Fabric

The Netvisor OS fabric can be established over the management network or an in-band network over Layer 2. Fabric over a Layer 3 network uses an existing or new Layer 3 network in order to establish the Netvisor OS fabric. Currently this feature is only supported over a BGP network. Before you can configure this feature on your network, make sure that BGP routing is configured on your switches.

Basic Concepts

In a simple topology with a network of two BGP neighbors, The BGP neighbor information is specified, while the two in-band networks are used to establish TCP sessions between the two switches.

To establish a fabric communication between the two switches over the BGP network, you need to do the following:

L3-Network-Fabric.png

 

Figure 10:Example Network of Two BGP Neighbors Topology

1. Create a vrouter in each switch.

2. Set up BGP peering and redistribute routes so that they can reach each other’s in-band networks.

3. Setup up global static routes using the local vrouter as the gateway. You need to do this because the routes reside inside the vrouter and each switch needs to reach the other switch’s in-band network.

4. Enable switch-B to join the fabric that was created by switch-A.

Creating a vRouter for Fabric Communication

Use the fabric-comm-vrouter-bgpcreate command to create a vRouter for fabric communication. This command has the following options:

name: vrouter name

bgp-as: BGP As number of the vrouter

bgp-redistribute: (default connected)

bgp-max-paths: (optional)

bgp-ibgp-multipath: (optional)

interface to communicate with other router:

IP address/netmask

vlan - vlan of the interface, or

l3-port - layer 3 port to use

bgp neigbor info: (optional)

neighbor: IP address

remote-as: neighbor AS number

interface info to communicate with current switch inband: (optional)

IP address/netmask

fabric network:

network/netmask to reach inband network of the switch that created the fabric

bfd: To use BFD for rapid BGP peer loss detection

allowas-in:

Accept routes with own AS in AS_PATH

This is only required for cluster connections

 

This CLI performs the majority of the actions in Steps 1 - 4 in the above exampleusing the information provided in the CLI. However, it does not:

If the inband network uses a /30 netmask, then it automatically determines the vrouter inband IP address from the main inband IP address. The switch that creates the fabric (the root switch) does not specify the fabric network, but does need to create a route to the other switch’s inband network.

switch-A> fabric-create name myfabric

switch-A> fabric-comm-vrouter-bgp-create name vrouter-a bgp-nic-l3-port 10 bgp-as 65001 bgpnic-

ip 192.169.0.5/30 in-band-nic-ip 12.1.1.10/24 remote-as 65002 neighbor 192.169.0.6 bgpredistribute

connected

switch-A> fabric-in-band-network-create 12.1.2.0/30

switch-B> fabric-comm-vrouter-bgp-create name vrouter-b bgp-nic-l3-port 20 bgp-as 65002 bgpnic-

ip 192.169.0.6/30 in-band-nic-ip 12.1.2.10/24 remote-as 65001 neighbor 192.169.0.5

fabric-network 12.1.1.0/24 bgp-redistribute connected

switch-B> fabric-join switch-ip 12.1.1.1

Joined fabric myfabric. Restarting ...

 

Multiple BGP Neighbors

With more than two switches, the first BGP peer for each switch can be created using the fabric-comm-vrouter-bgp-create CLI. You need to create the rest separately. Here is an example with switch-C added to the topology in Figure 10.

L3-Fabric-Multiple-Layers.png

Figure 5: An Example Fabric over Layer 3 Topology

The configuration for this will proceed along the same lines as before. In addition the following steps are required in order to bring switch-B into the fabric:

1. In switch-A, create BGP peering to swtich-C and create a static route to reach switch-C’s inband network. The way to extend this beyond three switches is to use this extra step in every switch that has more than one BGP peer:

 

switch-A> vrouter-interface-add vrouter-name vrouter-a ip 192.169.0.9/30 l3-port 11

switch-A> vrouter-bgp-add vrouter-name vrouter-a neighbor 192.169.0.10 remote-as 65003

switch-A> fabric-in-band-network-create 12.1.3.0/30

 

2. In switch-C, use the fabric-comm-vrouter-bgp-create command as before and con­nect:

 

switch-C> fabric-comm-vrouter-bgp-create name vrouter-c bgp-nic-l3-port 21 bgp-as 65003 bgpnic-

ip 192.169.0.10/30 in-band-nic-ip 12.1.3.10/24 remote-as 65001 neighbor 192.169.0.9

fabric-network 12.1.1.0/24 bgp-redistribute connected

switch-C> fabric-join switch-ip 12.1.1.1

Joined fabric myfabric. Restarting ...

 

Support for Bidirectional Forwarding Detection (BFD) and Static Routes

Currently when a static route is created, Netvisor OS installs a route entry in the routing information database (RIB) regardless of the reachability of the gateway. When static routes are conditional over BFD neighbor-ship formation, Netvisor OS alleviates this issue.

Netvisor OS supports static route reachability detection by using BFD protocol, and a static route entry is installed in the RIB only if BFD is able to communicate with the gateway. After installation, BFD periodically monitors reachability and removes the route if connectivity is interrupted. The Pluribus vRouter acts as a gateway, and sends out BFD hellos periodically to specified neighbors. Static BFD sessions are also configurable.

Netvisor OS allows you to configure static BFD sessions between a vRouter and any remote routers supporting BFD. The vRouter sends out periodic BFD packets to these neighbors, so that they can determine if PN router, acting as a gateway, is alive or not.

If the BFD destination IP address matches a static route gateway IP address, Netvisor OS considers the static route as BFD enabled. This means the static route is installed in the RIB only if the BFD session is up. Note that the BFD sessions are per gateway, and different static routes with the same gateway IP address use the same BFD session to determine connectivity. If the BFD session goes down, all static routes are removed from the RIB. The source IP address for the BFD session can be the interface address of any vRouter interface or a loopback interface. BFD timers can be specified for the vRouter interface or the loopback interface.

Use the following new commands to configure BFD on static routes:

CLI network-admin@switch > vrouter-static-bfd-add

CLI network-admin@switch > vrouter-static-bfd-remove

CLI network-admin@switch > vrouter-static-bfd-show

There are new parameters for vrouter-interface-config-add, -modify, and -show:

bfd-interval milliseconds

Specify the transmission interval in milliseconds. The default value is 750ms with a range of 200 to 3000 milliseconds.

bfd-min-rx milliseconds

Specify the transmission interval in milliseconds. The default value is 500ms with a range of 200 to 3000 milliseconds.

bfd-multiplier integer

Specify the BFD detection multiplier from 1 to 20. The default value is 3.

Support for Policy-based Routing

Policy-based Routing (PBR) enables flexible packet forwarding and routing through user defined policies. Unlike traditional routing based on destination IP address only, PBR allows you to define routes based on other parameters such as source and destination IP addresses, protocol, or souce and destination port numbers.

Policy-based routes can match packets based on the following criteria:

You configure PBR using vFlow commands. Internally, policy routing of the packets uses a vFlow entry. PBR vFlow entries are created in a new vFlow table, System-L3-L4-PBR.

To enable PBR, use the following command:

system-settings-modify policy-based-routing

 

To disable PBR, use the following command:

system-settings-modify no-policy-based-routing

 

To display the vFlow table, use the following command:

vflow-table-show

switch      name                 flow-max   flow-used flow-tbs-slices capability     flow-profile

-------- --------------------  --------   --------- --------------- -------------  ----------------

Spine1   System-L3-L4-PBR-1-0                                       set-metadata  system=>PBR Table

 

Now you configure a vFlow for the routing policy, using the following syntax:

vflow-create name name-string vrouter-name name-string scope local next-hop-ip gateway-ip-address table-name System-L3-L4-PBR-1-0

 

You can only specify the scope as local.

Cluster Active-Active Routing Support for IPv6 Addresses

With Cluster Active-Active Routing, the router peers act as a proxy for the other router interface DMACs. But if the two routers try to communicate with each other, packets are not routed correctly on the network.

For two vRouters in a cluster pair with cluster active-active routing enabled, when a switch receives a packet with the destination MAC address of the cluster peer, Netvisor attempts to route the packet. For neighbor discovery, IPv6 routing uses Layer 3 packets instead of Layer 2 for ARP communication.

A vRouter sends a neighbor solicitation packet and the peer vRouter responds with neighbor advertisements containing the destination IP address of the other peer router. On the first peer vRouter, the packet destination MAC matches the second peer MAC and the switch routes this packet back to the CPU port of the same switch. There are two copies of a neighbor advertisement packet on the internal port of the second switch and the Netvisor neighbor advertisement packet does not return to the first switch.

To alleviate this issue, Netvisor adds a host route in the hardware for the link-local IPv6 vRouter peer.Now, when the first cluster peer sends a unicast packet with a link-local destination IPv6 address to the second cluster peer, the first cluster peer has this host route entry which properly routes the packet.

 

Support for PIM Source Specific Multicast (PIM-SSM) Forwarding

 

Protocol Independent Multicast (PIM) distributes multicast data using routes gathered by other protocols.

PIM builds and maintains multicast routing trees using reverse path forwarding (RPF) based on a unicast routing table. PIM can use routing tables consisting of OSPF, BGP, RIP, and static routes. Each host (senders and receivers) is associated with a Designated Router (DR) that acts for all directly connected hosts in PIM-SSM transactions.

Netvisor has the following enhancements:

Netvisor OS supports PIM-SSM in a cluster environment by providing active-active multicast forwarding.

Netvisor OS also has enhanced support for mapping IGMPv1 and IGMPv2 requests to specific SSM ranges.

New commands support extended SSM IP addresses. The default IP address is 232.0.0.0/8.

vrouter-pim-ssm-range-add

vrouter-name name-string

Specify the name of the vRouter.

Add the following PIM-SSM arguments:

id id

Specify the ID as a number between 1 and 255.

group ip-address

Specify a group PIM-SSM range IP address. The default is 232.0.0.0

netmask netmask

Specify the netmask. The default is 8.

vrouter-pim-ssm-range-remove

vrouter-name name-string

Specify the name of the vRouter.

Add the following PIM-SSM arguments:

id id

Specify the ID as a number between 1 and 255.

group ip-address

Specify group PIM-SSM range IP address. The default is 232.0.0.0

er-pim-ssm-range-show

vrouter-name name-string

Displays the name of the vRouter.

Add the following PIM-SSM arguments:

id id

Displays  the ID as a number between 1 and 255.

group ip-address

Displays a group IP address. The default is 232.0.0.0

netmask netmask

Displays the netmask. The default is 8.

Configuring PIM-SSM Mapping

 SSM mapping introduces a means for the last hop router to discover sources sending to groups. When SSM mapping is configured, if a router receives an IGMPv1 or IGMPv2 membership report for a particular group G, the router translates this report into one or more (S, G) channel memberships for the well-known sources associated with this group.

The following new commands support this feature:

vrouter-pim-ssm-map-add

vrouter-name name-string

Displays the name of the vRouter.

Add the following PIM-SSM Mapping arguments:

id id

Displays  the ID as a number between 1 and 255.

group ip-address

Displays a group IP address. The default is 232.0.0.0.

netmask netmask

Displays the netmask. The default is 8.

vrouter-pim-ssm-map-remove

vrouter-name name-string

Displays the name of the vRouter.

Add the following PIM-SSM Mapping arguments:

id id

Displays  the ID as a number between 1 and 255.

group ip-address

Displays a group IP address. The default is 232.0.0.0.

netmask netmask

Displays the netmask. The default is 8.

vrouter-pim-ssm-map-add

vrouter-name name-string

Displays the name of the vRouter.

Add the following PIM-SSM Mapping arguments:

id id

Displays  the ID as a number between 1 and 255.

group ip-address

Displays a group IP address. The default is 232.0.0.0.

netmask netmask

Displays the netmask. The default is 8.

Configuring PIM-SSM on vRouter Interfaces

In previous releases, when you configured PIM-SSM on a vRouter, Netvisor applied the configuration to all vRouter interfaces. Now you can configure PIM-SSM on separate vRouter interfaces using the following syntax:

vrouter-interface-add

pim|no-pim

Specify if the vRouter interface is a PIM interface.

pim-dr-priority integer

Specify the direct router (DR) priority as an integer between 1 and 4294967295. Netvisor selects the vRouter interface with higher DR priority as the designated router.

By default, all interfaces are priority 1. In case of same priority, Netvisor selects the vRouter interface with highest network address as DR.

pim-cluster|no-pim-cluster

Specify if you want to provide alternative routing for Layer 3 attached sources for leaf cluster routing configuration. It allows for traffic to failover when a unicast path to the Spine fails.

You can modify or display these parameters using the commands vrouter-interface-modify and vrouter-interface-show.

Support for Active-Active Multicast Routing with VRRP

In the VRRP Spine and Leaf configuration, multi-cast traffic for a source, group, or VLAN, for example <S,G, VLAN> tuple can drop traffic since only one of the multicast routers forwards traffic while the other multicast router is not the DR router for the subnet.

To resolve this issue, configure active-active multicast forwarding to send traffic correctly. In the VRRP Spine and Leaf topology, you must configure both multicast routers as a designated router (DR). Designated Routers are the multicast routers designated to forward traffic to a specific subnet such as a VLAN. By enabling both routers in the Spine and Leaf VRRP topology as DR routers, all multicast routers are aware of the multicast receivers whatever the location in the Spine and Leaf topology.

Configuring active-active routing is simple and dynamic by enabling on a per interface basis. If the interface is a VRRP primary interface, then Netvisor enables active-active multicast forwarding on this interface by automatically designating the interface as the designated router for the Layer 3 subnet, no matter how PIM resolves the interface through the DR election process.

Group membership is not enough to ensure traffic is not black-holed. For a given <S,G,VLAN>, Netvisor routes traffic to the outgoing set of VLANs without causing a PIM assert on the peer or local router. Netvisor routes traffic only to local nodes, and the route excludes cluster link ports on the outgoing interface list.  

The following command displays the interfaces of a PIM multicast router:

vrouter-pim-interface-show

vrouter-name name          local-address index if-state   

------------ ------------- ------------- ----- ----------

vr0          eth0.110      10.16.110.1   0     dr,no-nbrs

vr0          eth0.111      10.16.111.1   1     dr,no-nbrs

vr0          eth0.112      10.16.112.1   2     pim        

vr0          eth0.113      10.16.113.1   3     dr,no-nbrs

vr0          register_vif0 10.16.110.1   4                

vr1          lo0:1         10.16.116.1   0     dr,no-nbrs

vr1          eth1.112      10.16.112.2   1     dr,pim     

vr1          eth0.114      10.16.114.1   2     pim        

vr1          register_vif0 10.16.116.1   3                

vr2          eth1.113      10.16.113.2   0     dr,no-nbrs

vr2          eth1.114      10.16.114.2   1     dr,no-nbrs

vr2          eth0.115      10.16.115.1   2     dr,no-nbrs

vr2          register_vif0 10.16.113.2   3

 

To display PIM neighbors, use the following command:

vrouter-pim-neighbor-show

vrouter-name interface address     neighbor    

------------ --------- ----------- -----------

vr0          eth0.112  10.16.112.1 10.16.112.2

vr0          eth0.113  10.16.113.1 10.16.113.2

vr1          eth1.112  10.16.112.2 10.16.112.1

vr1          eth0.114  10.16.114.1 10.16.114.2

vr2          eth1.113  10.16.113.2 10.16.113.1

vr2          eth1.114  10.16.114.2 10.16.114.1

 

To display the routing state for router or group, use the following command:

vrouter-pim-join-show 224.0.1.0

vrouter-name source        group     incoming-if   outgoing-ifs      joined-ifs

------------ ------------- --------- ------------- ----------------- ----------

vr0          ::            224.0.1.0 register_vif0 eth0.113          eth0.113

vr0          10.16.110.101 224.0.1.0 eth0.110      eth0.113          eth0.113

vr4          ::            224.0.1.0               eth0.125,eth0.127

 

pruned-ifs asserted-ifs leaf-ifs          mrt-state

---------- ------------ ----------------- ------------

                                          wc,rp

                                          spt,cache,sg

                        eth0.125,eth0.127 wc,rp

 

Configuring the Hello Interval for PIM-SSM

You can configure the PIM-SSM Hello Interval using the following command:

vrouter-pim-config-modify

vrouter-name name-string

Specify the vRouter name to modify for PIM-SSM.

query-interval seconds

Specify the query interval from 1 to 300 seconds.

hello-interval seconds

Specify the hello interval  from 1 to 300 seconds.

querier-timeout seconds

Specify the querier timeout from 1 to 900 seconds.

Configuring the Designated Router Priority for PIM-SSM

In a PIM SSM-configured network, a host subscribes to an SSM channel through IGMPv3, announcing a desire to join group G and source S. The directly connected PIM-SSM vRouter, the Designated Router (DR) for the receiver, sends an (S,G) join message to a Reverse Path Forwarding (RPF) neighbor for the source.

To configure the DR for PIM, SSM, use the following command:

vrouter-interface-add

pim-dr-priority integer

Specify the direct router (DR) priority as an integer between 1 and 4294967295. Netvisor selects the vRouter interface with higher DR priority as the designated router.

By default, all interfaces are priority 1. In case of same priority, Netvisor selects the vRouter interface with highest network address as DR.

Virtual Routing and Forwarding (VRF) Support

Netvisor OS supports VRF (virtual routing and forwarding instances) to maintain Layer 3 isolation. VRFs are created without a vRouter and do not support running any routing protocols within the VRF. Locally on each node, for each active VRF instance, hardware VRID is allocated to provide Layer 3 isolation. VRFs provides the capability to route between connected networks by leveraging the Netvisor OS vPort database within the fabric. You configure VRF and an anycast gateway subnets to provide the distributed routing capability for tenant endpoints. The distributed routing capability hosted on each leaf node avoids hair pinning traffic to the centralized vRouter.

Netvisor OS supports anycast gateway routing using a virtual MAC address, anycast gateway MAC address, which is associated with the subnet anycast gateway IP address. Netvisor OS provides a default fabric-wide anycast gateway MAC address, and it is also configurable. Since VRF supports connected networks only, each VRF is provided with a configurable option of VRF gateway which installs a default route to provide connectivity to subnets outside of VRF. For redundancy purposes, two VRF default gateways can be configured per leaf node.

Currently VRF only support IPv4 routing.

Netvisor OS assigns the anycast gateway MAC address to VRF from the MAC address in fabric-anycast-gatway-show output. You can modify the MAC address using the fabric-anycast-gateway-modify command.

The default MAC address for the anycast gateway is 64:0e:94:40:00:02.

Configuring VRF and Distributed Routing with an Anycast Gateway

 

The following commands are used to configure VRF:

vrf-create

name name-string

Specify a name for the VRF.

vnet vnet-name

Specify the name of the VNET to assign the VRF. If you only have a global VNET configured, omit this parameter.

scope local|cluster|fabric

Specify the scope for the VRF.

vrf-gw ip-address

Specify the gateway IP address.

vrf-gw2 ip-address

Specify the second gateway IP address.

vrf-delete

name name-string

Specify a name for the VRF.

vnet vnet-name

Specify the name of the VNET to assigned the VRF.

vrf-modify

name name-string

Specify a name for the VRF.

vnet vnet-name

Specify the name of the VNET to assign the VRF.

scope local|cluster|fabric

Specify the scope for the VRF.

vrf-gw ip-address

Specify the gateway IP address.

vrf-gw2 ip-address

Specify the second gateway IP address.

vrf-show

name name-string

Displays the name of the VRF.

vnet vnet-name

Displays the name of the VNET assigned the VRF.

scope local|cluster|fabric

Displays the scope of the VRF.

vrf-gw ip-address

Displays the gateway IP address.

vrf-gw2 ip-address

Displays the second gateway IP address.

The following commands configure the subnet:

subnet-create

name name-string

Specify the name of the subnet.

scope local|cluster|fabric

Specify the scope for the VRF.

vnet vnet-name

Specify the name of the VNET to assign the VRF.

vlan vlan-id

Specify the VLAN ID to assign to the subnet.

vxlan vxlan-id

Specify the VXLAN ID to assign to the subnet.

network ip-address

Specify the network IP address.

netmask netmask

Specify the netmask for the IP address.

vrf name-string

Specify the VRF to assign the subnet.

anycast-gw-ip ip-address

Specify the anycast gateway IP address.

subnet-delete

name name-string

Specify the name of the subnet.

vnet vnet-name

Specify the name of the VNET to assign the VRF.

vrf name-string

Specify the VRF to assign the subnet.

subnet-modify

name name-string

Specify the name of the subnet.

scope local|cluster|fabric

Specify the scope for the VRF.

subnet-show

name name-string

Displays the name of the subnet.

scope local|cluster|fabric

Displays the scope for the VRF.

vnet vnet-name

Displays the name of the VNET to assign the VRF.

vlan vlan-id

Displays the VLAN ID to assign to the subnet.

vxlan vxlan-id

Displays the VXLAN ID to assign to the subnet.

network ip-address

Displays the network IP address.

netmask netmask

Displays the netmask for the IP address.

vrf name-string

Displays the VRF to assign the subnet.

anycast-gw-ip ip-address

Displays the anycast gateway IP address.

state init|ok|vxlan not found|vxlan deactivated| subnet is not installed in hw

Displays the subnet state.

hw-state|no-hw-state

Displays if there is a hardware state present.

The following commands allow you to modify and display anycast gateway information on the fabric:

fabric-anycast-mac-modify

mac mac-address

Modify the MAC address for anycast. The default MAC address is 64:0e:94:40:00:02.

fabric-anycast-mac-show

mac:    64:0e:94:40:00:02

 

Example Configuration 

To add VRF to all switches installed on the network, use the following syntax:

vrf-create name BLUE vnet coke scope [local|fabric|cluster vrf-gw1 100.1.1.1 vrf-gw2 100.1.1.2

 

subnet-create name subnet-1 scope [local|fabric|cluster] vnet coke vxlan 10 network 10.0.10.0/24 vrf BLUE anycast-gateway-ip 10.0.10.1