Config migration from Comware 3 to Comware 5 and later to Comware 7

[lorn10]

A hello to all!

I want to discuss here my new little small business project.

As mentioned in the title, - this thread is about the migration of the config of an old defective Comware 3 based 3Com OfficeConnect Gigabit VPN Firewall, 3CREVF100-73. I plan to migrate as a transitional solution to a gigabit upgraded 3Com MSR 20-20 (Comware 5) router. It is a provisional solution because that MSR router will be replaced sometimes this year with a HP MSR1002-4 AC (Comware 7) router (JG875A).

So I need some help in “porting” the old Comware 3 stuff which was implemented over Web UI. The migration from Comware 5 to Comware 7 should be no big problem. However, the translation of the old Comware 3 config to Comware 5 seems more tricky.

As mentioned, the original 3Com Gigabit Firewall Router is defunct. So no access is possible, what I have available is the config as XML file.

I was successful in setting up the MSR 20 router. So I have internet access with IPv4 and IPv6 firewall enabled. In the next step I want to implement the SIP VoIP server (FreePBX) network information.

Regarding the MSR 20 router, GigabitEthernet1/0 is WAN port 3 and connected over a gigabit link to a cable-modem. GigabitEthernet2/0 is the so called “WAN port 4” but acts effectively as the internal LAN port which is connected to the Gigabit Baseline Switch 2928.

The simple network topology looks as follow:

Update 01.05.2020

=> Seperation of FreePBX and Macmini Server into VLAN2

VLAN1

192.168.1.1 => 3Com MSR 20 router (will be replaced later through a HP MSR1002-4)

192.168.1.x => 3Com 4800G PoE switch (48 port) [not present in the test network environment]

192.168.1.x => 3Com Baseline Switch 2928 (16 port)

VLAN2

192.168.2.x => FreePBX Server (virtual)

The VoIP Server (CentOS 6.x based) runs as a virtual client under Mac OS X at:

192.168.2.x => Macmini Server

The main company clients (around five computers) are placed in the range above 192.168.1.50.

All mentioned main network devices and main clients belongs to VLAN1. The new config should implement totally three VLANs, every with his own DHCP. VLAN2 will be with around 20 clients (mainly VoIP phones) the “largest” one. VLAN3 contains the password protected guest WiFi SSID.

VLAN1 => 192.168.1.x

VLAN2 => 192.168.2.x

VLAN3 => 192.168.3.x

Update 02.07.2020:

The Comware 5 config is now mostly finished, see the "solution" for more information.

[Ivan_B]

Hi Lorn10!

Looking at your further posts after this one I can see that you are progressing with your task to migrate the router, I even advised you on one ACL configuration question. I see one active topic here, let's clarify what remains.

As a potential candidate I see this question:

------------
According to the Comware 3 config file, the following ports must / should be reachable from the internet for the address 192.168.2.4:

"SIP" type="1" start-port="5060" finish-port="5060"/>
"RTP" type="1" start-port="10000" finish-port="20000"/>
"UDPTL" type="1" start-port="4000" finish-port="4999"/>

Furthermore I must define the corresponding LAN-WAN rules and the port triggering (to address 192.168.2.4). This seems at newer Comware versions quite different implemented.
------------

Do you still need help with this task?

[lorn10]

Hi Ivan_B

Thanks for your response, - yes I am working on this and any help is welcome.

I have “outsourced” that last open point into a separate thread. I think this is more helpful also for other users.

https://community.hpe.com/t5/comware-based/acl-rule-example-for-sip-voip/td-p/7086878

[Ivan_B]

SIP protocol has two implementations - over UDP (the most common one) and over TCP. Both use port 5060. For the RTP port mapping I suggest using NAT ALG for SIP that will dynamically scan SIP messages and allocate proper UDP ports for RTP communication:

system-view
#
nat alg sip
#
int Gi1/0
 nat server 1 protocol tcp global current-interface 5060 inside 192.168.2.4 5060
 nat server 2 protocol udp global current-interface 5060 inside 192.168.2.4 5060

Also, consider changing both IPv4 and IPv6 ACLs 2000 and delete " rule 10 deny" - it is not needed there. It does not cause any harm, it is just reduntant as it does nothing there - you permit everything with rule 0 and rule 10 will never match.

[lorn10]

Many thanks Ivan_B

I have implemented the suggested changes. So far, that nice little config is working absolutely great!

There remains now only one last point, can someone confirm here that the MSR 20 router series is unable to bind an IP to a MAC address? According to different MSR manuals this should work, - maybe this is true only for higher class MSR routers. (At my old 3Com OfficeConnect Gigabit VPN Firewall this was possible.)

According to the HP A-MSR Layer 3 (c02659312-3) the steps are regarding my config:

system-view

dhcp server ip-pool vlan2 extended

static-bind ip-address 192.168.x.x mask 255.255.255.0

static-bind mac-address 0000-xxxx-xxxx

This results always in an % Unrecognized command found at '^' position error.

Also an alternative Comware command is not working, it ends up with the same message:

