Nexus Interop 2015

HP-Cisco Data Center
Interoperability Cookbook
April 2015
HP-Cisco Data Center Interoperability Configuration Cookbook
TABLE OF CONTENTS
Introduction................................................................................................................................................................... 3
Interoperability testing.................................................................................................................................................. 5
HP Intelligent Resilient Framework (IRF) and Cisco Virtual PortChannel (vPC)......................................................6
Spanning tree case 1: PVST+.................................................................................................................................13
Spanning tree case 2: MSTP/PVST+.......................................................................................................................18
Spanning tree case 3: MSTP/MSTP.......................................................................................................................22
Link-Layer Discovery Protocol (LLDP)....................................................................................................................26
Cisco Discovery Protocol (CDP).............................................................................................................................28
Jumbo frame switching......................................................................................................................................... 32
Virtual LAN (VLAN) trunking.................................................................................................................................34
Link aggregation.................................................................................................................................................... 37
Jumbo frame routing............................................................................................................................................ 41
OSPFv2 (OSPF for IPv4)..........................................................................................................................................44
OSPFv3 (OSPF for IPv6).........................................................................................................................................55
Border Gateway Protocol (BGP) for IPv4..............................................................................................................66
Border Gateway Protocol-Multiprotocol Extensions (BGP-MP) for IPv6.............................................................76
Appendix A: About Network Test.................................................................................................................................86
Appendix B: Sample Configuration Files......................................................................................................................86
Appendix C: Software Releases Tested........................................................................................................................86
Appendix D: Disclaimer................................................................................................................................................86
ILLUSTRATIONS
Figure 1: The HP-Cisco data center interoperability test bed........................................................................................5

Figure 2: HP IRF and Cisco vPC Topology.......................................................................................................................7
Figure 3: Spanning tree test bed.................................................................................................................................. 14
Figure 4: CDP interoperability test bed........................................................................................................................28
Figure 5: Link aggregation test bed..............................................................................................................................38
Figure 6: Jumbo routing test bed................................................................................................................................. 42
Figure 7: OSPFv2 test bed............................................................................................................................................ 45
Figure 8: OSPFv3 test bed............................................................................................................................................56
Figure 9: BGP interoperability test bed........................................................................................................................67
Figure 10: BGP-MP interoperability test bed...............................................................................................................77
Page 2
Introduction
Objective
This configuration guide aims to help networking professionals interconnect HP Networking and Cisco Nexus
switches using a variety of protocols commonly found in enterprise and service provider data centers. By follow-
ing the step-by-step procedures described in this document, it should be possible to verify interoperability and
to pass traffic between the two vendors’ switches. Further, the procedures described here follow HP’s best
practices for network design and deployment.
Intended audience
This guide is intended for any network architect, administrator, or engineer who needs to interconnect HP and
Cisco Nexus switches in a data center environment.
This guide assumes familiarity with basic Ethernet and TCP/IP networking concepts, as well as at least limited
experience with the HP Networking and Cisco NX-OS command-line interfaces (CLIs). No previous experience is
assumed for the protocols discussed in this document.
For basic TCP/IP networking concepts, the standard references are Internetworking with TCP/IP, Volume 1 by
Douglas E. Comer and TCP/IP Illustrated, Volume 1 by W. Richard Stevens. For multicast topics, Deploying IP
Multicast in the Enterprise by Thomas A. Maufer is a popular choice.
Devices under test

Using the commands given in this document, Network Test has verified interoperability between these devices:
• HP FlexFabric 5700
• HP FlexFabric 5900AF
• HP FlexFabric 5900CP
• Cisco Nexus 5548
Appendix C lists software versions used.
Except where specifically noted, command syntax for HP Networking and Cisco Nexus switches does not change
across product lines. In cases where switches use different command syntax, this is explicitly noted.
Page 3
Conventions used in this document

The following table lists text and syntax conventions.
Conventions Description Examples

Bold Type Represents user-inputted text. To enter configuration mode, type
the system-view command:
<HP5900AF> system-view
Fixed-width text like Represents output that appears <HP7904> display stp bridge
this on the terminal screen.
MSTID Port
Role STP State Protec-
tion
0 Bridge-Aggrega-
tion20 ROOT FOR-
WARDING NONE
0 Ten-GigabitEth-
ernet2/1/0/1:1 DESI
FORWARDING NONE
Italic text like this • Introduces important new A policy term is a named structure
terms that defines match conditions and
• Identifies book titles actions.
• Identifies RFC and Internet- TCP/IP Illustrated Volume 1 by W.

draft titles Richard Stevens.
RFC 4814, Hash and Stuffing: Over-

looked Factors in Network Device
Benchmarking
Page 4
Interoperability testing
For each protocol tested, this document uses a five-section format consisting of objective, technical background,
HP configuration, Cisco configuration, and test validation.
Topology
Except where otherwise noted, engineers used the standard test bed shown in Figure 1 to validate interoperabil-
ity. The test bed uses the two-tier network design commonly found in data centers, with core and top-of-rack
(ToR) switches represented. In this example network, ToR switches (HP FlexFabric 5700, HP FlexFabric 5900AF,
HP FlexFabric 5900CP, HP FlexFabric 5930, Cisco Nexus 5548, and Cisco Nexus 9504) connect to core switches
(HP FlexFabric 7904 and Cisco Nexus 7010). For redundancy, multiple connections exist between switch layers.
Figure 1: The HP-Cisco data center interoperability test bed
Page 5
HP Intelligent Resilient Framework (IRF) and Cisco Virtual PortChannel (vPC)

Objective
To prepare HP FlexFabric 7904 core switches to use IRF for all HP-Cisco data center interoperability tests
To prepare Cisco Nexus 7010 core switches to use vPC for all HP-Cisco data center interoperability tests
Background
HP’s Intelligent Resilient Framework (IRF) technology allows multiple switches to appear to the rest of the net-
work as a single device. IRF not only eliminates the need for spanning tree between HP core devices, but also
results in a single configuration file and a single network element to manage. Further, IRF works at both layer 2
and layer 3. With switch elements combined using IRF, there is one routing table and one process per routing
protocol systemwide.
Cisco’s Virtual PortChannel (vPC) technology allows link aggregation groups to be constructed across multiple
switches.
Topology
For all tests described in this project, two HP FlexFabric 7904 switches will use IRF to appear as a single device.
The Cisco Nexus 7010 switches will use vPC for most tests described here, allowing HP top-of-rack switches to
form link aggregation groups (LAGs) across the two Cisco core switches.
Figure 2 shows the test bed topology using HP IRF and Cisco vPC. The dotted line around the two physical HP
FlexFabric 7904 switches indicates that they appear to the rest of the test bed as one virtual device. With IRF,
both switches use one configuration file and present one link aggregation group to attached devices. Note also
the use of LAGs across the two Cisco Nexus 7010 core chassis. Keepalive traffic between the two Cisco Nexus
7010 devices keeps LAG membership state synchronized.
Procedure
HP Comware commands
IRF setup is a three-step process:

• Configure the IRF priority on each device
• Configure IRF ports on each device
• Connect devices together
First, set membership and priorities for each IRF device. These commands makes the first switch the IRF master.
<HP7904> system-view
[HP7904] irf member 1 priority 1
Page 6
Figure 2: HP IRF and Cisco vPC Topology
On the second HP FlexFabric 7904, these commands make the switch an IRF backup device.
[HP7904] irf member 2 priority 2
Next, set IRF parameters on both switches. The following commands respectively will allow the switches to do
the following:
• Present the same MAC address to external devices at all times (the default expiration time is 6 minutes)
• Enable the auto-updating of boot files for an IRF virtual device
• Enable auto reboot for an IRF fabric merge. Disabled by default, this feature forces an IRF fabric to reboot its
member devices when it is defeated in an IRF master election.
• Disable reporting of link-down events from an IRF virtual device (this is the default)
[HP7904] irf mac-address persistent always

[HP7904] irf auto-update enable
Page 7
[HP7904] irf auto-merge enable

[HP7904] undo irf link-delay
Then, assign inter-switch links to form the IRF fabric. On the first HP FlexFabric 7904 device, the following
commands assign two 40G Ethernet interfaces into the IRF fabric.
[HP7904] irf-port 1/1

[HP7904] port group mdc 1 interface FortyGigE1/1/0/11 mode enhanced
[HP7904] quit
On the second HP FlexFabric 7904 switch, these commands assign two more 40G Ethernet interfaces into the
IRF switch fabric:
[HP7904] irf-port 2/2

[HP7904] quit
The final step is to connect the two switches. After powering down both devices and cabling together their
40-gigabit Ethernet interfaces, restore power to both switches. IRF will form a single switch fabric. Both devices
will appear as a single device to the rest of the network, and will use a single configuration file.
Cisco NX-OS commands
Create a virtual PortChannel (vPC) between the two Nexus 7010 devices. This is a five-step process:
• Enabling vPC capability
• Creating a vPC domain
• Creating a dedicated virtual routing and forwarding (VRF) instance for vPC keepalive traffic (optional)
• Creating a loopback interface for vPC keepalive traffic and (optionally) placing it in the correct VRF instance
• Configuring PortChannels to use vPC
Many features in NX-OS must first be explicitly enabled, including vPC:
N7K-1(config)# feature vpc
Next, create a vPC domain. The IP address given here will be the one assigned to a dedicated vPC loopback
address. The destination IP address must match the vPC loopback address on the other Nexus 7010 switch.
Page 8
N7K-1(config)# vpc domain 1

N7K-1(config-vpc1)# peer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf vpc-keepal-
ive
N7K-1(config-vpc1)# peer-gateway
N7K-1(config-vpc1)# exit
Define a VRF instance for vPC keepalive traffic.
N7K-1(config)# vrf context vpc-keepalive
Define a loopback address to carry vPC keepalive traffic and place it in the correct VRF instance. Note that this
loopback interface uses the source address defined above when creating a vPC domain. Also note the no
shutdown command. In NX-OS, all interfaces must be explicitly enabled.
N7K-1(config)# interface loopback100

N7K-1(config-if)# vrf member vpc-keepalive
N7K-1(config-if)# ip address 1.1.1.1/24
N7K-1(config-if)# no shutdown
Configure PortChannels to use vPC. First, create the PortChannels (essentially, link aggregation groups, similar to
bridge aggregation interfaces for HP FlexFabric switches). Here, PortChannels interface 1 will connect to the
other Nexus 7010 (carrying vPC keepalive traffic), while PortChannels 2-6 will carry traffic to HP FlexFabric
switches.
Note the use of the vpc peer-link statement in PortChannel 1 to indicate it carries vPC keepalive traffic. Note
also that PortChannels 2-6 use vPC IDs equivalent to their PortChannel ID. This particular example defines VLAN
trunk ports and allow traffic from VLAN IDs 200-202, but this is not mandatory. vPC configuration also will work
with access ports.
N7K-1# interface port-channel1

N7K-1# description vPC link to Cisco N7K-2
N7K-1# switchport
N7K-1# switchport mode trunk
N7K-1# spanning-tree port type network
N7K-1# vpc peer-link
N7K-1# description link agg to HP 5700
N7K-1# switchport
N7K-1# switchport trunk allowed vlan 200-202
N7K-1# vpc 2
N7K-1# description link agg to HP 5900AF
Page 9
N7K-1# switchport
N7K-1# vpc 3
N7K-1# description link agg to HP 5900CP
N7K-1# switchport
N7K-1# vpc 4
N7K-1# description link agg to HP 5930
N7K-1# switchport
N7K-1# vpc 5
N7K-1# description to HP 7904 IRF
N7K-1# switchport
N7K-1# vpc 6
This completes vPC configuration for the first Nexus 7010. Now, vPC must also be configured on the second
Nexus 7010 (unlike IRF, each vPC member is a discrete switch with its own configuration file).
Configuration for the second switch is essentially identical except for IP addresses. The second switch uses a dif-
ferent address when setting up the vPC domain: Note that the destination and source addresses are the reverse of
the configuration for the first Nexus 7010.
N7K-2(config)# vpc domain 1

N7K-2(config-vpc1)# peer-keepalive destination 1.1.1.1 source 1.1.1.2 vrf vpc-keepalive
N7K-2(config-vpc1)# peer-gateway
N7K-2(config-vpc1)# exit
The loopback address on the second switch must match the one specified in the vpc domain 1 configuration.
N7K-2(config)# interface loopback100

N7K-2(config-if)# vrf member vpc-keepalive
All other steps for vPC configuration of the second switch are identical to those for the first switch.
Page 10
Validation
For HP FlexFabric devices, the Comware commands display irf, display irf topology, and display
irf configuration will show IRF fabric information. Note that this is the master device in the IRF fabric.
<HP7900> display irf

MemberID Slot Role Priority CPU-Mac Description
*1 0 Master 1 00e0-fc0a-15e0 ---
+2 0 Standby 1 00e0-fc0f-8c19 ---
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The bridge MAC of the IRF is: bcea-fa1d-b2ff

