SOLVED
That's interesting.
So no routing between VLAN 2 and VLAN 3 if you test traffic flow between a device connected to, let's say, a VLAN 2 tagged Port on IRF Member 1 and a device connected to, let's say, a VLAN 3 tagged port on IRF Member 2.
Instead if you repeat the same test between two devices both connected to VLAN 2 tagged (different) ports of different IRF Members...the traffic flows.
Normally routing among VLANs (with IP assigned) should work out-of-the-box either if this routing happens within the same IRF Member (among differents VLANs on the same IRF Member) or among IRF Members (among different VLANs on different IRF Members) provided that something (1) doesn't block those VLANs from crossing/traversing the IRF stack (which, I think, could be quite difficult - if not impossible - to achieve), (2) those VLANs (as you wrote are configured) are assigned to ports that belong to all involved IRF Members (as example, VLAN 2 and 3 configured on some ports of IRF Member 1 and 2) and (3) devices you're using to test routing between VLANs are properly configured [*] (pay attention to DHCP and routes). So it should work...
[*] devices that belong respectively to VLAN 2 or VLAN 3 must use respective VLAN 2's (or 3) IP Address as their Next-Hop/Default Gateway IP Address.
I'm not an HPE Employee
Interesting...but then a question: if each involved logical IRF port is binded to multiple physical interfaces (as example: two 10G interfaces per each logical IRF port on each IRF Member of the IRF Stack) then...shouldn't that logical IRF port use the gained physical redundancy and load balancing features to let the IRF Stack to continue to work flawlessly by adapting dynamically the traffic between involved IRF Members even if a physical interface shows an issue (e.g. link broken/interface broken and so on)?
I'm not an HPE Employee
Wait...How your IRF Stack (Daisy Chain IRF Topology I presume) was exactly configured?
If a Daisy-Chain (AKA Bus) IRF Topology was used:
- Which physical port(s) of IRF Member 1 was binded to the logical IRF port 1 on IRF Member 1?
- Which physical port(s) of IRF Member 2 was binded to the logical IRF port 2 on IRF Member 2?
If a (sort of) Ring IRF Topology was used (even if a Ring IRF Topology made with only two IRF Members is really a sort of "double crossed" Daisy Chain IRF Topology):
- Which physical port(s) of IRF Member 1 was binded to logical IRF port 1 on IRF Member 1?
- Which physical port(s) of IRF Member 2 was binded to logical IRF port 2 on IRF Member 2?
- Which physical port(s) of IRF Member 2 was binded to logical IRF port 1 on IRF Member 2?
- Which physical port(s) of IRF Member 1 was binded to logical IRF port 2 on IRF Member 1?
Since you played with a total of four Ten-Gigabit Ethernet ports (two per IRF Member): port 1/0/23 and port 1/0/24 on IRF Member 1, port 2/0/23 and 2/0/24 on IRF Member 2...I presume you chose the Daisy Chain IRF Topology deployed with both ports 1/0/23 and 1/0/24 binded to the same Logical IRF Port 1 on IRF Member 1 - those ports are then physically connected by means of two optical cables via 10G SFP+ Transceivers or by means of two DAC cables - respectively to port 2/0/23 and 2/0/24 both binded to the equivalent Logical IRF Port 2 on IRF Member 2 (so forget about the "double crossed" Ring IRF Topology when you have just two IRF Members only, as I asked above).
Did you deployed IRF Stack that way or what?
I'm not an HPE Employee
If I were you I would go straight with the HP 5820X & 5800 Switch Series IRF Configuration Guide (Configuring IRF on page 11): I would use the IRF Link Redundancy (since you own two good DAC Cables) to deploy a Daisy Chain IRF Topology between your two Switches (this means: on the first Switch do bind two physical 10G ports [so 1/0/23 and 1/0/24 together] to the Logical IRF port 1 on IRF Member 1 and, on the second Switch, do bind two physical 10G ports [so 2/0/23 and 2/0/24 together] to the Logical IRF port 2 on IRF Member 2; no other Logical IRF ports are then required for such Daisy Chain IRF Topology deployment...this is somewhat different with regard to the exampe you followed...in which four Logical IRF ports were created - two per IRF Member - instead of only two really necessary with the used IRF Link Redundancy option).
It's pretty straightforward.
I'm not an HPE Employee
Hi,
Would be good to see the IRF configuration. But from what you post, it looks like you've made a 2 member ring topology.
You could consider using both of the physical links in one IRF logical link. (daisy). Not that it should make a difference.
About the FPP drops. That does seem a bit suspecious. Are those drop-counts growing faster when you're clients are on different vlans? (compared to when they are on the same vlan, where you have normal functionality)
Regards
sdide wrote: You could consider using both of the physical links in one IRF logical link. (daisy). Not that it should make a difference.
Hi S├╕ren! Nice drawing!
For the benefit of the OP...well, a relevant difference...is that the canonical way of configuring a IRF Stack in Daisy Chain when only two members are available (with IRF Link Redundancy at Logical IRF port level, e.g. with two 10G physical ports binded together to one logical IRF port) with respect to the same IRF Stack configured with a "Loop" (without that IRF Link Redundancy at logical IRF port level) where two Logical IRF ports per switch are singularly and respectively binded to a single 10G physical port...that difference grants IRF Links redundancy and IRF Link load balancing (so higher bandwidth: 20Gbps Full Duplex per that single Logical IRF port), the second way (the "Loop" way) provides only IRF Links redundancy and no IRF Link higher bandwidth between the two IRF Members of the stack (10Gbps Full Duplex per single Logical IRF port).
At least this is what I've seen pointed out, more or less recently, here and here.
Personally I don't know how much difference the gained aggregated bandwidth of that single Logical IRF port implies - when only two Switches are involved on a IRF Stack - but *for sure* I prefer to kill two birds with one stone...if that is easily achievable (the OP already used two SFP+ Transceivers per member).
I'm not an HPE Employee