network configuration question

[golfdoctor]

Hello all,

We are a Nortel shop for voice and data.

Very shortly we will be in the process of installing an opt11c (cs1000m-small) at a remote location. Our main site is running an 81c(cs1000m-large)and we are going to try and leverage our data connection and implement H.323 IP virtual trunking between the two sites. 4 digit CDP dialling will be in effect, with the main site providing PSTN services for the remote site via PRI. (general statement) At present the main site has a signalling server and a 32 port MC card configured. The intent is to utilize existing dlc and a/mwlc hardware and telephones at the remote site.I have activated the H.323 NRS functionality etc.and started preliminary configuration of the NRS, element manager and the main site PBX. Basically trying to program as much as possible prior to receiving and deploying the 11c. Rlse 4.0 is being used. The remote site will have a 32 port MC card for the virtual trunking.

Have a couple of questions;

1) Can I get away without programming a second node within element manager? My thought is any numbers or dialling info that does not terminate locally at the new node will be sent to the NRS based upon the TLAN configuration. As long as the gateway from the new node has registered with the NRS and I have programmed the routing tables correctly, should this not be enough ?

2) At present our TLAN has been setup utilizing a private class C subnet. Does it make sense to possibly change it to a private class B for possible future growth concerning IP phone registration etc. I dont think it should matter considering the data network is layer 2/3 vlan compliant and all that good stuff, however not sure if it may pose a problem in the future. We are relatively small with only a few thousand lines of which we have 100 or so IP phone's deployed.


Never posted before, thanks for any suggestions

TGD

 

[johnpoole]

sounds like a workable plan. i think dlc/analog cards need to be on the far end, and do add the node. have the ip's reg at the main. instead of a standalone opt 11 sounds more like an ip remote app.. class b/c is a mute point, local network concern.. i've seen class a with a 24 bit subnet... sounds like to me you should be answering questions, and welcome to tek-tips

john poole
bellsouth business
columbia,sc

 

[Firebird Scrambler]

I've got a Test system (11c 4.5) with a single 32 port Trunk card connected to another 4.5 system via it's Sig Server. I just needed OTM to configure the trunk card with its end point name & the T-Lan address of the Sig Server.
I used H323 & it does work fine.
Make sure that you use the latest 03.01.60 trunk software. I've also done the same with an old 24 port Pentium card that I rebuilt to link with a CPP4 system.

All the best

Firebird Scrambler
Meridian Programmer in the UK

http://mysite.wanadoo-members.co.uk/firebird_scrambler

 

[golfdoctor]

Thanks for the quick response, example and vote of confidence. Will keep you posted on any trials and tribulations.



TGD

 

[golfdoctor]

Hello all,

Well so much for preparation,planning and the vote of confidence. Am probably going to look dopey for this however...

I basically have done a pre-configuration implementation within the NRS. Service/L1/L0 Domains have been identified/configured in conjunction with the two H323 gateway endpoints. Testing within the NRS configuration looks good wrt to proper endpoint identication and termination as depicted when using the H323 route test within the NRS.
The main GW endpoint physically exists while the new node GW endpoint does not. The VRTK ISM's have not been implemented as of yet. The H323 VTRK package (399)is installed.

We only have one signalling server and the original role was set to failsafe. I configured the NRS and changed the role to "primary" so NRS functionality would come into play. When I activated the NRS to be primary, I would have thought the configured main GW end point should be registering with the NRS. The main endpoint is configured using the signalling server TLan IP, H323 support is RAS H323 and NCS is enabled.

When I look at the Signalling server log output however I get errors wrt the main endpoint registration. The second node endpoint I understand as not being available, however should the existing main endpoint not register regardless ?

Have fwded config; this is for main site as new node not installed. My thought is to get the main GW end point registering with the NRS first, and add the second node GW end point later with an MC TLan IP of 192.168.60.242.

TLAN Node IP - 192.168.60.250
SS TLAN IP - 192.168.60.251
MC TLAN IP - 192.168.60.252
PRI Gatekeeper- 192.168.60.251
PRI NCS IP- 192.168.60.251
TLan Default GW 192.168.60.1
NRS H323 ALIAS - xxxxx3
SS/MC H323ID - xxxxxx (both the same) Originally configured different however this is my last setting and there was no change with respect to the registration error.
The H323ID of the SS is not being interpolated. Originally I had a _ in the H323 nameing convention however I removed it. I believe there was a PEP (MPLR19772) regarding this, thus the change.

I have attached a print of the errors. Have changed the H323ID to xxxxxx for illustration purposes. The xxxxxx error seems to correlate to the H323ID of the Signalling Server.