Auto upgrade : yes
Mac persistent : always
Domain ID : 0
Auto merge : yes
<HP7900> display irf topology

Topology Info
-------------------------------------------------------------------------
IRF-Port1 IRF-Port2
MemberID Link neighbor Link neighbor Belong To
2 DIS --- UP 1 00e0-fc0a-15e0
1 UP 2 DIS --- 00e0-fc0a-15e0
<HP7900> display irf configuration

MemberID NewID IRF-Port1 IRF-Port2
1 1 FortyGigE1/1/0/11 disable
FortyGigE1/1/0/12
2 2 disable FortyGigE2/1/0/11
FortyGigE2/1/0/12
Page 11
On Cisco NX-OS switches, the command show vpc brief will display information about VPC status.
N7K-1# show vpc brief
Legend:
(*) - local vpc is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status: success
vPC role : primary
Number of vPC configured : 1
vPC Peer-link status

---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 Po1 up 1,100,200-202
vPC status
----------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
-- ---- ------ ----------- -------------------------- ------------
2 Po2 up success success 200-202
Page 12
Spanning tree case 1: PVST+

Objective
To verify loop prevention between HP FlexFabric and Cisco Nexus switches using Per-VLAN Spanning Tree
protocol (PVST+).
Background
The spanning tree protocol is widely used for loop prevention and redundancy. Most HP Networking switches
support Cisco’s proprietary per-VLAN spanning tree plus (PVST+) mode. Both the “rapid” version of PVST+ and
standards-based rapid spanning tree, defined in IEEE 802.1w, provide much faster convergence time after a link
or device failure than the original 802.1D spanning tree specification.
Network architects can designate a specific switch to act as the root of a spanning tree instance. A best practice
in the data center is to designate a core switch as root.
All participating switches in a spanning tree “elect” a root bridge by selecting the device with the lowest bridge
ID. If all switches have the default bridge ID of 32768, the device with the lowest MAC address will become root.
If a switch is configured with a lower bridge ID, and all other switches have higher bridge ID values (e.g., the
default of 32768), that switch will be elected as root.
In PVST+ and Rapid PVST+, root bridge election works on a per-VLAN basis. Thus, it is possible to designate
different root bridges for different VLANs.
Topology
This example uses redundant paths between all HP FlexFabric and Cisco Nexus switches in the test bed. The
default spanning tree mode in Cisco Nexus switches is that vendor’s proprietary rapid PVST+ (RPVST+). Although
RPVST+ is interoperable with other vendors’ rapid spanning tree implementations, most HP Networking switches
also natively support PVST+.
Figure 3 shows the PVST+ validation test bed. In this example, all switches use VLAN trunking for inter-switch
connectivity, but this is optional. The “VLAN trunking” section of this document covers VLAN configuration.
Note that when VLAN trunking is used, trunk ports must allow traffic from VLAN 1 to allow spanning tree bridg-
ing protocol data unit (BPDU) frames to pass between switches.
Page 13
Figure 3: Spanning tree test bed
Note also that inter-switch links between the core switches – the HP FlexFabric 7904 and the Cisco Nexus 7010
– use link aggregation, while all core-to-ToR links rely on spanning tree for loop prevention. Traffic offered from
the Spirent TestCenter generator/analysis verifies the spanning tree topology.
In this example, the two Cisco Nexus 7010 switches have different priorities for VLANs 200 and 201, forcing
elections of different root bridges for each VLAN.
Procedure
HP Comware commands
This procedure covers configuration of the HP FlexFabric 7904. Configuration commands are identical on other
HP Comware devices.
Rapid PVST is globally defined in Comware.
[HP7904] stp mode pvst
[HP7904] stp global enable
[HP7904] quit
Page 14
This configuration is for the Cisco Nexus 7010. Configuration syntax for other NX-OS devices is identical. Rapid
PVST+ is enabled by default on Cisco NX-OS devices. If it previously has been disabled, it can be re-enabled
with the spanning-tree mode rapid-pvst command.
N7K-1# configure terminal

N7K-1(config)# spanning-tree mode rapid-pvst
Optionally, configure different priorities per VLAN to force election of a root bridge. In this example, the first
Cisco Nexus 7010 will act as the root bridge for VLAN 200, and the second Cisco Nexus 7010 will act as root
bridge for VLAN 201. If either switch fails, the other switch will take over as root, since its configured priority is
still lower than the default bridge ID of 32768.
On the first switch, set priorities for VLANs 200 and 201. Note the lower priority for VLAN 200, which will force
election of this switch as root for this VLAN.
N7K-1(config)# spanning-tree vlan 200 priority 24576

N7K-1(config)# end
On the second Cisco Nexus 7010, enable Rapid PVST+ and set priorities for VLANs 200 and 201. Note that the
priorities are reversed from the first switch, but still use lower bridge IDs than the default of 32768.

N7K-2(config)# end
Validation
HP Comware switches can use the command display stp brief to verify the state of rapid spanning tree. To
get information about one or more specific VLANs, use the display stp vlan <ID> command.
<HP-7904> display stp vlan 200 201

-------[VLAN 200 Global Info]-------
Protocol status : Enabled
Bridge ID : 32768.bcea-fa1d-b2ff
Bridge times : Hello 2s MaxAge 20s FwdDelay 15s
VlanRoot ID/RPC : 24576.f866-f211-3ec3, 1
RootPort ID : 128.31449
BPDU-Protection : Disabled
TC or TCN received : 0
Time since last TC : 5 days 0h:53m:43s
Page 15
----[Port31449(Bridge-Aggregation1)][FORWARDING]----
Port protocol : Enabled
Port role : Root Port
Port ID : 128.31449
Port cost(Legacy) : Config=auto, Active=1
Desg.bridge/port : 24576.f866-f211-3ec3, 144.5
Port edged : Config=disabled, Active=disabled
Point-to-Point : Config=auto, Active=true
Transmit limit : 10 packets/hello-time
Protection type : NONE
Rapid transition : True
Port times : Hello 2s MaxAge 20s FwdDelay 15s MsgAge 0s
..
-------[VLAN 201 Global Info]-------
Protocol status : Enabled
Bridge ID : 32768.bcea-fa1d-b2ff
Bridge times : Hello 2s MaxAge 20s FwdDelay 15s
VlanRoot ID/RPC : 24576.8478-ac11-d1c3, 2
RootPort ID : 128.31452
BPDU-Protection : Disabled
TC or TCN received : 0
Time since last TC : 5 days 0h:53m:43s
----[Port31449(Bridge-Aggregation1)][DISCARDING]----
Port protocol : Enabled
Port role : Alternate Port
Port ID : 128.31449
Port cost(Legacy) : Config=auto, Active=1
Desg.bridge/port : 28672.f866-f211-3ec3, 144.5
Port edged : Config=disabled, Active=disabled
Point-to-Point : Config=auto, Active=true
Transmit limit : 10 packets/hello-time
Protection type : NONE
Rapid transition : True
Port times : Hello 2s MaxAge 20s FwdDelay 15s MsgAge 1s
..
Cisco Nexus switches use the command show spanning-tree to display all spanning-tree state, or show
spanning-tree vlan <ID> to get information about specific VLANs. In these examples, note that switch
“N7K-1” is the root bridge for VLAN 200 and switch “N7K-2” is the root for VLAN 201. As expected with root
bridges, all interfaces should be in forwarding state.
N7K-1-TEST# show spanning-tree vlan 200
VLAN0200
Spanning tree enabled protocol rstp
Root ID Priority 24776
Address f866.f211.3ec3
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Page 16
Bridge ID Priority 24776 (priority 24576 sys-id-ext 200)

Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 2 128.4096 P2p
Eth2/28 Desg FWD 2 128.284 P2p
N7K-02# show spanning-tree vlan 201
VLAN0201
Address 8478.ac11.d1c3


---------------- ---- --- --------- -------- --------------------------------
To verify all switches only send traffic over the spanning tree interfaces in forwarding state, generate a known
quantity of frames from Spirent TestCenter or other source and compare switch interface packet counters with
those sent and received on each interface. Interfaces in blocking state will receive spanning tree BPDU frames
but should transmit no frames.
Page 17
Spanning tree case 2: MSTP/PVST+

Objective
To verify interoperability of multiple spanning tree protocol (MSTP) and per-VLAN spanning tree protocol plus
(PVST+) between HP FlexFabric and Cisco Nexus switches, respectively.
Background
As defined in IEEE specification 802.1s, the multiple spanning tree protocol (MSTP) adds loop prevention and
redundancy on a per-VLAN basis in a vendor-neutral standard. With MSTP, individual spanning tree topologies
can be configured for each VLAN.
The goal of this exercise is to demonstrate interoperability in a multiple-VLAN environment when the HP
FlexFabric and Cisco Nexus switches use different variations of spanning tree: MSTP on HP FlexFabric switches
and Rapid PVST+ on Cisco Nexus switches.
In MSTP and Rapid PVST+, root bridge election works on a per-VLAN basis. Thus, it is possible to designate
different root bridges for different VLANs.
Topology
This example uses the same topology as the first spanning tree test, as shown in Figure 3. There are multiple
VLANs configured on all switches. The VLAN IDs in use are 200 and 201. MSTP is enabled on all the HP switches,
and Rapid PVST+ is enabled on all the Cisco switches.
The links interconnecting each switch are VLAN trunk ports. The “VLAN trunking” section of this document
covers VLAN configuration. Traffic offered from the Spirent TestCenter traffic generator/analyzer verifies the
spanning tree topology in each VLAN.
Procedure
HP Comware commands
MSTP is the default mode on HP Comware switches. Configuration involves definition of one multiple spanning
tree instance per VLAN.
Page 18

[HP7904] stp region-configuration
[HP7904] region-name hp-mstp
[HP7904-mst-region] instance 1 vlan 200
[HP7904-mst-region] active region-configuration
[HP7904-mst-region] quit
[HP7904] quit
This configuration is for the Cisco Nexus 7010. Configuration syntax for other NX-OS devices is identical. Rapid
PVST+ is enabled by default on Cisco NX-OS devices. If it previously has been disabled, it can be re-enabled
with the spanning-tree mode rapid-pvst command.

On the first switch, set priorities for VLANs 200 and 201. Note the lower priority for VLAN 200, which will force
election of this switch as root for this VLAN.

N7K-1(config)# end
On the second Cisco Nexus 7010, enable Rapid PVST+ and set priorities for VLANs 200 and 201. Note that the
priorities are reversed from the first switch, but still use lower bridge IDs than the default of 32768.

N7K-2(config)# end
Validation
HP Comware switches can use the command display stp brief to verify the state of rapid spanning tree.
Page 19
<HP-7904> display stp brief

MST ID Port Role STP State Protection
0 Bridge-Aggregation1 DESI FORWARDING NONE
0 Ten-GigabitEthernet1/1/0/1:3 DESI FORWARDING NONE
Cisco Nexus switches use the command show spanning-tree to display all spanning-tree state, or show
spanning-tree vlan <ID> to get information about specific VLANs. In these examples, note that switch
“N7K-1” is the root bridge for VLAN 200 and switch “N7K-2” is the root for VLAN 201. As expected with root
bridges, all interfaces should be in forwarding state.
N7K-1-TEST# show spanning-tree vlan 200
VLAN0200


---------------- ---- --- --------- -------- --------------------------------
Page 20
N7K-02# show spanning-tree vlan 201
VLAN0201


---------------- ---- --- --------- -------- --------------------------------
To verify all switches only send traffic over the spanning tree interfaces in forwarding state, generate a known
quantity of frames from Spirent TestCenter or other source and compare switch interface packet counters with
those sent and received on each interface. Interfaces in blocking state will receive spanning tree BPDU frames
but should transmit no frames.
Page 21
Spanning tree case 3: MSTP/MSTP

Objective
To verify interoperability of a multiple spanning tree topology between HP FlexFabric and Cisco Nexus switches.
Background
As defined in IEEE specification 802.1s, the multiple spanning tree protocol (MSTP) adds loop prevention and
redundancy on a per-VLAN basis in a vendor-neutral standard. With MSTP, a separate spanning tree topology
can be configured for each VLAN.
MSTP is the default version of spanning tree for HP Comware switches, and is enabled by default.
In MSTP, root bridge election works on a per-VLAN basis. Thus, it is possible to designate different root bridges
for different VLANs.
Topology
This test bed is identical to that used in the previous spanning tree examples (see Figure 3), with one important
exception: MSTP runs on all HP and Cisco switches. This example uses VLAN IDs 200 and 201 on all switches.
Procedure
HP Comware commands
Enable multiple spanning tree. This requires enabling MSTP (the default on HP Comware switches) and configur-
ing one multiple spanning tree instance per VLAN.
[HP7904] stp mode mstp
[HP7904] stp region-configuration
[HP7904] region-name hp-mstp
[HP7904-mst-region] active region-configuration
[HP7904-mst-region] quit
[HP7904] quit
Page 22
This configuration is for the Cisco Nexus 7010. Configuration syntax for other NX-OS devices is identical.
Enable multiple spanning tree. This requires enabling MSTP and configuring one multiple spanning tree instance
per VLAN.

