problem with MSTP after firmware upgrade on Core1

[bocian]

Hello

Today we will make a Failover test on Core 1 Core 2.

The result MSTP work VRRP VLAN 1 not.

Ping on the VLAN IP Adresses working not (Core 1 VLAN IP Adresses) .

Ping from device VLAN 201 to VLAN 1 works not.

All other VLAN s has no member devices in the moment only VLAN 201 SWITCH Managment and VLAN 1 all clients and servers.

In the future we will clearing the VLAN 1 all devices of vlan 1 will putted in the other vlans.

core are  5412ZL with premium license.

Before, we have problem with VRRP The HP support say Core 1 and Core 2 must have the sam Firmware release.

We make that.

Mstp not working after update.

Before update

Core 1 has Firmware K.15.02.0005

Core 2 has Firmware K.15.04.0003

Edge switch E2910

before update works mstp Core 1 was Root and when core 1 down core 2 is root.

Core 1 running up and was root and core 2 was blocked.

That was good.

After Update Core 1 K.15.04.0003

Core 1 goes down and the Core 2 was blocked on edge.

MSTP not work.

VRRP It's normal that i can't ping the virtual IP when Master is down???

When i make a tracert from VLAN 201 to VLAN 1

tracert 192.70.182.181 then the first hope is 10.42.1.253 (core2)

and then timeout.

I have only devices in VLAN 201 and Vlan 1 all other are has no devices.

I have see that problem an VRRP

VRRP Virtual Router Statistics Information

  Vlan ID                  : 1
  Virtual Router ID        : 1
  State                    : Backup
  Up Time                  : 4 hours
  Virtual MAC Address      : 00005e-000101
  Master's IP Address      : 192.70.182.181
  Associated IP Addr Count : 1          Near Failovers            : 0
  Advertise Pkts Rx        : 13809      Become Master             : 3
  Zero Priority Rx         : 1          Zero Priority Tx          : 0
  Bad Length Pkts          : 0          Bad Type Pkts             : 0
  Mismatched Interval Pkts : 0          Mismatched Addr List Pkts : 61
  Mismatched IP TTL Pkts   : 0          Mismatched Auth Type Pkts : 0

 VRRP Virtual Router Statistics Information

  Vlan ID                  : 2
  Virtual Router ID        : 2
  State                    : Backup
  Up Time                  : 5 hours
  Virtual MAC Address      : 00005e-000102
  Master's IP Address      : 10.42.2.254
  Associated IP Addr Count : 1          Near Failovers            : 1
  Advertise Pkts Rx        : 18803      Become Master             : 7
  Zero Priority Rx         : 1          Zero Priority Tx          : 0
  Bad Length Pkts          : 0          Bad Type Pkts             : 0
  Mismatched Interval Pkts : 0          Mismatched Addr List Pkts : 0
  Mismatched IP TTL Pkts   : 0          Mismatched Auth Type Pkts : 0

the Mismatched Addr List on VRID 1 is not 0.

all other VRID's are =0.

We have for one week changed the VLAN 1 IP adressed form 192.70.182.254 to 192.70.182.181 on core 1 and 192.70.182.253 to 192.70.182.183 on core 2. MSTP running after that.

Is that the Problem of VRRP. MAC ARP TABLE???

Best thanks

And sorry for my english.

[jguse]

Hello,

I think you're running into a configuration issue here. VLAN 201 is set as management VLAN (at least on the edge switch config you provided), which is only for switch management purposes. You shouldn't expect to be able to ping or otherwise get out of it, that's as designed. That's why you see ICMP getting as far as core2, then timing out.

Q: What is a Secure Management VLAN and how would I use it in my network? Could enabling Spanning Tree affect my Secure Management VLAN?
This feature allows a user to set up an isolated network (VLAN) to manage network devices. Access to this Secure Management VLAN, and to the switch's management functions (Menu, CLI, and web browser interface), is available only through ports configured as members of the Secure Management VLAN.

• Multiple ports on the switch can belong to the Secure Management VLAN. This allows you to have multiple management stations accessing the Secure Management VLAN, while at the same time allowing Secure Management VLAN links between switches configured for the same Secure Management VLAN.
• Only traffic from the Secure Management VLAN can manage the switch, which means that only the workstations and PCs connected to ports belonging to the Secure Management VLAN can manage and reconfigure the switch.
• Enabling Spanning Tree may cause loss of connectivity if the port that the Secure Management VLAN is on becomes blocked.

http://www.hp.com/rnd/support/faqs/2650_6108.htm#question23

http://h40060.www4.hp.com/procurve/uk/en/pdfs/application-notes/How_to_configure_Virtual_Router_Redundancy_Protocol_%28VRRP%29_Configuration_note_Sept_08_EMEA_Eng_A4.pd.pdf

Try removing the management-vlan from edge switches and see if that improves your results.

[bocian]

Hello,

You mean I must remove vlan 201 from all edge Switch with feature management VLAN??

No managemt-vlan 201 right??

Is that the problem with VRRP too???

Best thans

Andy

[jguse]

"You mean I must remove vlan 201 from all edge Switch with feature management VLAN??"

No, you can keep the vlan itself, just don't set it as the management VLAN if you want to be able to ping or otherwise reach IPs outside of it.

"No managemt-vlan 201 right??"

Yes, that will do it.

"Is that the problem with VRRP too???"

 It very well could be, at least if I understand your VRRP problem correctly. Pinging the virtual IP should work regardless of whether the owner or backup is running, but it depends on which VLAN's VIP you're pinging from where...

Your default gateway on the edge switch is in the management VLAN too so any traffic is sends to the core will not be able to get out of the VLAN, at least not until you remove the management-vlan option from a VLAN that shouldn't be isolated.

I would recommend reading the following articles for better understanding of implementing VRRP:

http://h40060.www4.hp.com/procurve/uk/en/pdfs/application-notes/How_to_configure_Virtual_Router_Redundancy_Protocol_%28VRRP%29_Configuration_note_Sept_08_EMEA_Eng_A4.pd.pdf

http://h40060.www4.hp.com/procurve/uk/en/pdfs/application-notes/How_to_configure_VRRP_Preempt_Delay_on_ProCurve_switches_Configuration_note_Dec_08_EMEA_Eng_A4.pdf