LOG0003 GKNPM: nrsDbGKEndpointGet: EndpointName xxxx not found!
[0003] 04/03/06 09:29:33 LOG0003 GKNPM: gkNpmEndpointFindActive: SOLID didn't find xxxxx
[0004] 04/03/06 09:29:33 LOG0003 GKNPM: gkNpmRRQ: Endpoint not found in DB:
[0005] 04/03/06 09:29:33 LOG0003 GKNPM: gkNpmRRQ: DBM_NPM_RC_invalidAlias 123e51c8
[0006] 04/03/06 09:29:33 LOG0003 GKNPM: gkNpmHandleRRQRequest: DBM failure 6
[0007] 04/03/06 09:29:33 LOG0005 GKNPM: RAS FAILURE: RAS_TYPE : RRQ,Reason=incompleteAddress,SrcIP=192.168.30.250:1719
[0008] 04/03/06 09:29:38 LOG0003 GKNPM: nrsDbGKEndpointGet: EndpointName xxxxx not found!


Is it possible the software reqires the ISM truking license to allow gateway endpoint registration with the NRS ?

Could it be a PEP issue or have I simply pooched the dog ?


Any thoughts or suggestions ?




TGD

 

[dlesap]

OK i guess your opt11 will have a SigServ.
That way, you have to config it with another node number.

NRS main site will have to be set up as Primary NRS. New site can be Alternate NRS.

In NRS, enter a new Gateway Endpoint with RAS Endpoint. The name in that Gateway have to be the H323 id of remote site.
Using that way, after database synchonization, go back in Active database, gateway endpoint. If IP@ of remote site appears, the remote site is registered.

The virtual route have to be defined on both ends: DCH, Rout, and trunks.

For IP addressing, on TLAN for IP sets, you can change the subnet class, but Nortel recommendations is to set up a separated LAN for Voice. Look in NTPs.

 

[golfdoctor]

Thanks for the reply. It is lengthy and difficult to explain all aspects of the configuration however the main site does contain the Primary NRS and is functional wrt main site IP phone registration, functionality and configuration. The lone Signalling Server is configured co-resident. It will be the only one to service the TLAN node. I am aware of the redundancy issues, but will address later. As far as the configuration of the ELAN and TLAN they are on separate subnets, very standard Nortel setup (ELAN 137.135.128.xxx. and TLAN 192.168.060.xxx with both subnets physically isolated). I don't think that is applicable in this particular stage of the scenario as I am only looking for the main site H323GW end point to register with the Primary NRS which I believe to be a TLAN dependency, however I could be wrong. When the remote node comes into play the TLAN node identification will be key in conjunction with the remote site MC TLAN IP for NRS RAS-H323 registration and identification. The remote site ELAN will be completely separate and independant of the main site. Separate sites, separate ELAN configuration setup which I think is fairly common.
I have probably just misunderstood the response, but I am skeptical of the statement regarding the appearance in NRS of the remote H323GW endpoint IP meaning it is registered. I have two H323GW endpoints configured (the main and remote) The main being the Signalling Server while the remote is not physically present and both H323GW endpoint IP's appear. Neither the main or remote H323GW register with the GateKeeper (as per previous post). However the routing functionality of the NRS is correct as per the simulated H323 routing tests within NRS. The remote registration is obvious however the main GW endpoint should register with the Primary Gatekeeper.

I guess I am trying to ensure I am not on a goose chase wrt to the main site H323GW not registering with the Primary NRS because of a PEP or lack of ISM issue. If it is a configuration issue, great, then I should be able to get it to register even though functionally the remote site is not present.

As a side note for example purposes only, if I was dealing with a normal client/server type network registration issue this would appear to be a name resolution issue, sort of like DNS or the lmhost/host tables not configured to resolve the H323ID of the Signalling Server.

Thanks again -

TGD

 

[dlesap]

If you don't have the main site registreted in NRS, 1st solve it before going ahead.

How did you configured Gaeway endpoint for Main site: Static IP or RAS?

If static ip@, you have to give the TLAN ip@ of SS.
If RAS, give the h323 id of SS

I really suggest to use RAS, that you will be sure registration is OK when IP@ appears in active DB gway endpoint

 

[golfdoctor]

Thanks dlesap for your assistance. You were right on the money. Apologize as I did not pick up on your first response

I pooched the name in the gateway and H323ID config between the NRS and Element Mgr. They were different, when I changed, voila, the SS Node IP and the SS TLan IP register under the Signalling Server column and the Protocol Supported is RASH323/NCS . Before all that was being displayed was the TLan IP of the Signalling Server and "not registered" for the TLan Node and the RASH323 protocol. The main site is now registered!

Will keep you posted of any further issues or developments.


Thanks again,



TGD