N7K-1(config)# spanning-tree mode mst
N7K-1(config)# spanning-tree mst configuration
N7K-1(config-mst)# name hp-mstp
N7K-1(config-mst)# instance 1 vlan 200
N7K-1(config-mst)# exit
On the first switch, set priorities for MST instances 1 and 2, defined in the previous step. Note the lower priority
for instance 1, which will force election of this switch as root for this instance.
N7K-1(config)# spanning-tree mst 1 priority 24576

N7K-1(config)# end
On the second Cisco Nexus 7010, enable MSTP and set priorities for each VLAN instance. Note that the priorities
are reversed from the first switch, but still use lower bridge IDs than the default of 32768.

N7K-2(config)# spanning-tree mode mst
N7K-2(config)# spanning-tree mst configuration
N7K-2(config-mst)# name hp-mstp
N7K-2(config-mst)# exit
N7K-2(config)# end
Page 23
Validation
HP Comware switches use the command display stp brief to examine spanning tree bridge state.
<HP-7904>display stp brief

MST ID Port Role STP State Protection
0 Bridge-Aggregation1 ROOT FORWARDING NONE
0 Bridge-Aggregation2 ALTE DISCARDING NONE
1 Bridge-Aggregation1 MAST FORWARDING NONE
2 Bridge-Aggregation1 MAST FORWARDING NONE
Cisco Nexus switches use the command show spanning-tree to display all spanning-tree state. In these
examples, note that switch “N7K-1” is the root bridge for MSTP instance 1 (VLAN 200) and switch “N7K-2” is the
root for MSTP instance 2 (VLAN 201). As expected with root bridges, all interfaces should be in forwarding state.
N7K-1# show spanning-tree
..
MST0001
Spanning tree enabled protocol mstp


---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 2000 128.4096 P2p
Po6 Desg FWD 1000 128.4101 P2p Bound(PVST)
Eth2/28 Desg FWD 2000 128.284 P2p Bound(PVST)
Eth2/30 Desg FWD 2000 128.286 P2p Bound(PVST)
Eth2/31 Desg FWD 2000 128.287 P2p
Eth2/32 Desg FWD 2000 128.288 P2p
Page 24
N7K-2# show spanning-tree
..
MST0002
Spanning tree enabled protocol mstp


---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 2000 128.4096 P2p
Po6 Desg FWD 1000 128.4101 P2p Bound(PVST)
Eth1/17 Desg FWD 2000 128.145 P2p
Eth1/19 Desg FWD 2000 128.147 P2p
Eth1/21 Desg FWD 2000 128.149 P2p
Eth1/22 Desg FWD 2000 128.150 P2p
To verify all switches send traffic only over the spanning tree interfaces in forwarding state, generate a known
quantity of frames from Spirent TestCenter or other source to each VLAN and compare switch interface packet
counters with those sent and received on each interface. Interfaces in blocking state will receive spanning tree
BPDU frames but should transmit no frames.
Page 25
Link-Layer Discovery Protocol (LLDP)

Objective
To verify the ability of HP FlexFabric and Cisco Nexus switches to exchange capabilities information using the
Link-Layer Discovery Protocol (LLDP).
Background
LLDP, as described in the IEEE 802.1AB specification, is a standards-based method of exchanging device capa-
bilities. Unlike Cisco Discovery Protocol (CDP), covered elsewhere in this document, LLDP is an open standard,
and thus allows multiple vendors’ devices to exchange capabilities data.
LLDP requires very little configuration. Both HP Comware and Cisco Nexus switches require one command to
enable LLDP.
Topology
The LLDP test bed uses the same topology as the CDP tests, as shown in Figure 4. All HP FlexFabric ToR switch-
es connect to both Cisco Nexus 7010 core switches, while all Cisco Nexus ToR switches connect to the HP 7904
core switch and the Spirent TestCenter instrument.
This example uses VLAN trunking and switched virtual interfaces (SVIs), with IP addresses bound to VLAN
interfaces instead of physical interfaces. Both are optional; LLDP would work equally well without VLAN trunking
or SVIs.
Procedure
HP Comware commands
On HP Comware switches, enable LLDP in a global configuration context.
[HP7904] lldp global enable
[HP7904] quit
In NX-OS, the feature lldp command will globally enable LLDP. No other configuration is needed.

N7K-1(config)# feature lldp
N7K-1(config)# exit
Page 26
Validation
On HP Comware switches, the command “display lldp neighbor-information list” will show informa-
tion about attached devices running LLDP.
<HP-7904> display lldp neighbor-information list

Chassis ID : * -- -- Nearest nontpmr bridge neighbor
# -- -- Nearest customer bridge neighbor
Default -- -- Nearest bridge neighbor
System Name Local Interface Chassis ID Port ID
HP-7904 FGE1/1/0/11 bcea-fa1d-b2ff FortyGigE2/1/0/11
DIA-N5K-04 XGE1/1/0/1:1 002a-6aa0-8286 Eth1/31
DIA-9504-01 XGE1/1/0/1:2 c08c-6063-4eca Ethernet1/47
DIA-N7K-1-N7K-1-TEST XGE1/1/0/9:1 649e-f30a-1f06 Eth2/27
DIA-N7K-02-N7K-1-TEST XGE1/1/0/9:2 e4c7-2215-a782 Eth1/23
DIA-N5K-04 XGE2/1/0/1:1 002a-6aa0-8287 Eth1/32
DIA-9504-01 XGE2/1/0/1:2 c08c-6063-4ecb Ethernet1/48
DIA-N7K-02-N7K-1-TEST XGE2/1/0/9:1 e4c7-2215-a77f Eth1/20
DIA-N7K-1-N7K-1-TEST XGE2/1/0/9:2 649e-f30a-1f05 Eth2/26
The equivalent command on Cisco Nexus devices is “show lldp neighbors”.
N7K-1-TEST# show lldp neighbors

Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
DIA-2960X-01 mgmt0 120 BR Gi1/0/20
DIA-N7K-02-N7K-1-TEST Eth2/25 120 BR Eth1/24
HP-7904 Eth2/26 121 BR Ten-GigabitEthernet2/1/0/9:2
HP-7904 Eth2/27 121 BR Ten-GigabitEthernet1/1/0/9:1
HP-5900 Eth2/28 121 BR Ten-GigabitEthernet1/0/47
HP-5700 Eth2/30 121 BR Ten-GigabitEthernet1/0/51
HP-5930 Eth2/31 121 BR Ten-GigabitEthernet1/0/13:3
HP-5900CP Eth2/32 121 BR Ten-GigabitEthernet1/0/47
Total entries displayed: 8
Page 27
Cisco Discovery Protocol (CDP)

Objective
To verify the ability of HP FlexFabric and Cisco Nexus switches to exchange capabilities information using the
Cisco Discovery Protocol (CDP).
Background
The proprietary Cisco Discovery Protocol (CDP) allows sharing of information, such as port names, IP addresses,
model numbers, and power requirements among connected HP and Cisco devices. Although CDP is a Cisco-
proprietary protocol, HP switches understand it and can share information using the protocol.
CDP requires very little configuration on HP data center switches. On the HP Networking data center switches
tested here, enabling CDP requires as few as three commands.
Topology
Figure 4 shows the CDP test bed topology. The HP FlexFabric 7904 core switches connect to Cisco ToR switches,
while the Cisco Nexus 7010 core switches connect to the HP ToR switches. As in all tests described here, the HP
FlexFabric 7904 uses IRF, so it appears to be a single device to the rest of the test bed.
Figure 4: CDP interoperability test bed
Page 28
In this example, the FlexFabric 7904 is a layer-2 device. All interfaces are members of VLAN 1 (using untagged
traffic), and physical interfaces belong to bridge aggregation groups. These parameters are optional; CDP would
work equally well with VLAN trunking (carrying tagged traffic), and in layer-3 mode, with IP addresses bound
either to physical or VLAN interfaces.
Procedure
HP Comware commands
In a global configuration context, enable logical-layer discovery protocol and CDP.
[HP7904] lldp global enable
[HP7904] lldp compliance cdp
(Optional) For each bridge aggregation group needed, create the bridge group.
[HP7904] interface Bridge-Aggregation1

[HP7904-Bridge-Aggregation1] interface Vlan-interface200
[HP7904-Bridge-Aggregation1] description LAG to Nexus7k
[HP7904-Bridge-Aggregation1] link-aggregation mode dynamic
[HP7904-Bridge-Aggregation1] quit
Repeat as needed for each bridge aggregation group.
Configure one or more physical interfaces to be bridge group members, and enable CDP on each interface. The
command “lldp compliance admin-status cdp txrx” enables CDP, both in transmit and receive modes.
[HP7904] interface Ten-GigabitEthernet1/1/0/9:1

[HP7904-interface Ten-GigabitEthernet1/1/0/9:1] port link-mode bridge
[HP7904-interface Ten-GigabitEthernet1/1/0/9:1] description to N7K-1 (vdc N7K-1-

TEST) int e2/27
[HP7904-interface Ten-GigabitEthernet1/1/0/9:1] lldp compliance admin-status cdp

txrx
[HP7904-interface Ten-GigabitEthernet1/1/0/9:1] port link-aggregation group 1
Repeat as needed for each physical interface that requires CDP.
Cisco devices run CDP by default, and require no additional configuration.
Page 29
Validation
On HP Comware switches, the command “display lldp neighbor list” will show information about
attached devices running CDP.
[HP7904] display lldp neighbor list

Chassis ID : * -- -- Nearest nontpmr bridge neighbor
# -- -- Nearest customer bridge neighbor
Default -- -- Nearest bridge neighbor
System Name Local Interface Chassis ID Port ID
- XGE1/1/0/1:1 DIA-N5K-04(SSI1 Ethernet1/31
742072T)
- XGE1/1/0/1:2 DIA-9504-01(FOX Ethernet1/47
1821H03C)
- XGE1/1/0/9:1 DIA-N7K-1-N7K-1 Ethernet2/27
-TEST(JAF1435AT
TA)
- XGE1/1/0/9:2 DIA-N7K-02-N7K- Ethernet1/23
1-TEST(JAF1711A
PBS)
- XGE2/1/0/1:1 DIA-N5K-04(SSI1 Ethernet1/32
742072T)
- XGE2/1/0/1:2 DIA-9504-01(FOX Ethernet1/48
1821H03C)
- XGE2/1/0/9:1 DIA-N7K-02-N7K- Ethernet1/20
1-TEST(JAF1711A
PBS)
- XGE2/1/0/9:2 DIA-N7K-1-N7K-1 Ethernet2/26
-TEST(JAF1435AT
TA)
Page 30
On Cisco devices, the equivalent command is “show cdp neighbors”. If desired, more information about CDP
neighbors is available on Cisco devices with the “show cdp neighbors detail” command.
N7K-1# show cdp neighbors detail

----------------------------------------
Device ID:DIA-2960X-01
VTP Management Domain Name: DIA
Interface address(es):
IPv4 Address: 1.1.1.2
Platform: N7K-C7010, Capabilities: Router Switch IGMP Filtering Supports-STP-Dis
pute
Interface: Ethernet2/25, Port ID (outgoing port): Ethernet1/24
Holdtime: 139 sec
Version:
Cisco Nexus Operating System (NX-OS) Software, Version 6.2(8)
Advertisement Version: 2
Native VLAN: 1
Duplex: full
MTU: 1500
Mgmt address(es):
IPv4 Address: 1.1.1.2
----------------------------------------
Device ID:bcea-fa1d-b2ff
Interface address(es):
Platform: , Capabilities:
Interface: Ethernet2/26, Port ID (outgoing port): Ten-GigabitEthernet2/1/0/9:2
Holdtime: 99 sec
Version:
Advertisement Version: 2
Native VLAN: 1
----------------------------------------
..
Page 31
Jumbo frame switching

