Comware Based
cancel
Showing results for 
Search instead for 
Did you mean: 

error con switch je072a al conectar una maquina no tiene red

erode
Occasional Advisor

error con switch je072a al conectar una maquina no tiene red

Estimados amigos de la comunidad, tengo 2 switchs
HP je072a conectados por IRF. El firmware que uso es el 1513P99 (ya que tengo otro switch h3c 5120 en IRF y esta es la ultima actualizacion compatible).
El problema es que cuando una maquina se enciende, o se desconecta de la red y se vuelve a conectar, no tiene PING ni acceso dentro de la red, ni tampoco llega a otras VLANs. Luego de 10-15 minutos se normaliza y funciona correctamente.
Otra cosa que sucede es que tengo acceso dentro de la VLAN 192.168.0.0 pero no llego a otras vlan's (10.0.0.0). Es aleatorio, y sucede de repente. Tienen idea que podria ser? La unica forma de solucionarlo "temporalmente" es reiniciando los switchs, pero esto implica dejar sin red a toda la empresa.

Agradezco cualquier tipo de informacion al respecto.

Saludos!

9 REPLIES
erode
Occasional Advisor

error switch je072a

I dear friends of the community, I have 2 switchs HP je072a connected by IRF. The firmware that use is 1513P99 (as I have another switch in IRF h3c 5120 and this is the last update supported). The problem is that when a machine is turned on, or disconnected from the network and reconnects, PING has no access within the network, nor reach other VLANs. After 10-15 minutes it is normalized and working properly. Another thing that happens is that I have access within the VLAN 192.168.0.0 but did not reach other vlan's (10.0.0.0). It is random, and it happens suddenly. They have no idea that it might be? The only way to fix it "temporarily" is restarting the switches, but this means leaving without network throughout the enterprise. I appreciate any information about it. Regards!

parnassus
Honored Contributor

Re: error switch je072a

Shouldn't IRF be deployed using the same (HP-/H3C-) branded fabrics (all IRF members are HP or all IRF members are H3C)?

I ask that because there is an important statement regarding IRF deployment and branding on the HP Brand Migration Feature Guide (about Router & Switch series) of 2012 that says explicitly:

Different Brands used in a single IRF fabric

Some HP, H3C and 3Com switches can form an IRF fabric and their MPUs are interchangeable. If differently branded MPUs are used on your switch or IRF fabric, change the MPU brand to be the same to prevent an active/standby MPU switchover or master re-election from causing network management problems. Network Management systems may detect unexpected changes such as new device information (vendor name, device model, and device panels) changes and force re-collection of information about MPUs and other hardware components. For example, if an IRF fabric uses an HP switch as the master member switch and uses an H3C switch as a subordinate member switch, the network management software will identify the switch as an HP IRF fabric. Then, if the IRF fabric is rebooted and the H3C switch is elected as the master, the network management software will identify the IRF fabric as a new H3C IRF fabric. To avoid this problem, change the brand names of all member switches to be the same.

If I read your description correctly you used two HPE 5120-48G SI Switch code JE072A and a H3C S5120-52P-SI Switch, if so...why not (re)brand the H3C S5120-52P-SI Switch to HP (as per guide above) and then upgrade all three members belonging to your IRF deployment to latest available software version supported (Comware 5.20 R1517) for your Switch model (HPE 5120-48G SI Switch code JE072A...now replaced by the HPE 5130-48G-4SFP+ EI Switch code J934A)?

erode
Occasional Advisor

Re: error switch je072a

Thanks for your answer! make this change and then i'll tell you if could solve.

 

Regards :)

parnassus
Honored Contributor

Re: error switch je072a

I hope you succeed!

erode
Occasional Advisor

Re: error switch je072a

Dear parnassus, could change the brand H3C to HP and then update the firmware to the latest version (1517).

Unfortunately, this problem still occurs. I have armed six VLANs and for any reason, randomly when power a machine, stops having connection with the other VLANs can only see the current vlan. For example, if i am on the network 192.168.0.0 i can not reach the 10.0.0.0 network... and this is solved by rebooting any of the 3 switches. It's very weird. I do not know what to do :(

 

Would appreciate any help in this regard.

 

Regards!

parnassus
Honored Contributor

Re: error switch je072a

OK, let's try to understand exactly what is happening.

You reported two separate issues, the first was:

"The problem is that when a machine is turned on, or disconnected from the network and reconnects, PING has no access within the network, nor reach other VLANs. After 10-15 minutes it is normalized and working properly."

Correct me if I'm wrong: you basically wrote that every time an Host connected to one of your two Switch IRF Cluster (no matter which Switch, right?) power on or when it disconnects (deactivate?) --> reconnects (reactivate?) its Network Interface Card it is then unable to ping [*] other Hosts located within its VLAN or other Hosts located on other VLANs (Routing needed here) you have definded and configured.

Is this description correct?

In my first post I assumed you had problem with one of your Switch not with a Host...but doesn't matter, at least you know have an updated IRF Cluster with the same HPE branded Switches...which is a good thing to start with.

Could you provide IRF configuration of your two Switches?

Could you provide a basic Network Diagram of your setup (with Host, Default Gateway, IRF Switches and all their related links)?

Then you provided a second issue:

"Another thing that happens is that I have access within the VLAN 192.168.0.0 but did not reach other vlan's (10.0.0.0). It is random, and it happens suddenly."

Does the statement above mean that you never had access (routing) to other VLANs or does that statement above mean you have had access but then you suddenly lost that access during time? <-- to solve this second issue you force a reboot of one of the IRF Switches, is this description correct?

