Why I can not reach my IGX 8420 from SV+ via IP?

[afranco]

We have installed a new node in our IGX network. But we can not have access via IP to that node:

sv01cor% ping 10.0.255.36

ICMP Host Unreachable from gateway ig01cor-l (10.0.255.253)

for icmp from sv01cor-l (10.0.255.254) to 10.0.255.36

ICMP Host Unreachable from gateway ig01cor-l (10.0.255.253)

for icmp from sv01cor-l (10.0.255.254) to 10.0.255.36

ICMP Host Unreachable from gateway ig01cor-l (10.0.255.253)

for icmp from sv01cor-l (10.0.255.254) to 10.0.255.36

Do you know if I have to configurate some command in the gateway node to gain access via IP to the new node. Thank you very much.

IG01COR TN SuperUser IGX 8420 9.2.38 Feb. 19 2002 00:02 GMT

Active Network IP Address: 10.0.255.33

Active Network IP Subnet Mask: 255.255.255.224

NodeName IP Address

IG01COR 10.0.255.33

IG01VIG 10.0.255.34

IG01SAN 10.0.255.35

IG02COR 10.0.255.36

Last Command: dspnwip

[smoosa]

Have you checked what are the routes available on the SV+ ?

In order to ping using the nwip, you will need valid routes to the addresses available in the SV+

netstat -rn will give you the routes here. Check if the nwip addresses point to the lan ip of the gateway node. If this is set correctly, then you should be able to ping the nwip addresses.

[afranco]

Hi,

Thank you very much for your response. I have checked the routing table, but I din´t find anything strange in it. As you can see, the nwip (10.0.255.32 with mask 255.255.255.224) point to 10.0.255.253, which is the gateway. Do you see anything rare in this routing table?. Thank you very much.

sv01cor% netstat -nvrp

IRE Table:

Destination Mask Gateway Device Mxfrg Rtt Ref Flg Out In/Fwd

-------------------- --------------- -------------------- ------ ----- ----- --- --- ----- ------

192.187.172.14 255.255.255.255 10.0.128.15 ipdptp0 1500* 0 2 UH 1 0

10.0.255.240 255.255.255.252 10.0.255.253 1500* 0 0 UG 7 0

10.0.255.252 255.255.255.252 10.0.255.254 qfe1 1500* 0 2 U 6863 0

10.0.255.32 255.255.255.224 10.0.255.253 1500* 0 0 UG 132851 0

10.0.128.0 255.255.255.0 10.0.128.15 hme0 1500* 0 2 U 11746 0

default 0.0.0.0 10.0.128.241 1500* 0 0 UG 30181 0

127.0.0.1 255.255.255.255 127.0.0.1 lo0 8232* 0 0 UH 1739500 0

Net to Media Table

Device IP Address Mask Flags Phys Addr

------ -------------------- --------------- ----- ---------------

qfe1 10.0.255.253 255.255.255.255 00:c0:43:00:f9:9e

hme0 10.0.128.241 255.255.255.255 01:00:5e:00:03:03

hme0 10.0.128.10 255.255.255.255 08:00:20:a2:be:83

qfe1 10.0.255.254 255.255.255.255 SP 08:00:20:ac:0b:8a

hme0 10.0.128.243 255.255.255.255 08:00:20:bc:7d:40

hme0 10.0.128.245 255.255.255.255 08:00:20:b6:7d:8c

hme0 10.0.128.15 255.255.255.255 SP 08:00:20:ac:0b:8a

qfe1 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00

hme0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00

sv01cor%

IG01COR TN SuperUser IGX 8420 9.2.38 Feb. 20 2002 23:10 GMT

Active LAN IP Address: 10.0.255.253

Active LAN IP Subnet Mask: 255.255.255.252

NodeName IP Address

IG01COR 10.0.255.253

IG01VIG 192.0.0.1

IG01SAN 10.3.201.4

IG02COR 10.1.201.4

Last Command: dsplanip

[smoosa]

Hello,

It is clear now that I see your Lan ip. Basically the process that handles network ip to lan ip traffic (IP Relay) does not support VLSM.

This is identified in the DDTS CSCdj42445. I think that you can use VLSM with iprelay in 9.3 versions of switch software.

[afranco]

Hello, thank you very much for your valuable response. I have collected the following information from our four IGX network:

Node Active LAN IP Subnet Mask Active Network IP Subnet Mask

IG01COR 255.255.255.252 255.255.255.224

IG02COR 255.255.255.0 255.255.255.224

IG01VIG 255.255.255.0 255.255.255.224

IG01SAN 255.255.255.0 255.255.255.224

So, do you mean that LAN and NW IP subnet masks must match for the four nodes (for example, Active LAN IP Subnet Mask must be 255.255.255.224 for all nodes)?.

But before including IG02COR in the network, everything was working fine. I mean, why does this bug show up now?. We have been supporting VLSM all the time before. Are you sure that this is the reason of the problem or you only think that may be?. Could you please give some more information about this bug?.

Thank you very much and my best regards.

Tony.

[smoosa]

Hi Tony,

If you check your ip addresses for each node, ( the lan and nwip), then you will see that only for the new node added do you have the lanip and nwip address in the same major network ( class A).

I should have clarified when I said that you cannot use VLSM. If you have a different major network, then the subnet mask does not matter. The routing (ip relay ) is done based on the major network (which is why you cannot have the same major network but use VLSM to separate them).

regards

Shajith

[afranco]

Hi Shajith,

just remind me if I am wrong:

you say "you will see that only for the new node added do you have the lanip and nwip address in the same major network ( class A)". But, for example, IG01SAN (which is not the new node added) has IP LAN = 10.3.201.4 and IP NW = 10.0.255.35, so it has the same major Class A network (10.0.0.0), and everything was and is working fine with this node. Why do you say that IG02COR (which is the new node added) is the ONLY one that has the same major network (Class A)?.

Could you please have a look to my question?.

Thank you very much.

[smoosa]

Hi Tony,

Before you added the new node, was the node IG01SAN the gateway node ?

If you are trying to get to your NWIP address, the traffic has to go through the gateway node and if you have the VLSM problem or the major network being the same (with different masks)at the gateway node, then you would run into the same issue. I don't think that you should have the same issue if this condition was not at the gateway node.

[afranco]

Hi Shajith,

thank you very much for your quick response.

No, IG01SAN wasn´t the gateway node before we added the new node. The gateway node has always been IG01COR (the node that can not comunicate via IP with the new node (IG02COR)).

But, we have had different masks for the gateway node (IG01COR) before and after adding the new node. IG01COR´s masks have not changed and the gateway node was working well with different masks before adding the new node.

That´s why I am not sure if the problem would be solve configuring the same masks for the gateway node (because this node has been working fine with different masks before adding the new node).

Maybe, you think that the problem was there (because we have always had different masks in the gateway node), but we were lucky because the problem haven´t shown up yet. Is this what you think?.

I hope I am not asking too many questions to you about this issue and you get tired of me. Thank you for being patience.

[smoosa]

Tony,

No problem at all. I would suggest that you open a case with the TAC and this would facilitate dialin into the network and some real time testing. There is still some confusion regarding the state of the lan and nwip addresses before and after the new node was added.