Objective
To validate the ability of HP FlexFabric and Cisco Nexus switches to correctly forward traffic consisting of jumbo
frames.
Background
For many years the IEEE Ethernet specification has defined the maximum length of an Ethernet frame to be 1,518
bytes (or 1,522 bytes with an 802.1Q VLAN tag). The use of jumbo frames – those larger than 1518 bytes – re-
mains nonstandard. However, jumbo frames can improve the performance of applications involving bulk data
transfer, such as backup and disaster recovery.
HP FlexFabric and Cisco Nexus switches both support 9,216-byte jumbo frames, including Ethernet CRC. This
section explains how to configure both vendors’ switches to exchange jumbo frames.
Topology
In this example, the Spirent TestCenter traffic generator offers 9,216-byte jumbo Ethernet frames using a “par-
tially meshed” topology, meaning all traffic offered to ports on HP switches are destined to ports on Cisco
switches and visa-versa. VLAN trunk ports connect the switches and VLAN access ports at the edge accept
untagged jumbo frames. However, the ability to switch jumbo frames does not depend on VLAN tagging. This
example would also work with all interfaces passing untagged traffic.
Figure 1 illustrates the configuration used to validate jumbo frame switching. VLAN trunk ports run between the
core switches, and between core and access switches. All other ports operate in access mode.
Procedure
HP Comware commands
HP Comware switches have jumbo frames enabled by default, so no additional configuration is needed. The
following commands are used to explicitly set the maximum transmission unit (MTU), though this step is optional
unless some MTU other than 9216 is required. The MTU is set in the interface configuration context.
[HP7904-Ten-GigabitEthernet1/1/0/9:1] port link-mode bridge
[HP7904-Ten-GigabitEthernet1/1/0/9:1] jumboframe enable 9216
[HP7904-Ten-GigabitEthernet1/1/0/9:1] description to N7K-1 int e2/27
[HP7904-Ten-GigabitEthernet1/1/0/9:1] port link-type trunk
[HP7904-Ten-GigabitEthernet1/1/0/9:1] port trunk permit vlan 1 200
[HP7904-Ten-GigabitEthernet1/1/0/9:1] port link-aggregation group 1
[HP7904-Ten-GigabitEthernet1/1/0/9:1] quit
Page 32
On Cisco Nexus 5548 switches, jumbo MTUs are set using global policy-map and service-policy com-
mands. First, define a policy-map that defines a jumbo MTU of 9216 bytes.
N5548# configure terminal

N5548(config)# policy-map type network-qos jumbo
N5548(config-policy-map)# class type network-qos class-default
N5548(config-policy-map)# mtu 9216
N5548(config-policy-map)# multicast-optimize
N5548(config-policy-map)# exit
Next, configure a service-policy that applies the policy-map defined in the previous step. This service-policy
applies globally. Cisco Nexus 5548 switches do not accept MTU commands on a per-interface basis.
N5548(config)# system qos

N5548(config-qos)# service-policy type network-qos jumbo
N5548(config-qos)# end
On Cisco Nexus 7010 and Nexus 9504 switches running NX-OS, MTU is set on a per-interface basis.
Configure the physical interface with jumbo frame support with the mtu 9216 command. Note that Cisco NX-OS
requires an explicit no shutdown command to enable interfaces.

N7K-1(config)# interface Ethernet2/27
N7K-1(config-if)# description to HP 7904 Ten-GigabitEthernet1/1/0/9:1
N7K-1(config-if)# switchport
N7K-1(config-if)# switchport mode trunk
N7K-1(config-if)# mtu 9216
N7K-1(config-if)# channel-group 6 mode active
N7K-1(config-if)# exit
Validation
Generating jumbo frames between the attached clients and servers validated the ability of the switches to
exchange jumbo traffic. All switches forwarded all jumbo frames with zero frame loss.
Page 33
Virtual LAN (VLAN) trunking

Objective
To verify interoperability of IEEE 802.1Q VLAN trunking between HP FlexFabric and Cisco Nexus switches using
tagged and untagged traffic.
Background
The IEEE 802.1Q specification defines a method for creating virtual broadcast domains. A 4-byte VLAN header,
usually called a “tag,” allows definition of broadcast domains that may differ from physical switch topology.
Without VLANs, all switch ports are members of the same broadcast domain. With VLAN tagging, a network
manager can set up multiple broadcast domains across switches, and restrict broadcasts for different VLANs on
different ports.
In VLAN terminology, an interface that carries tagged traffic between multiple devices is known as a trunk port.
An interface that accepts untagged traffic is known as an access port. Trunk ports may permit traffic from all
VLANs, or (more commonly) allow traffic only from user-specified VLAN IDs. Trunk ports optionally may also carry
untagged traffic from one VLAN ID, known as the native VLAN.
Topology
This configuration example will validate VLAN trunking interoperability between HP FlexFabric and Cisco Nexus
switches in three ways:
• The switches will forward allowed tagged traffic from multiple VLANs across a trunk port.
• The switches will forward allowed untagged traffic from a native VLAN across a trunk port.
• The switch will not forward disallowed tagged traffic across a trunk port.
The final example above is a negative test to verify that switches with VLAN trunking will forward only traffic
explicitly permitted by the switch configurations.
This test used the standard test bed (see Figure 1). In this example, all interswitch communication is done via
VLAN trunks. The trunk ports on each switch will allow tagged traffic with VLAN IDs 200 and 201, and untagged
traffic from ports with VLAN ID of 202. A fourth VLAN, with an ID of 203, is also defined but the trunk ports are
configured not to allow traffic from that VLAN.
Page 34
Procedure
HP Comware commands
First, define VLANs 200 to 203.
[HP7904] vlan 200 to 203
Then, define a VLAN trunk port that allows tagged traffic from VLANs 200-201, and native untagged traffic on
VLAN 202. Note that traffic from VLAN 203 is not allowed
Note also that traffic from VLAN ID 1 is allowed to enter the trunk port. This is mandatory if spanning tree is
enabled to allow bridge protocol data unit (BPDU) frames to pass.

[HP7904-TenGigabitEthernet1/1/0/9:1] port link-mode bridge
[HP7904-TenGigabitEthernet1/1/0/9:1] description to N7K-1 int e2/27
[HP7904-TenGigabitEthernet1/1/0/9:1] port link-type trunk
[HP7904-TenGigabitEthernet1/1/0/9:1] port trunk permit vlan 1 200 to 202
[HP7904-TenGigabitEthernet1/1/0/9:1] port trunk pvid vlan 202
[HP7904-TenGigabitEthernet1/1/0/9:1] quit
Next, define a VLAN trunk port connected to the Spirent test instrument. Again, the interface will allow tagged
traffic from VLANs 200 and 201, and untagged traffic from native VLAN 202. Traffic carrying VLAN 203 tags is
not allowed. Traffic from VLAN 1 again is allowed, because spanning tree is enabled in this example.
While this configuration uses a single trunk port for inbound traffic, it also could use four access-mode interfaces,
each allowing untagged traffic from one VLAN apiece in the range of VLANs 200 through 203.
[HP7904-TenGigabitEthernet1/1/0/1:3] interface Ten-GigabitEthernet1/1/0/1:3

[HP7904-TenGigabitEthernet1/1/0/1:3] port link-mode bridge
[HP7904-TenGigabitEthernet1/1/0/1:3] description to Spirent
[HP7904-TenGigabitEthernet1/1/0/1:3] port link-type trunk
[HP7904-TenGigabitEthernet1/1/0/1:3] port trunk permit vlan 1 200 to 202
[HP7904-TenGigabitEthernet1/1/0/1:3] port trunk pvid vlan 202
[HP7904-TenGigabitEthernet1/1/0/1:3] quit
Page 35
This configuration is for the Cisco Nexus 7010. Configuration syntax for other NX-OS devices is identical.
First, define VLANs 200 to 203.

N7K-1(config)# vlan 200-203
Then, define a VLAN trunk port that allows tagged traffic from VLANs 200-201, and native untagged traffic on
VLAN 202. Note that traffic from VLAN 203 is not allowed. Note also the explicit no shutdown command, which
is required to enable the interface.

N7K-1(config-if)# switchport trunk native vlan 202
N7K-1(config-if)# switchport trunk allowed vlan 200-202
Next, define a VLAN trunk port connected to the Spirent test instrument. Again, the interface will allow tagged
traffic from VLANs 200 and 201, and untagged traffic from native VLAN 202. Traffic carrying VLAN 203 tags is
not allowed. Again, note the use of a no shutdown statement to enable the interface.
While this configuration uses a single trunk port for inbound traffic, it also could use four access-mode interfaces,
each allowing untagged traffic from one VLAN apiece in the range of VLANs 200 through 203.
N7K-1(config-if)# interface Ethernet2/29

N7K-1(config-if)# description to stc 1/9
N7K-1(config-if)# switchport trunk native vlan 202
N7K-1(config-if)# switchport trunk allowed vlan 200-202
Validation
The Spirent TestCenter traffic generator/analyzer can be configured to offer traffic tagged with VLAN IDs 200
through 203. The expected result is that HP and Cisco switches will forward all traffic from VLANs 200
through 202, and drop all traffic from VLAN 203.
If desired, port mirroring can be enabled on either HP or Cisco switches to verify that the trunk ports carry
tagged traffic VLAN IDs 200-201 and untagged traffic for VLAN ID 202.
Page 36
Link aggregation
Objective
To validate the ability of HP FlexFabric and Cisco Nexus switches to correctly forward traffic over a logical
connection created using IEEE 802.1AX link aggregation.
Background
The IEEE 802.1AX link specification defines a standards-based method for aggregating multiple physical Ether-
net links into a single logical link. The logical link, known as a link aggregation group (LAG), is comprised of
multiple members (physical interfaces on each switch). LAGs may be defined statically or dynamically, the latter
using the link aggregation control protocol (LACP). With LACP enabled, 802.3AX-compliant switches can dynam-
ically add or remove LAG members.
Link aggregation is useful for both increasing bandwidth beyond the limits of single physical interfaces and,
especially when used with LACP, for adding redundancy to network connections.
Topology
In this example, the HP FlexFabric 7904 core switch uses two-member LAGs to exchange traffic with Cisco ToR
switches and with the Cisco Nexus 7010 core switch. The HP ToR switches also use two-member LAGs for
connectivity with the Cisco Nexus 7010. The maximum number of LAG members varies between platforms and
manufacturers. Refer to manufacturers’ datasheets for more information.
Figure 5 shows the topology used to validate link aggregation and LACP functionality. This test deviates from the
standard test bed with the additional of several link aggregation groups.
Procedure
HP Comware commands
On HP FlexFabric switches running Comware, configuring link aggregation is a two-step process. First a virtual
bridge aggregation interface is created. Then physical interfaces (and optionally, VLANs) are associated with the
virtual bridge interface. While this example involves a VLAN trunk, a common use of link aggregation, it is not a
requirement. Also, if individual port configuration is not required, link aggregation configuration requires defini-
tion of a bridge aggregation group; addition of physical ports; and configuration of VLAN trunk ports.
As noted, this example covers configuration of individual ports. First, create the bridge aggregation interfaces.
These examples allow traffic from all VLANs; if desired, selected VLANs can be permitted by explicitly allowing
only those VLAN IDs. This example is for the first LAG. The same commands apply for other LAGs, with different
Bridge-Aggregation IDs applied to each.
[HP7904] interface bridge-aggregation1
[HP7904-bridge-aggregation1] description LAG to Nexus7k
[HP7904-bridge-aggregation1] link-aggregation mode dynamic
[HP7904-bridge-aggregation1] quit
Page 37
Figure 5: Link aggregation test bed
Optionally, configure the hashing algorithm to use for distributing traffic across LAG members. For example, this
command uses a hash of destination and source MAC addresses to assign outgoing traffic to LAG members.

[HP7904-bridge-aggregation1] link-aggregation load-sharing mode destination-mac
source-mac
Next, assign physical interfaces to the bridge aggregation virtual interface. This example is for the links between
the HP FlexFabric 7904 and Cisco Nexus 7010. The same commands apply for LAGs to other switches.
[HP7904] interface Ten-Gigabitethernet 1/1/0/9:1

[HP7904-Ten-Gigabitethernet1/1/0/9:1] description to N7K-1 int e2/27
[HP7904-Ten-Gigabitethernet1/1/0/9:1] link-aggregation group 1
[HP7904-Ten-Gigabitethernet1/1/0/9:1] interface Ten-GigabitEthernet 2/1/0/9:2
[HP7904-Ten-Gigabitethernet2/1/0/9:2] description to N7K-1 int e2/27
[HP7904-Ten-Gigabitethernet2/1/0/9:2] link-aggregation group 1
[HP7904-Ten-Gigabitethernet2/1/0/9:2] quit
Page 38
Note that the LAG encompasses interfaces from different modules. This is considered a best practice. Even if
one module fails, the LAG can continue to operate.
Next, configure VLAN info and port link type on the bridge aggregation interface. This example permits traffic
from all VLANs, but trunk ports can be configured to forward traffic only from specific VLAN IDs. See the “Virtual
LAN (VLAN) Trunking” section for more information.

[HP7904-bridge-aggregation1] port link-type trunk
[HP7904-bridge-aggregation1] port trunk permit vlan all
Cisco Nexus switches, like HP Comware switches, require a two-step process to create a Portchannel.
First, create the link aggregation group. Here we also create a VLAN trunk that allows traffic for all VLANs (due to
the lack of an explicit “switchport trunk allowed” command). The optional vpc 6 statement associates
this interface with a virtual PortChannel (vPC) between two Nexus 7010 switches.
If vPC is in use, these commands are installed on both Cisco Nexus 7010 switches.