user-bind static ip-address 192.168.x.x mac-address 08:00:xx:xx:xx:xx

If that is really a limitation of the MSR 20 series, then I hope that the Comware 7 based HP MSR1002-4 has not the same restrictions.

[Ivan_B]

Could you paste 'display version' output from your router, so I can check? 

Thanks!

[lorn10]

The firmware should be the newest build from 2017:

<3Com MSR20>display version
H3C Comware Platform Software
Comware Software, Version 5.20, Release 2516P13, Standard
Copyright (c) 2004-2017 Hangzhou H3C Tech. Co., Ltd. All rights reserved.
H3C MSR20-20 uptime is 0 week, 1 day, 0 hour, 44 minutes
Last reboot 2020/05/05 15:49:22
System returned to ROM By <Reboot> Command.

CPU type: FREESCALE PowerPC 8248 400MHz
256M bytes SDRAM Memory
4M bytes Flash Memory
Pcb Version: 3.0
Logic Version: 3.0
Basic BootROM Version: 5.00
Extended BootROM Version: 5.00
[SLOT 0]CON (Hardware)3.0, (Driver)1.0, (Cpld)3.0
[SLOT 0]AUX (Hardware)3.0, (Driver)1.0, (Cpld)3.0
[SLOT 0]ETH0/0 (Hardware)3.0, (Driver)1.0, (Cpld)3.0
[SLOT 0]ETH0/1 (Hardware)3.0, (Driver)1.0, (Cpld)3.0
[SLOT 0]CELLULAR0/0 (Hardware)3.0, (Driver)1.0, (Cpld)3.0
[SLOT 1]SIC-1GEC (Hardware)3.0, (Driver)1.0, (Cpld)2.4
[SLOT 2]SIC-1GEC (Hardware)3.0, (Driver)1.0, (Cpld)2.4

<3Com MSR20>

[Ivan_B]

Extended address pools support dynamic address allocation only. Just use this one for dynamic IP address allocation and create additional common address pools - one per statically allocated address as the guide suggests - " A static binding is a special address pool containing only one IP address. " And do not forget to explicitly exclude statically allocated addresses from that extended address pool with "forbidden-ip" command, just to avoid clashes

[lorn10]

Again many thanks Ivan_B for this explanation. I thought that the extended address pool could be the effective reason for that problem.

However, it works now PERFECTLY!

I had also to add at the client-binding pool the corresponding gateway-list and dns-list, - otherwise no Internet access was possible. I should mention that these special address pools work globally across the config. So it is not necessary to apply those to a specific interface. (In my case, that's not possible anyway because for whatever reason I can only bind extended address pools to my sub interfaces.)

dhcp server ip-pool 192.168.1.x

static-bind ip-address 192.168.1.x mask 255.255.255.0

static-bind mac-address xxxx-xxxx-xxxx

gateway-list 192.168.1.1

dns-list 8.8.8.8 8.8.4.4

#

dhcp server ip-pool 192.168.2.x

static-bind ip-address 192.168.2.x mask 255.255.255.0

static-bind mac-address xxxx-xxxx-xxxx

gateway-list 192.168.2.1

dns-list 8.8.8.8 8.8.4.4

All my static IP clients are below the 192.168.x.50 starting range of my DHCP servers. So in my situation the "forbidden-ip" command is not really necessary. Or should I exclude the static addresses despite this?

Whatever, I will update my config file and mark it as solution. As very last point I am trying to add regarding the VLAN2 a last ACL rule. I want to deny all clients above 192.168.2.50 the access to VLAN1.

Until now I was unfortunately not really successful….

[Ivan_B]

If your extended pool is above .50 then forbidden-ip is not needed.

As for the ACL that should deny VLAN 2 -> VLAN 1 communication for source addresses above 192.168.2.50, it is possible, however we should play a little with wildcard mask and rules, because .50 is kind of a round number for you, not for your router, LOL. Since it counts in binary, .64 is much more round, but nevertheless - routers should serve humans, not vice versa.

I think following rules should block the communication for the host below .50 (including .50 as well) to the whole 192.168.1.0/24 subnet:

rule 10 deny ip source 192.168.2.0 0.0.0.31 destination 192.168.1.0 0.0.0.255
rule 20 deny ip source 192.168.2.32 0.0.0.15 destination 192.168.1.0 0.0.0.255
rule 30 deny ip source 192.168.2.48 0.0.0.1 destination 192.168.1.0 0.0.0.255
rule 40 deny ip source 192.168.2.50 0.0.0.0 destination 192.168.1.0 0.0.0.255

If you do not need to block .50 address, just omit the rule 40.

In order to better understand the logic behind those numbers, try to experiment with those IPs and wildcard masks here - http://www.ip-calc.co.uk/wildcard.php You will see the range each IP-wildcard mask defines so you will see why for such "round" range as 0-50 we need not less than 4 rules. After that it will be easier to compose your own ACL rules.

Of course at the end of this ACL you should have:

rule 999 permit ip

in order to permit the rest of communication. 

Hope it helps!