[*] Is the Host able to ping its Default Gateway, other Hosts in the same VLAN or what else?

erode
Occasional Advisor

Re: error switch je072a

Dear parnassus, good morning, first of all wanted to thank you for your time and help.

Perhaps my explanation, it was a bit confusing, besides my English is not very good (I am from Argentina). I will be as clear as possible to talk to you about the problem, and then you will attach the network topology you asked.

Well, what happens is the following:

I have three switches, operating in IRF where one is the master and the other 2 are the slave. One of the slave is H3C, which now change the brand to HP and all have the latest firmware available (thanks to you). Within these switches I have armed 5 VLANs:

-a 192.168.0.0/24 which is where all the users (approximately 120 users)
-Another Is the 10.0.0.0/24 where are the servers (about 30)
-Another Is the 192.168.52.0/24 network, in this are the wireless.
Then I have another 2 vlans, with 2 or 3 machines connected, that use for testing.

Well, the problem occurs randomly and presented to users who are on the network 192.168.0.0. at some point of the day, when a user turns on your computer the Windows DHCP server assigned an IP address.
As a gateway, I use the IP address of the HP switch. But I try to ping the gateway (the HP) and I have no answer, I can only see the computers that are in my range, but I have no access to the gateway and thus to other vlans.

During that period, if another computer reboot happens the same, it does not reach the 10.0.0.0 network. It's weird, I have a firewall on the 10.0.0.1 and doing a ping from the firewall to the machine not arrived. Or arrival I have my gateway.

Try looking at the switch, in the part of "ARP" port of the machine, but does not register the MAC address and IP in the ARP table.

When this is happening, all other machines connected on both networks function properly, without presenting any problem. And to solve this, what I do is to restart any of the 3 switches. If the user has a problem, it is in the switch 1, and reset the switch 3, the problem is solved. Any switch to restart solve the problem, temporarily, for a few hours.

This does not happen every day at the same time or on the same machine, it is totally random computer and schedules.

It may be that the IRF ocacione these problems? It would be a good test and disable the switch function independently?

Additionally, I would like adjuntarte a log with some mistakes we made today during a fall.

Also, I attached some pictures on our network topology:1.JPG2.JPG3.JPG4.JPG5.JPG6.JPG7.JPG8.JPG9.JPG

Since'm very grateful for your answer, it is helpful for us :)

regards!

parnassus
Honored Contributor

Re: error switch je072a

OK, the physical topology is basically clear.

You have an IRF virtual device with three identical HPE A5120 SI devices connected using a bus (daisy-chain) topology: member Id 1 has the Master role and is the elected Master (it has the Higher Priority set and is the current Master), members Id 2 and Id 3 have the Slave role.

IRF ports are binded to physical 1G links on each member: IRF Port 1/1 is physical Port 1/0/48 <--> IRF 2/2 is physical Port 2/0/48, IRF 2/1 is physical Port 2/0/47 <--> IRF 3/2 is physical Port 3/0/47.

IRF Ports 1/2 and 3/1 were defined but are disabled and not binded to any physical port.

So when you reboot a Slave member (let's say the member Id 2 or the member Id 3) you're causing an IRF Split condition and multi-active collision occurs and this is not good at all: in case of member Id 3 forced shutdown or reboot then the IRF Port 3/2 fails and so a topology database update happens on the member Id 1 which is the current Master (there is not a new Master Election in your case) and there are traffic disruptions for sure.

You don't have a MAD (Multi Active Detect) mechanism (LACP MAD and/or ARP MAD) against IRF Split Brain scenario, but this is just to say. MAD is not mandatory even if it is highly recommended.

Apart from that the IRF part looks go to me. If there something to check it should be on the routing/Firewall side.

The VLAN and routing part will be more interesting to see (the DHCP Server and your Firewall on 10.0.0.1).

At first sight the active routing table looks strange to me (the Default Route to 10.0.0.1 through VLAN 2 seems to have very low priority - higher value of Preference - and it share that priority - doing a sort of load balancing - with VLAN 6 and 10) but can't say really much interesting now.

parnassus
Honored Contributor

Re: error switch je072a


parnassus wrote:

So when you reboot a Slave member (let's say the member Id 2 or the member Id 3) you're causing an IRF Split condition and multi-active collision occurs and this is not good at all: in case of member Id 3 forced shutdown or reboot then the IRF Port 3/2 fails and so a topology database update happens on the member Id 1 which is the current Master (there is not a new Master Election in your case) and there are traffic disruptions for sure.

What I wrote - above in red - is partially incorrect in terms: forcing a Shutdown or a Reboot of just one Slave of two Slave IRF members (let's say the second slave, the Slave Member Id 3) causes the IRF Stack to partition...that's the IRF Split condition...the Shutdown/Reboot will cause the IRF Stack to loose permanently/temporarily one of its members (and, clearly, any Host served only by that Slave Member will lose its connectivity to the whole network for the entire duration the shutdown/reboot condition exists)...probably this caused event is somewhat better than simply losing IRF ports connectivity (IRF Port 3/2 or 2/1) between Slave Member 3 and Slave Member 2 while the Slave Member Id 3 or 2 remains active.

With the particular case discussed on previous posts (Slave Member 3 rebooted) the IRF Stack will perform a Database Update on remaining active members. Traffic disruption are limited to any Host connected with the Member powered-off or rebooted and, when the Slave Member Id 3 will reconnect, a Topology Convergence happens followed by a Master Election (in the case above the Master doesn't change at all), at the end of these processes the partitioned IRF Stack merges returning to a normal operation for all connected Hosts.