N7K-1(config)# interface port-channel6
N7K-1(config-if)# description to HP 7904 IRF
N7K-1(config-if)# vpc 6
Next, add interfaces to the link aggregation group. If vPC is in use, these commands are for the first Nexus 7010:

N7K-1(config-if)# end
If vPC is in use, these commands are for the second Nexus 7010:

Page 39

Validation
The command “display link-aggregation summary” on HP Comware switches will show the status of the
bridge aggregation interfaces. In this example, the LAG called Bridge-Aggregation1 has four members.
<HP-7904> display link-aggregation summary

Aggregation Interface Type:
BAGG -- Bridge-Aggregation, BLAGG -- Blade-Aggregation, RAGG -- Route-Aggregation
Aggregation Mode: S -- Static, D -- Dynamic
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Actor System ID: 0x8000, bcea-fa1d-b2ff
AGG AGG Partner ID Selected Unselected Individual Share

Interface Mode Ports Ports Ports Type
--------------------------------------------------------------------------------
BAGG1 D 0x7f9b, 0023-04ee-be01 4 0 0 Shar
On Cisco Nexus switches, the “show lacp neighbor” command will verify correct operation.
DIA-N7K-1-N7K-1-TEST# show lacp neighbor

Flags: S - Device is sending Slow LACPDUs F - Device is sending Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Po6 neighbors
Partner’s information
Partner Partner Partner
Port System ID Port Number Age Flags
Eth2/27 32768,bc-ea-fa-1d-b2-ff0xe36 20397 SA
LACP Partner Partner Partner

Port Priority Oper Key Port State
32768 0x3 0x3d
Partner’s information
Partner Partner Partner
Port System ID Port Number Age Flags
Eth1/20 32768,bc-ea-fa-1d-b2-ff0x9d 20397 SA
LACP Partner Partner Partner

Port Priority Oper Key Port State
32768 0x3 0x3d
Page 40
Jumbo frame routing

Objective
To validate the ability of HP FlexFabric and Cisco Nexus switches to route traffic consisting of jumbo frames.
Background
For many years the IEEE Ethernet specification has defined the maximum length of an Ethernet frame to be 1,518
bytes (or 1,522 bytes with an 802.1Q VLAN tag). The use of jumbo frames – those larger than 1518 bytes – re-
mains nonstandard. However, jumbo frames are useful in both routed and switched environments for applica-
tions involving bulk data transfer. Further, the open shortest path first (OSPF) routing protocol also requires that
both routers use the same MTU before exchanging routing information.
HP FlexFabric and Cisco Nexus switches both support 9,216-byte jumbo frames, including Ethernet CRC. This
section explains how to configure both vendors’ devices to exchange jumbo frames using IP routing.
Topology
In this example, all HP and Cisco devices use IP addresses to exchange jumbo frames. In this example, engineers
assigned IP addresses to VLANs instead of physical interfaces. However, IP addresses directly assigned to
physical addresses also support jumbo frames.
Figure 6 illustrates the configuration used to validate jumbo frame routing. All devices routed traffic at layer 3 in
this test.
Procedure
HP Comware commands
HP Comware switches have jumbo frames enabled by default, so no additional configuration is needed. The
following commands are used to explicitly set the maximum transmission unit (MTU), though this step is optional
unless some MTU other than 9216 is required. The MTU is set in the interface configuration context.
[HP7904-Ten-GigabitEthernet1/1/0/9:1] jumboframe enable 9216
[HP7904-Ten-GigabitEthernet1/1/0/9:1] description to N7K-1 int e2/27
Page 41
Figure 6: Jumbo routing test bed
On Cisco Nexus 5548 switches, jumbo MTUs are set using global policy-map and service-policy com-
mands. First, define a policy-map that defines a jumbo MTU of 9216 bytes.
N5548# configure terminal

N5548(config)# policy-map type network-qos jumbo
N5548(config-policy-map)# class type network-qos class-default
N5548(config-policy-map)# mtu 9216
N5548(config-policy-map)# multicast-optimize
N5548(config-policy-map)# exit
Next, configure a service-policy that applies the policy-map defined in the previous step. This service-policy
applies globally. Cisco Nexus 5548 switches do not accept MTU commands on a per-interface basis.
Page 42
N5548(config)# system qos

N5548(config-qos)# service-policy type network-qos jumbo
N5548(config-qos)# end
On Cisco Nexus 7010 and Nexus 9504 switches running NX-OS, MTU is set on a per-interface basis.
First, configure the physical interface with jumbo frame support with the mtu 9216 command. Note that Cisco
NX-OS requires an explicit no shutdown command to enable interfaces.

N7K-1(config-if)# switchport trunk allowed vlan 200
Then set up each VLAN for jumbo frames. This is required to route jumbo frames between VLANs. All interfaces
in the VLAN must be set to allow jumbo frames before this command will take effect.
In this example, note that the MTU value of 9,198 bytes is 18 bytes less than the value of 9,216 bytes configured
on the physical interface. In the VLAN interface context, the MTU refers to the IP packet length, and not the
Ethernet frame length (which is 14 bytes of header plus 4 bytes of CRC, for 18 additional bytes). For IP routing
protocols such as IS-IS, OSPF, and BGP, the MTU configured on VLAN interfaces should refer to the IP packet
length. Note also the use of the mandatory no shutdown command to enable the interface.
N7K-1(config)# interface Vlan200

Validation
Generating jumbo frames between the attached clients and servers validated the ability of all devices to route
jumbo traffic across an IP network. All switches forwarded all jumbo frames with zero frame loss.
Page 43
OSPFv2 (OSPF for IPv4)

Objective
To verify that HP FlexFabric and Cisco Nexus switches are able to establish open shortest path first version 2
(OSPFv2) connections, exchange topology information, and forward traffic to networks learned using OSPF.
Background
Intended for use on IPv4 networks, OSPFv2 supports IP subnetting and redistribution of routing information
learned via other protocols. OSPF optionally allows session authentication and uses IP multicast for distribution
of routing updates. RFC 2328 describes OSPFv2.
OSPF uses areas to segment traffic, with area 0 designated as the backbone network. OSPF typically involves
coordination among multiple internal routers; area border routers (ABRs) connected to multiple areas; and
autonomous system boundary routers (ASBRs).
In addition to standard areas, OSPFv2 also defines two special types of areas: Stubs are areas into which informa-
tion on external routes is not sent. Instead, the area border router (ABR) generates a default external route into
the stub area. A Not-So-Stubby-Area (NSSA) is like a stub area, but it can import external routes into the area for
redistribution via OSPF.
Topology
In this example, OSPF runs on the HP FlexFabric 7904 and the Cisco Nexus 5548, Nexus 9504, and both Nexus
7010s. The HP ToR switches use VLANs for connectivity to core switches.
The HP ToR switches support layer-3 routing. In this example, engineers configured VLANs and layer-2 switching
on the HP ToR switches because vPC requires Hot Standby Routing Protocol (HSRP) to present a single IP address
to connected neighbors, and interactions between vPC, HSRP, and routing protocols may introduce unexpected
results. Where layer-3 ToR connectivity is required, a better practice is to configure dedicated layer-3 interfaces on
each connected device. For an example of how to configure OSPFv2 routing on HP ToR switches, see the “Layer-3
ToR Connectivity” section starting on page 51.
Figure 7 illustrates the OSPFv2 test bed. The Spirent TestCenter traffic generator/analyzer also runs OSPFv2, and
advertises networks “behind” each device running OSPF. By sending traffic to all these advertised networks,
Spirent TestCenter verifies that all routers correctly learn and forward traffic.
Although not required, the configuration examples given here are in switch virtual interface (SVI) mode, where IP
addresses are bound to VLAN interfaces rather than physical interfaces. OSPF routing would work equally well
with IP addresses configured directly on physical interfaces.
This example also uses bridge aggregation groups as described in the “Link Aggregation” section of this docu-
ment. Again, this is optional; OSPF routing would work equally well with or without link aggregation.
Note that all IP addresses use the 192.18.x.0/24 format, with a unique third byte for each network. This third byte
is also the VLAN ID. For example, interfaces in the 192.18.200.0/24 network are also members of VLAN 200.
Page 44
Figure 7: OSPFv2 test bed
Procedure
HP Comware commands
In this example, switched virtual interfaces (SVIs) are created using VLAN interfaces. Physical interfaces are then
mapped to the VLAN interfaces. Routing is done between VLAN interfaces on each switch. The following
commands apply to an HP FlexFabric 7900. The syntax is identical for all HP switches in the test bed.
Create the VLANs.
[HP7904] vlan 200 to 201
[HP7904] vlan 213 to 214
Create the switched virtual interfaces and assign IP addresses to each VLAN interface.
[HP7904] interface Vlan-interface200

[HP7904-vlan-interface200] ip address 192.18.200.1 255.255.255.0
[HP7904-vlan-interface200] interface Vlan-interface201
Page 45

[HP7904-vlan-interface214] quit
Optionally, create bridge aggregation groups for redundant connections to other devices. See the “Link Aggre-
gation” section of this document for more details.

[HP7904-bridge-aggregation1] description LAG to N7K_1
[HP7904-bridge-aggregation1] port trunk permit vlan 1 200
[HP7904-bridge-aggregation1] interface Bridge-Aggregation2
[HP7904-bridge-aggregation5] description to Nexus 5k
Associate the physical interfaces with the corresponding SVIs and bridge groups. A statement such as port
trunk permit vlan 213 allows tagged traffic from VLAN 213, while port link-aggregation group 5
binds the physical interface to bridge group 5.

[HP7904-Ten-GigabitEthernet1/1/0/1:1] description to Cisco 5548 e1/31
[HP7904-Ten-GigabitEthernet1/1/0/1:1] port trunk permit vlan 213
[HP7904-Ten-GigabitEthernet1/1/0/1:1] interface Ten-GigabitEthernet1/1/0/1:2
Page 46

[HP7904-Ten-GigabitEthernet1/1/0/1:3] description to Spirent
[HP7904-Ten-GigabitEthernet1/1/0/1:3] port access vlan 201
[HP7904-Ten-GigabitEthernet1/1/0/9:1] description to N7K-1 (vdc N7K-1-TEST) int e2/27
[HP7904-Ten-GigabitEthernet2/1/0/1:1] description link agg to Nexus 5548 int e1/32
[HP7904-Ten-GigabitEthernet2/1/0/1:2] description to 9504 e1/48
[HP7904-Ten-GigabitEthernet2/1/0/9:1] description to N7K-2 e1/20
Configure OSPF routing. Note the use of route summarization; the command “network 192.18.0.0
0.0.255.255” covers all networks in the 192.18.0.0/16 space. If any peers were in noncontiguous address space
(for example, 192.18.1.0/24 and 192.18.3.0/24), then individual “network” statements would be required.
[HP7904] ospf 1
[HP7904-ospf] area 0.0.0.0
Page 47
[HP7904-ospf] network 192.18.0.0 0.0.255.255

[HP7904-ospf] quit
[HP7904] quit
On Cisco Nexus switches, like HP FlexFabric switches, create the VLANs first and then assign physical interfaces
to the VLAN interfaces. The following commands apply to a Cisco Nexus 7010 The syntax is identical for Cisco
Nexus 5548 and Nexus 9504 switches.
Cisco NX-OS requires OSPF to be explicitly enabled with the feature command. Additionally, HSRP must be
enabled to work with vPC.

N7K-1(config)# feature hsrp
N7K-1(config)# feature ospf
Next, create VLANs and VLAN interfaces and assign IP addresses to those interfaces. Note the requirement for
an explicit no shutdown statement to enable each interface. Note also the use of HSRP on VLANs 204 through
207, those connected to the HP ToR switches.
N7K-1(config)# vlan 200-207

N7K-1(config-vlan)# interface Vlan200
N7K-1(config-if)# interface Vlan203
N7K-1(config-if)# hsrp 204
N7K-1(config-if)# preempt delay minimum 180
N7K-1(config-if)# timers 1 3
N7K-1(config-if)# ip 192.18.204.1
N7K-1(config-if)# ip 192.18.205.1
N7K-1(config-if)# ip 192.18.206.1
Page 48
N7K-1(config-if)# ip 192.18.207.1
Optionally, create Portchannels for redundant connections to other devices. See the “Link Aggregation” section
of this document for more details. Note also that these Portchannels make use of Cisco’s vPC feature. See the
“HP IRF and Cisco vPC Configuration” section for more details. In this example, Portchannel 1 carries vPC
keepalive traffic while Portchannels 2 through 6 connect with other switches on the test bed.

