Problem with One-to-One vlan mapping

[jqueiroz]

Hi all,

I have a pair of HPE 5940 switches working in IRF, linked to a bunch of Aruba 2930F access switches. This network is working (very) well. My final users on this network (hereafter called "new network") are connected to VLAN 160.

I also have a bunch of H3C S7506E switches that compose my old network, Final users on this network ("old netork") are connected to VLAN 1.

I need to interconnect these two networks transparently, in a way that my buddies can progressively move the workstations on the old network, to the new one, with minimum reconfiguration (or no reconfiguration at all).

The solution I found to do this was to create a LAGG between the two core switches, and stablish a vlan mapping on the 5940 stack.

These are the configurations I used:

[HPE 5940] display current-configuration interface Bridge-Aggregation 100
#
interface Bridge-Aggregation100
description Link c/ Infra antiga
port link-type trunk
port trunk permit vlan 1 to 4094
port trunk pvid vlan 10
vlan mapping 1 translated-vlan 160
link-aggregation mode dynamic
link-aggregation selected-port maximum 4
arp detection trust
#

[H3C-OLDCORE] display current-configuration interface Bridge-Aggregation 100
#
interface Bridge-Aggregation100
description Link com infra nova (HPE 5940) (AGG)
port link-type trunk
port trunk permit vlan 1 to 4094
port trunk pvid vlan 10
link-aggregation mode dynamic
#

My problem is, direct communication between workstations on the old and new network ocurr perfectly, but workstations on the old network can't contact the new core switch. This behavior is preventing me to set up the router interfaces on the new switch, as when I do this, the workstations can't reach the gateway (core router).

So, I'm searching for clues to point me what am I doing wrong, for this not to work.

Thanks in advance for any help.

[parnassus]

Nice idea the VLAN Mapping...it means you uplinked both Cores together remaining on a Layer 2 link (you didn't mention if VLAN 1 and VLAN 160 have the same IP address space)....wouldn't have been better to use a Layer 3 interconnection (so both Cores know each others through proper static routes using an ad-hoc Transit VLAN)? with such connection Hosts on your "old network" will continue to point to their Core and will concurrently be able to connect to any Host hosted on your "new network" served by the new Core...clearly moving an Host from old to new means (re)wiring at some point and means also that you must assign it a new address (if VLAN 160 and your new Core use a new addressing plan) probably through a DHCP Server serving the VLAN 160.

If instead VLAN 1 and VLAN 160 share the same address space...the routing (supposing both Core act as routers for their networks), from the Hosts standpoint, should be one or the other...but here again a Host is on VLAN 1 on the Old Core or is on the VLAN 160 on the new one...it can't be "served" by both Cores.

Hope I didn't miss anything...or misunderstood your approach.

[jqueiroz]

> you didn't mention if VLAN 1 and VLAN 160 have the same IP address space
Yes, they have the very same address space. As I said, I need the migration to have minimum or zero reconfiguration. So, the addresses of the workstations can't be touched [now]. What I haven't said is that a significant amount of the workstations are [historically] configurated with fixed IP addresses.

> wouldn't have been better to use a Layer 3 interconnection (so both Cores know each others through
> proper static routes using an ad-hoc Transit VLAN)?
I did consider this approach. But, the very same address space exists in both networks, and worse, all the workstations need to talk with servers (which were on the old network, and now are on the new one), and reach the firewall, that is still on the old network. I also did consider using NAT, but there are other VLANs that don't need mapping (and where the problem doesn't occur).

> but here again a Host is on VLAN 1 on the Old Core or is on the VLAN 160 on the new one...it can't be "served" by
> both Cores.
No, the hosts will be served by only one core --- either the old, or the new. Only one of them will be active at any time, for each of the VLANs.

My exact problem: right now, I'm trying to switch the old core with the new one. But when I deactivated the routing functions of the old core, the hosts on the old network couldn't reach the new core. I had to rollback the configurations (with a very displeasant downtime).

The problem is certainly related to the vlan mapping, as workstations on the new network can talk to both cores with no problem. Only the workstations on the old network have this problem, and only when the new core is activated.

I scanned the manuals top down again and again, and the only thing I saw was this:

The following features are mutually exclusive with one another on a Layer 2 Ethernet interface or Layer 2 aggregate interface:

• EVB.
• VLAN mapping.
• Binding an Ethernet service instance to a VSI or to an MPLS L2VPN cross-connect.

Do not configure these features simultaneously on the same interface. Otherwise, the features cannot take effect.

https://techhub.hpe.com/eginfolib/networking/docs/switches/5940-5930/5200-4870_l2-lan_cg/content/504652992.htm

I have no EVB, no Ethernet services, neither MPLS L2VPNs. But the mention to VSI gets me confused.

[parnassus]

Hi, could it be something related to what was explained on this HPE KB Article (kc0135457) or I totally misunderstood the whole issue?

[jqueiroz]

Sorry, I don't have access to that material. Can you give me a summary of it?

[parnassus]

Don't you have an account on HPE My Networking Portal (yet)?

Anyway...here it is:

Cheers.

[jqueiroz]

Gotcha. That's exactly the simptoms I see.

By the way, not only the IP address of the translated VLAN is not accessible from the original VLAN, but also any other IP address on the translating switch, on any other VLAN interface.

I tried to sniff the related traffic, and I believe I saw an ARP packet incoming on the test workstation from the HPE 5940, but for some reason the workstation seems not recognize this ARP request [I need to confirm this].

Don't you have an account on HPE My Networking Portal (yet)?

I have the account, but not a support contract.

[jqueiroz]

Well, this is not a solution, but I need to inform it, anyway.

This weekend we moved all the workstations to the new network, so the vlan mapping is no more necessary. It will be removed tomorrow night, so the problem will no more affect us.