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 primary 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 primary 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 primary, 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)?
I'm not an HPE Employee
I hope you succeed!
I'm not an HPE Employee
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?
I'm not an HPE Employee
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 Primary and the other 2 are the secondary . One of the secondary 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:
Since'm very grateful for your answer, it is helpful for us
regards!
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.
I'm not an HPE Employee
@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.
I'm not an HPE Employee