N7K-1(config-if)# description vPC link to N7K-2 (vdc N7K-1-TEST)
N7K-1(config-if)# switchport trunk allowed vlan 1,100,200-215
N7K-1(config-if)# spanning-tree port type network
N7K-1(config-if)# vpc peer-link
N7K-1(config-if)# interface port-channel2
N7K-1(config-if)# description link agg to 5700
N7K-1(config-if)# description link agg to 5900CP
Page 49
Next, assign physical interfaces to the VLANs and Portchannels. Note again the requirement for an explicit no
shutdown statement to enable each interface.

N7K-1(config-if)# description VCP link to N7K-2 (vdc N7K-1-TEST) interface e1/24
N7K-1(config-if)# description link agg to 5900 Ten-GigabitEthernet1/0/47
N7K-1(config-if)# description to Spirent TestCenter 1/9
N7K-1(config-if)# switchport access vlan 203
N7K-1(config-if)# description link agg to 5930 interface Ten-GigabitEthernet 1/0/13:3
Page 50
N7K-1(config-if)# description link agg to 5900CP Ten-GigabitEthernet1/0/47
Finally, enable OSPF routing.
N7K-1(config)# router ospf 1

N7K-1(config-ospf)# log-adjacency-changes
N7K-1(config-ospf)# network 192.18.0.0 0.0.255.255 area 0
N7K-1(config-ospf)# end
Layer-3 ToR Connectivity
This section covers OSPFv2 configuration on HP ToR switches. The HP ToR switches used layer-2 VLANs in the
previous example because of the Cisco Nexus 7010’s use of vPC and HSRP.
The following commands are for the HP FlexFabric 5900, but command syntax would be identical on HP FlexFab-
ric 5900CP and HP FlexFabric 5930 switches. The HP FlexFabric 5700 supports RIP but not OSPF.
In this example, a single HP FlexFabric 5900AF and Cisco Nexus 7010 will establish an OSPFv2 adjacency. This
example does not use vPC or HSRP.
HP Comware commands
First, create a switched virtual interface (SVI) using a VLAN interface. A physical interface is then mapped to the
VLAN interface. Routing is done between VLAN interfaces on each switch.
Create the VLAN.
[HP5900] vlan 205
Create a switched virtual interface and assign an IP address to the VLAN interface.

Page 51
Associate one or more physical interfaces with the corresponding SVI. A statement such as port trunk per-
mit vlan 205 allows tagged traffic from VLAN 205.
[HP5900] interface Ten-GigabitEthernet1/0/47

[HP5900-Ten-GigabitEthernet1/0/47] port link-mode bridge
[HP5900-Ten-GigabitEthernet1/0/47] description to N7K-1 2/28
[HP5900-Ten-GigabitEthernet1/0/47] port link-type trunk
[HP5900-Ten-GigabitEthernet1/0/47] port trunk permit vlan 205
[HP5900-Ten-GigabitEthernet1/0/47] quit
Configure OSPF routing. Note the use of route summarization; the command “network 192.18.0.0
0.0.255.255” covers all networks in the 192.18.0.0/16 space. If any peers were in noncontiguous address space
(for example, 192.18.1.0/24 and 192.18.3.0/24), then individual “network” statements would be required.
[HP5900] ospf 1
[HP5900-ospf] area 0.0.0.0
[HP5900-ospf] network 192.18.0.0 0.0.255.255
[HP5900-ospf] quit
[HP5900] quit
OSPF configuration on Cisco Nexus switches is identical to the example given above, with two exceptions:
• vPC is not configured. Each Nexus 7010 is a standalone device.
• HSRP is not configured. The HSRP commands are omitted from the VLAN interface configuration.
to the VLAN interfaces.
Cisco NX-OS requires OSPF to be explicitly enabled with the feature command.

N7K-1(config)# feature ospf
Next, create VLANs and VLAN interfaces and assign IP addresses to those interfaces. In this example, VLAN 200
is for connectivity to the HP FlexFabric 7904, while VLAN 205 is for the link to the HP FlexFabric 5900. Note the
requirement for an explicit no shutdown statement to enable each interface.

N7K-1(config)# vlan 200,205
Page 52

Next, assign physical interfaces to the VLANs. Note again the requirement for an explicit no shutdown state-
ment to enable each interface.

Finally, enable OSPF routing.
N7K-1(config)# router ospf 1

N7K-1(config-ospf)# log-adjacency-changes
N7K-1(config-ospf)# network 192.18.0.0 0.0.255.255 area 0
N7K-1(config-ospf)# end
Page 53
Validation
If the HP and Cisco devices are unable to complete OSPF negotiation, routing adjacencies will remain in the
ExStart state. Fully functional adjacencies will be in the Full state. On a Comware device, the “display ospf
peer” command will verify that an OSPF adjacency has entered OSPF Full state.
<hp7904> display ospf peer
OSPF Process 1 with Router ID 192.18.200.1

Neighbor Brief Information
Area: 0.0.0.0
Router ID Address Pri Dead-Time Interface State
192.18.200.2 192.18.200.2 1 39 Vlan200 Full/BDR
The equivalent command on Cisco Nexus devices is “show ip ospf neighbor”.
N7K-1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface

192.18.200.1 1 FULL/DR 00:00:31 192.18.200.1 Vlan200
To validate the ability of all devices to forward traffic to routes learned via OSPF, the Spirent TestCenter instru-
ment advertised 10 networks to each devices, and then offered traffic to networks “behind” all other devices.
The ability of all devices to forward this traffic to and from all networks without loss is a positive indicator that
OSPF routing works as intended.
Page 54
OSPFv3 (OSPF for IPv6)

Objective
To verify that HP FlexFabric and Cisco Nexus switches are able to establish open shortest path first version 3
(OSPFv3) connections, exchange topology information, and forward traffic to networks learned using OSPF.
Background
OSPFv3 updates the routing protocol for use on IPv6 networks. In a mixed IPv4/IPv6 environment, OSPFv2 must
be used in conjunction with OSPFv3.
While the basic mechanics of OSPF are identical in both versions, OSPFv3 introduces new link-state advertise-
ment (LSA) types; removes addressing semantics from OSPF headers; generalizes flooding; and removes OSPF-
layer authentication, among other changes. RFC 5340 describes OSPFv3.
Topology
In this example, OSPFv3 runs on the HP FlexFabric 7904 and the Cisco Nexus 5548, Nexus 9504, and both Nexus
7010s. The HP ToR switches use VLANs for connectivity to core switches.
to connected neighbors, and interactions between vPC, HSRP, and routing protocols may produce unexpected
each connected device. For an example of how to configure OSPFv3 routing on HP ToR switches, see the “Layer-3
Figure 8 illustrates the OSPFv3 test bed. The Spirent TestCenter traffic generator/analyzer also runs OSPFv3, and
advertises networks “behind” each device running OSPF. By sending traffic to all these advertised networks,
Spirent TestCenter verifies that all routers correctly learn and forward traffic.
Although not required, the configuration examples given here are in switch virtual interface (SVI) mode, where IP
addresses are bound to VLAN interfaces rather than physical interfaces. OSPF routing would work equally well
with IP addresses configured directly on physical interfaces.
Also, for simplicity this section covers only IPv6 and OSPFv3 configuration. Where required, dual-stack environ-
ments can concurrently run OSPFv2 by configuring IPv4 addresses and enabling OSPFv2 as described in the
“OSPFv2 (OSPF for IPv4)” section.
Page 55
Figure 8: OSPFv3 test bed
Procedure
HP Comware commands
In this example, switched virtual interfaces (SVIs) are created using VLAN interfaces. Physical interfaces are then
mapped to the VLAN interfaces. Routing is done between VLAN interfaces on each switch. Unlike OSPFv2,
OSPv3 configuration is done on the actual routable interface. The command ospfv3 1 area 0.0.0.0 indi-
cates OSPFv3 will run with a process ID of 1 in area 0.
The rest of this example uses the HP 7904. The commands are identical for other HP FlexFabric switches running
Comware. The command undo ipv6 nd ra halt enables IPv6 router advertisement messages. Here, the
command is given only on the interface connected with the Spirent TestCenter instrument to allow replies to
neighbor discovery messages. This command should be used wherever neighbor discovery is required.
[HP7904-vlan-interface200] ospfv3 1 area 0.0.0.0
[HP7904-vlan-interface200] ipv6 address 2001:200:200::1/64
[HP7904-vlan-interface200] undo ipv6 nd ra halt
Page 56

[HP7904-vlan-interface214] quit
Optionally, create bridge aggregation groups for redundant connections to other devices. See the “Link Aggre-
gation” section of this document for more details.

Associate the physical interfaces with the corresponding SVIs and bridge groups. A statement such as port
trunk permit vlan 213 allows tagged traffic from VLAN 213, while port link-aggregation group 5
binds the physical interface to bridge group 5.
Note also that the interface to the second Nexus 7010 is in shutdown mode. This example involves an OSPF adja-
cency with one Nexus 7010 on the test bed.

Page 57

[HP7904-Ten-GigabitEthernet2/1/0/1:1] description link agg to Nexus 5548 int e1/32
[HP7904-Ten-GigabitEthernet2/1/0/1:2] description to 9504 e1/48
[HP7904-Ten-GigabitEthernet2/1/0/9:1] shutdown
Page 58

Finally, configure OSPFv3 routing. This example defines OSPFv3 with a process ID of 1.
[HP7904] ospfv3 1
[HP7904-ospfv3] router-id 192.18.200.1
[HP7904-ospfv3] area 0.0.0.0
[HP7904-ospfv3] quit
[HP7904] quit
to the VLAN interfaces. The following commands apply to a Cisco Nexus 7010 The syntax is identical for Cisco
Nexus 5548 and Nexus 9504 switches.
Cisco NX-OS requires OSPFv3 to be explicitly enabled with the feature command. Additionally, HSRP must be
enabled to work with vPC.

N7K-1(config)# feature ospfv3
Next, create VLANs and VLAN interfaces, assign IP addresses, and bind OSPFv3 to those interfaces. Note the
requirement for an explicit no shutdown statement to enable each interface. Note also the use of HSRP on
VLANs 204 through 207, those connected to the HP ToR switches.

N7K-1(config-if)# ipv6 address 2001:200:200::2/64
N7K-1(config-if)# ipv6 router ospfv3 1 area 0.0.0.0
N7K-1(config-if)# hsrp version 2
N7K-1(config-if)# hsrp 204 ipv6
N7K-1(config-if)# ip autoconfig
N7K-1(config-if)# ip 2001:200:204::1
Page 59

N7K-1(config-if)# ip 2001:200:206::1
N7K-1(config-if)# ip 2001:200:206::1
N7K-1(config-if)# ip 2001:200:207::1
Optionally, create Portchannels for redundant connections to other devices. See the “Link Aggregation” section
of this document for more details. Note also that these Portchannels make use of Cisco’s vPC feature. See the
“HP IRF and Cisco vPC Configuration” section for more details.
In this example, Portchannel 1 carries vPC keepalive traffic while Portchannels 2 through 6 connect with other
switches on the test bed.

N7K-1(config-if)# description vPC link to N7K-2 (vdc N7K-1-TEST)
N7K-1(config-if)# spanning-tree port type network
N7K-1(config-if)# vpc peer-link
Page 60

N7K-1(config-if)# description link agg to 5900CP
Next, assign physical interfaces to the VLANs and Portchannels. Note again the requirement for an explicit no
shutdown statement to enable each interface.

Page 61

N7K-1(config-if)# description to Spirent TestCenter 1/9
N7K-1(config-if)# switchport access vlan 203
Finally, enable OSPFv3 routing. This example allows redistribution of routes using a route-map. In this example,
OSPFv3 will redistribute any IPv6 route in the 2001:200/32 address space.
N7K-1(config)# route-map ToR permit 10

N7K-1(config-route-map)# description HP ToR
N7K-1(config-route-map)# match ipv6 address 2001:200::/32
N7K-1(config-route-map)# exit
N7K-1(config)# router ospfv3 1
N7K-1(config-rtr-ospfv3)# log-adjacency-changes
N7K-1(config-rtr-ospfv3)# address-family ipv6 unicast
N7K-1(config-rtr-ospfv3-af)# redistribute direct route-map ToR
N7K-1(config-rtr-ospfv3-af)# end
Page 62
This section covers OSPFv3 configuration on HP ToR switches. The HP ToR switches used layer-2 VLANs in the
The following commands are for the HP FlexFabric 5900, but command syntax would be identical on HP FlexFab-
ric 5900CP and HP FlexFabric 5930 switches. The HP FlexFabric 5700 supports RIP but not OSPF.
In this example, a single HP FlexFabric 5900AF and Cisco Nexus 7010 will establish an OSPFv2 adjacency. This
HP Comware commands
Create the VLAN.
[HP5900] vlan 205
Create a switched virtual interface and assign an IPv6 address to the VLAN interface.

Associate one or more physical interfaces with the corresponding SVI. A statement such as port trunk per-
mit vlan 205 allows tagged traffic from VLAN 205.

Configure OSPFv3 routing. Note that an IPv4 address can serve as the router ID, even in an all IPv6-network.
[HP5900] ospfv3 1
[HP5900-ospfv3] area 0.0.0.0
[HP5900-ospfv3] router-id 192.18.205.2
[HP5900-ospfv3] quit
[HP5900] quit
Page 63
OSPFv3 configuration on Cisco Nexus switches is identical to the example given above, with two exceptions:
Cisco NX-OS requires OSPFv3 to be explicitly enabled with the feature command.

N7K-1(config)# feature ospfv3
Next, create VLANs and VLAN interfaces, assign IPv6 addresses, and bind OSPFv3 to those interfaces. In this
example, VLAN 200 is for connectivity to the HP FlexFabric 7904, while VLAN 205 is for the link to the HP
FlexFabric 5900. Note the requirement for an explicit no shutdown statement to enable each interface.

Next, assign physical interfaces to the VLANs. Note again the requirement for an explicit no shutdown state-
ment to enable each interface.

Page 64
Finally, enable OSPFv3 routing. This example allows redistribution of routes using a route-map. In this example,
OSPFv3 will redistribute any IPv6 route in the 2001:200/32 address space.
N7K-1(config)# route-map ToR permit 10

N7K-1(config-route-map)# description HP ToR
N7K-1(config-route-map)# match ipv6 address 2001:200::/32
N7K-1(config-route-map)# exit
N7K-1(config)# router ospfv3 1
N7K-1(config-ospfv3)# log-adjacency-changes
N7K-1(config-ospfv3)# address-family ipv6 unicast
N7K-1(config-ospfv3-af-inet6)# redistribute direct route-map ToR
N7K-1(config-ospfv3-af-inet6)# end
Validation
If the HP and Cisco devices are unable to complete OSPF negotiation, routing adjacencies will remain in the
ExStart state. Fully functional adjacencies will be in the Full state. On an HP Comware device, the “display
ospfv3 peer” command will verify that an OSPFv3 adjacency has entered OSPF Full state.
<HP7904> display ospfv3 peer
OSPFv3 Process 1 with Router ID 192.18.205.2
Area: 0.0.0.0
-------------------------------------------------------------------------
Router ID Pri State Dead-Time Interface Inst ID
192.18.205.1 1 Full/DR 00:00:33 Vlan205 0
The equivalent command on Cisco Nexus switches is “show ipv6 ospf neighbor”.
N7K-1# show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface

192.18.205.2 1 FULL/BDR 00:00:34 5001 Vlan205
To validate the ability of all devices to forward traffic to routes learned via OSPFv3, the Spirent TestCenter
instrument advertised 10 networks to each devices, and then offered traffic to networks “behind” all other
devices. The ability of all devices to forward all traffic without loss is a positive indicator that OSPFv3 routing
works as intended.
Page 65
Border Gateway Protocol (BGP) for IPv4

Objective
To verify that HP FlexFabric and Cisco Nexus switches are able to establish Border Gateway Protocol (BGP)
connections and exchange topology information over an IPv4 network.
Background
The Border Gateway Protocol (BGP) is the mechanism that connects organizations to the global Internet. As
described in RFC 4271, BGP treats each organization’s network as an “autonomous system” (AS) and connects
that system to all other such systems on the Internet.
BGP has two variants for connectivity inside and outside an AS. For inter-AS connectivity, there is external BGP
(eBGP), where neighboring routers use different AS numbers (ASNs). For intra-AS connectivity, there is internal
BGP (iBGP), where neighboring routers use the same ASN.
Topology
Figure 9 shows the BGP interoperability test bed. This example uses eBGP, with different ASNs configured on HP
and Cisco devices. For iBGP configuration, all devices would use the same ASN. In this example, eBGP runs on the
HP FlexFabric 7904 and the Cisco Nexus 5548, Nexus 9504, and both Nexus 7010s.
The HP ToR switches also support layer-3 routing. In this example, engineers configured VLANs and layer-2
switching on the HP ToR switches because vPC requires Hot Standby Routing Protocol (HSRP) to present a single
IP address to connected neighbors, and interactions between vPC, HSRP, and routing protocols may introduce
unexpected results. Where layer-3 ToR connectivity is required, a better practice is to configure dedicated layer-3
interfaces on each connected device. For an example of how to configure BGP routing on HP ToR switches, see
the “Layer-3 ToR Connectivity” section starting on page 72.
This example focuses on BGP configuration for the HP 7904 and one of the Cisco Nexus 7010 data center
switches. BGP configuration commands are identical for other switches running HP Comware or Cisco NX-OS.
Do not use the ASNs given in this example except in controlled lab networks with no Internet connectivity. For
ASNs to use in production networks, contact a regional Internet registry (RIR) such as the American Registry for
Internet Numbers (ARIN).
Page 66
Figure 9: BGP interoperability test bed
Procedure
HP Comware commands
Create a loopback address and assign an IP address to that interface. This step is optional with directly connect-
ed devices, but a loopback interface will ensure the BGP session is available regardless of the state of physical
interfaces.
[HP7904] interface Loopback0
[HP7904-LoopBack0] ip address 2.2.201.1 255.255.255.255
Create the bridge aggregation interfaces for redundant links to other switches. Here, bridge aggregation inter-
faces 1 and 2 respectively will connect to both Cisco Nexus 7010s.
[HP7904-LoopBack0] interface Bridge-Aggregation1

[HP7904-Bridge-Aggregation1] description LAG to N7K_1
[HP7904-Bridge-Aggregation1] port link-type trunk
Page 67
[HP7904-Bridge-Aggregation1] port trunk permit vlan 1 200

[HP7904-Bridge-Aggregation1] interface Bridge-Aggregation2
Create one or more VLANs and assign an IP address to each VLAN interface.
[HP7904] vlan 200

[HP7904-Vlan] interface Vlan-interface200
[HP7904-Vlan-interface200] ip address 192.18.200.1 255.255.255.0
Associate one or more physical interfaces with the VLAN interfaces. Note that all physical interfaces connected
to other switches also are associated with bridge aggregation groups. The two interfaces connected to the
Spirent test instrument are in VLAN access mode, and are not members of bridge aggregation groups. This
example involves BGP peering with one Nexus 7010 on the test bed.
[HP7904-Vlan-interface200] interface Ten-GigabitEthernet1/1/0/9:1

Next, configure BGP. This example uses AS number 2011, assigns a router ID, and explicitly defines which BGP
neighbors can share routing information. Note the use of description labels to identify peers.
Page 68
[HP7904] bgp 2011

[HP7904-bgp2011] router-id 2.2.201.1
[HP7904-bgp2011] peer 192.18.200.2 as-number 2031
[HP7904-bgp2011] peer 192.18.200.2 description Nexus7k_1
[HP7904-bgp2011] peer 192.18.200.2 connect-interface Vlan-interface200
Finally, enable the protocols and peers which can use BGP. This example allows IPv4 routing from the Cisco
Nexus 7010 switches on the test bed. The import-route direct statement redistributes directly attached
routes into BGP.
[HP7904-bgp2011] address-family ipv4 unicast

[HP7904-bgp2011] import-route direct
[HP7904-bgp2011] peer 192.18.200.2 enable
[HP7904-bgp2011] quit
The following commands apply to a Cisco Nexus 7010. BGP configuration syntax is similar for Nexus 5548 and
Nexus 9504 switches.
NX-OS requires many features to be enabled before they can be configured. In this case, begin by enabling BGP
routing. This scenario also requires these addtional features:
• Hot Standby Routing Protocol (HSRP) for connectivity to the HP ToR switches
• interface-vlan for assignment of IP addresses to VLAN interfaces (called switched virtual interfaces [SVI] in
Cisco terminology)
• Link Aggregation Control Protocol (LACP) to share link state information between members of a link aggre-
gation group (LAG, or “Portchannel” in Cisco terminology)
Here are the commands to enable these features:

N7K-1(config)# feature bgp
N7K-1(config)# feature interface-vlan
N7K-1(config)# feature lacp
interfaces.
Page 69
N7K-1(config)# interface Loopback1

Create VLANs and assign IP addresses to the VLAN interfaces. Again, note the mandatory no shutdown
statement to bring up each interface. Note also the use of HSRP on VLANs 204 through 207, those connected to
the HP ToR switches.
N7K-1(config)# vlan 1,100,200,203-207,210-212,215

N7K-1(config-if)# ip 192.18.204.1
N7K-1(config-if)# ip 192.18.205.1
N7K-1(config-if)# ip 192.18.206.1
N7K-1(config-if)# ip 192.18.207.1
Associate physical interfaces with the VLAN interfaces.

Page 70

Next, configure BGP. This example uses AS number 2031 and explicitly defines which BGP neighbors can share
routing information. Note the use of allowed traffic types through the address-family statement. This state-
ment allows BGP to redistribute IPv4 routes learned from a specific neighbor.
N7K-1(config)# router bgp 2031

N7K-1(config-rtr)# router-id 2.2.203.1
N7K-1(config-rtr)# neighbor 192.18.200.1 remote-as 2011
N7K-1(config-rtr)# description HP7904
N7K-1(config-rtr)# address-family ipv4 unicast
N7K-1(config-rtr-af)# exit
Page 71
This section covers BGP configuration on HP ToR switches. The HP ToR switches used layer-2 VLANs in the
The following commands are for the HP FlexFabric 5900AF, but command syntax would be identical on HP
FlexFabric 5900CP and HP FlexFabric 5930 switches. The HP FlexFabric 5700 supports RIP but not BGP.
In this example, a single HP FlexFabric 5900AF and Cisco Nexus 7010 will establish a BGP peering session. This
HP Comware commands
Create the VLAN.
[HP5900] vlan 205
Create a switched virtual interface and assign an IP address to the VLAN interface. This example assumes the HP
FlexFabric 5900AF will use 192.18.205.2 and that the Cisco Nexus 7010 will use 192.18.205.1, both both switches’
interfaces as members of VLAN 205.

Associate one or more physical interfaces with the corresponding SVI.
A statement such as port trunk permit vlan 205 allows tagged traffic from VLAN 205.

Next, configure BGP. This example uses AS number 2051 on the HP FlexFabric 5900AF, assigns a router ID, and
explicitly defines which BGP neighbors can share routing information. Note the use of description labels to
identify a BGP peer.
Page 72
[HP5900] bgp 2051

[HP5900-bgp2051] router-id 192.18.205.2
Finally, enable the protocols and peers which can use BGP. This example allows IPv4 routing from the Cisco
Nexus 7010 switch. The import-route direct statement redistributes directly attached routes into BGP.

[HP5900-bgp2051] quit
BGP configuration on Cisco Nexus switches is identical to the example given above, with two exceptions:
Cisco NX-OS requires BGP and other required features to be explicitly enabled with the feature command.

interfaces.

Create VLANs and assign IP addresses to the VLAN interfaces. Again, note the mandatory no shutdown
statement to bring up each interface.

Page 73


Next, configure BGP. This example uses AS number 2031 and explicitly defines which BGP neighbors can share
routing information. Note the use of allowed traffic types through the address-family statement. This state-
ment allows BGP to redistribute IPv4 routes learned from a specific neighbor.

N7K-1(config-rtr)# log-neighbor-changes
N7K-1(config-rtr)# neighbor 192.18.205.2 remote-as 2051
Page 74
Validation
In Comware, the command “display bgp peer ipv4” will display information about BGP neighbors. Note
that all BGP sessions are in “established” state.
<HP7904> display bgp peer ipv4
BGP local router ID: 192.18.205.2

Local AS number: 2051
Total number of peers: 1 Peers in established state: 1
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
2.2.205.1 2031 34 40 0 6000 00:24:32 Established
In Cisco NX-OS, the command “show ip bgp summary” will display information about BGP neighbors.
N7K-1# show ip bgp summary

BGP router identifier 2.2.205.1, local AS number 2031
..
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/

PfxRcd
192.18.205.2 4 2051 40 35 11001 0 0 00:25:01 6000
Page 75
Border Gateway Protocol-Multiprotocol Extensions (BGP-MP) for IPv6

Objective
To verify that HP FlexFabric and Cisco Nexus switches are able to establish Border Gateway Protocol (BGP)
connections and exchange topology information over an IPv6 network.
Background
RFC 4760 describes BGP-MP, a set of multiprotocol extensions to BGP for carrying topology information about
multiple network-layer protocols, including IPv6. In most respects BGP-MP for IPv6 is similar to its IPv4 counter-
part. BGP-MP still treats each organization’s network as an “autonomous system” (AS), and still uses eBGP and
iBGP variants for inter- and intra-AS connectivity respectively.
Topology
Figure 10 shows the BGP-MP interoperability test bed. This example uses eBGP, with different ASNs configured on
HP and Cisco devices. For iBGP configuration, all devices would use the same ASN. In this example, eBGP runs on
the HP FlexFabric 7904 and the Cisco Nexus 5548, Nexus 9504, and both Nexus 7010s.
to connected neighbors, and interactions between vPC, HSRP, and routing protocols may introduce unexpected
each connected device. For an example of how to configure BGP-MP routing on HP ToR switches, see the “Layer-3
This example focuses on BGP-MP configuration for the HP 7904 and one of the Cisco Nexus 7010 data center
switches. BGP-MP configuration commands are identical for other switches running HP Comware or Cisco NX-OS.
Do not use the ASNs given in this example except in controlled lab networks with no Internet connectivity. For
ASNs to use in production networks, contact a regional Internet registry (RIR) such as the American Registry for
Internet Numbers (ARIN).
Page 76
Figure 10: BGP-MP interoperability test bed
Procedure
HP Comware commands
ed devices, but a loopback interface will ensure the BGP-MP session is available regardless of the state of
physical interfaces. This particular example uses an IPv4 address for the loopback address, but either IPv4 or
IPv6 addresses would work.
Create the bridge aggregation interfaces for redundant links to other switches. Here, bridge aggregation inter-
faces 1 and 2 respectively will connect to both Cisco Nexus 7010s.
[HP7904-LoopBack0] interface Bridge-Aggregation1

Page 77

[HP7904-Bridge-Aggregation1] interface Bridge-Aggregation2
Create a VLAN and assign an IPv6 address to the VLAN interface. To enable IPv6 neighbor discovery, use the
undo ipv6 nd ra halt command.
[HP7904] vlan 200

[HP7904-Vlan-interface200] ipv6 address 2001:200:200::1/64
[HP7904-Vlan-interface200] undo ipv6 nd ra halt
Associate one or more physical interfaces with the VLAN interface. Note that all physical interfaces connected to
other switches also are associated with bridge aggregation groups. The two interfaces connected to the Spirent
test instrument are in VLAN access mode, and are not members of bridge aggregation groups. Note also that
the interface to the second Nexus 7010 is in shutdown mode. This example involves BGP peering with one Nexus
7010 on the test bed.
[HP7904-Vlan-interface200] interface Ten-GigabitEthernet1/1/0/9:1

[HP7904-Ten-GigabitEthernet2/1/0/9:1] shutdown
Page 78
Next, configure BGP-MP. This example uses AS number 2011, assigns a router ID, and explicitly defines which
BGP-MP neighbors can share routing information. Note the use of description labels to identify peers.
[HP7904] bgp 2011

[HP7904-bgp2011] router-id 2.2.201.1
[HP7904-bgp2011] peer 2001:200:200::2 as-number 2031
[HP7904-bgp2011] peer 2001:200:200::2 description Nexus7k_1
[HP7904-bgp2011] peer 2001:200:200::2 connect-interface Vlan-interface200
Finally, enable the protocols and peers which can use BGP-MP. This example allows IPv6 unicast routing from the
Cisco Nexus 7010 switches on the test bed. The import-route direct statement redistributes directly
attached routes into BGP-MP.

[HP7904-bgp2011] peer 2001:200:200::2 enable
The following commands apply to a Cisco Nexus 7010. BGP-MP configuration syntax is similar for Nexus 5548
and Nexus 9504 switches.
NX-OS requires many features to be enabled before they can be configured. In this case, begin by enabling BGP
routing. The command feature bgp also covers BGP-MP. This scenario also requires these addtional features:
• Hot Standby Routing Protocol (HSRP) for connection to the HP ToR switches
• interface-vlan for assignment of IP addresses to VLAN interfaces (called switched virtual interfaces [SVI] in
Cisco terminology)
• Link Aggregation Control Protocol (LACP) to share link state information between members of a link aggre-
gation group (LAG, or “Portchannel” in Cisco terminology)
Here are the commands to enable these features:

Page 79
physical interfaces. This example uses an IPv4 address, but an IPv4 or IPv6 address would work equally well.

Create one or more VLANs and assign IPv6 addresses to the VLAN interfaces. Again, note the mandatory no
shutdown statement to bring up each interface. Note also the use of HSRP on VLANs 204 through 207, those
connected to the HP ToR switches.
N7K-1(config)# vlan 1,100,200,203-207,210-212,215

N7K-1(config-if)# ip 2001:200:204::1
N7K-1(config-if)# ip 2001:200:205::1
N7K-1(config-if)# ip 2001:200:206::1
N7K-1(config-if)# ip 2001:200:207::1
Page 80

Next, configure BGP-MP. This example uses AS number 2031 and explicitly defines which BGP neighbors can
share routing information.
Note the use of allowed traffic types through the address-family statements. Both statements allow BGP to
redistribute IPv6 routes learned from two specific neighbors.

N7K-1(config-rtr)# neighbor 2001:200:200::1 remote-as 2011
This section covers BGP-MP configuration on HP ToR switches. The HP ToR switches used layer-2 VLANs in the
The following commands are for the HP FlexFabric 5900AF, but command syntax would be identical on HP
FlexFabric 5900CP and HP FlexFabric 5930 switches. The HP FlexFabric 5700 supports RIP but not BGP-MP.
Page 81
In this example, a single HP FlexFabric 5900AF and Cisco Nexus 7010 will establish a BGP peering session. This
HP Comware commands
physical interfaces. This particular example uses an IPv4 address for the loopback address, but either IPv4 or
IPv6 addresses would work.
Create a VLAN and assign an IPv6 address to the VLAN interface. To enable IPv6 neighbor discovery, use the
undo ipv6 nd ra halt command.
[HP5900] vlan 205

[HP5900-Vlan-interface205] ipv6 address 2001:200:205::2/64
[HP5900-Vlan-interface205] undo ipv6 nd ra halt
Associate one or more physical interfaces with the VLAN interface.
[HP5900-Vlan-interface205] interface Ten-GigabitEthernet1/0/47

[HP5900-Ten-GigabitEthernet1/0/47] description to N7K-1 (vdc N7K-1-TEST) int e2/27
[HP5900-Ten-GigabitEthernet1/0/47] port trunk permit vlan 1 205
Next, configure BGP-MP. This example uses AS number 2051, assigns a router ID, and defines which BGP-MP
neighbors can share routing information. Note the use of a description label to identify the BGP-MP peer.
[HP5900] bgp 2051

[HP5900-bgp2051] router-id 2.2.205.2
Page 82
Finally, enable the protocols and peers which can use BGP-MP. This example allows IPv6 unicast routing from the
Cisco Nexus 7010 switches on the test bed. The import-route direct statement redistributes directly
attached routes into BGP-MP.

BGP-MP configuration on Cisco Nexus switches is identical to the example given above, with two exceptions:
Cisco NX-OS requires BGP and other required features to be explicitly enabled with the feature command.

physical interfaces. This example uses an IPv4 address, but an IPv4 or IPv6 address would work equally well.

Create one or more VLANs and assign IPv6 addresses to the VLAN interfaces. Again, note the mandatory no
shutdown statement to bring up each interface.
N7K-1(config)# vlan 1,100,200,203-207,210-212,215

Page 83

N7K-1(config-if)# description to HP 5900 Ten-GigabitEthernet1/0/47
Next, configure BGP-MP. This example uses AS number 2031 and defines which BGP-MP neighbors can share
routing information.
Note the use of allowed traffic types through the address-family statements. Both statements allow BGP to
redistribute IPv6 routes learned from two specific neighbors.

N7K-1(config-rtr)# neighbor 2001:200:205::2 remote-as 2051
Page 84
Validation
In Comware, the command “display bgp peer ipv6” will display information about BGP-MP neighbors.
Note that all BGP sessions are in “established” state.
<HP7904> display bgp peer ipv6
BGP local router ID: 2.2.205.2

Local AS number: 2051
Total number of peers: 1 Peers in established state: 1
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
2.2.205.1 2031 34 40 0 6000 00:24:32 Established
In Cisco NX-OS, the command “show ipv6 bgp summary” will display information about BGP neighbors.
N7K-1# show ipv6 bgp summary

BGP router identifier 2.2.205.1, local AS number 2031
..
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/

PfxRcd
2.2.205.2 4 2051 40 35 11001 0 0 00:25:01 6000
Page 85
Appendix A: About Network Test

Network Test is an independent third-party test lab and engineering services consultancy. Our core competencies
are performance, security, and conformance assessment of networking equipment and live networks. Our clients
include equipment manufacturers, large enterprises, service providers, industry consortia, and trade publications.
Appendix B: Sample Configuration Files

This appendix lists URLs for the HP and Cisco switch files used to verify interoperability. These files are freely
available for download from a public Network Test server. This document, a brief interoperability report, and all
HP and Cisco configuration files are available at http://networktest.com/hpdciop.
Appendix C: Software Releases Tested

This appendix describes the software versions used on the test bed. Network Test conducted all benchmarks in
January and February 2015 at HP’s labs in Houston, Texas, USA.
Component Version
HP FlexFabric 7904 Comware Software, Version 7.1.045, Release 2133
HP FlexFabric 5900AF Comware Software, Version 7.1.045, Release 2416
HP FlexFabric 5900CP Comware Software, Version 7.1.045, Release 2416
Cisco Nexus 7010 NX-OS 6.2(8)
Cisco Nexus 5548 NX-OS 7.1(0)N1(1a)
Cisco Nexus 9504 NX-OS 6.1(2)I2(2)
Spirent TestCenter 4.45
Appendix D: Disclaimer
Network Test Inc. has made every attempt to ensure that all test procedures were conducted with the utmost
precision and accuracy, but acknowledges that errors do occur. Network Test Inc. shall not be held liable for
damages which may result for the use of information contained in this document. All trademarks mentioned in
this document are property of their respective owners.
Version 2015040300. Copyright © 2011-2015 Network Test Inc. All rights reserved.
Network Test Inc.

31324 Via Colinas, Suite 113 • Westlake Village, CA 91362-6761 • USA
+1-818-889-0011 • http://networktest.com • info@networktest.com

Nexus Interop 2015

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nexus Interop 2015

Uploaded by

Copyright:

Available Formats

HP-Cisco Data Center

Figure 1: The HP-Cisco data center interoperability test bed........................................................................................5

Devices under test

Appendix C lists software versions used.

Conventions used in this document

Conventions Description Examples

• Identifies RFC and Internet- TCP/IP Illustrated Volume 1 by W.

RFC 4814, Hash and Stuffing: Over-

Figure 1: The HP-Cisco data center interoperability test bed

HP Intelligent Resilient Framework (IRF) and Cisco Virtual PortChannel (vPC)

IRF setup is a three-step process:

Figure 2: HP IRF and Cisco vPC Topology

[HP7904] irf mac-address persistent always

[HP7904] irf auto-merge enable

[HP7904] irf-port 1/1

[HP7904] irf-port 2/2

Cisco NX-OS commands

Many features in NX-OS must first be explicitly enabled, including vPC:

N7K-1(config)# feature vpc

N7K-1(config)# vpc domain 1

Define a VRF instance for vPC keepalive traffic.

N7K-1(config)# vrf context vpc-keepalive

N7K-1(config)# interface loopback100

N7K-1# interface port-channel1

N7K-2(config)# vpc domain 1

N7K-2(config)# interface loopback100

<HP7900> display irf

The bridge MAC of the IRF is: bcea-fa1d-b2ff

<HP7900> display irf topology

<HP7900> display irf configuration

N7K-1# show vpc brief

vPC Peer-link status

Spanning tree case 1: PVST+

Figure 3: Spanning tree test bed

Rapid PVST is globally defined in Comware.

Cisco NX-OS commands

N7K-1# configure terminal

N7K-1(config)# spanning-tree vlan 200 priority 24576

N7K-2# configure terminal

<HP-7904> display stp vlan 200 201

N7K-1-TEST# show spanning-tree vlan 200

Bridge ID Priority 24776 (priority 24576 sys-id-ext 200)

Interface Role Sts Cost Prio.Nbr Type

N7K-02# show spanning-tree vlan 201

Bridge ID Priority 24777 (priority 24576 sys-id-ext 201)

Interface Role Sts Cost Prio.Nbr Type

Spanning tree case 2: MSTP/PVST+

[HP7904] stp global enable

Cisco NX-OS commands

N7K-1# configure terminal

N7K-1(config)# spanning-tree vlan 200 priority 24576

N7K-2# configure terminal

<HP-7904> display stp brief

N7K-1-TEST# show spanning-tree vlan 200

Bridge ID Priority 24776 (priority 24576 sys-id-ext 200)

Interface Role Sts Cost Prio.Nbr Type

N7K-02# show spanning-tree vlan 201

Bridge ID Priority 24777 (priority 24576 sys-id-ext 201)

Interface Role Sts Cost Prio.Nbr Type

Spanning tree case 3: MSTP/MSTP

Cisco NX-OS commands

N7K-1# configure terminal

N7K-1(config)# spanning-tree mst 1 priority 24576