icmp redirect from netware
sje...@mb.bluecross.ca
what are the prerequisites for it to do this?
I have a Netware server that has several static routes setup for tcp/ip,
some of which point to routers that are "inside" the local network.
Currently every packet is sent to netware (default gateway) and then sent
on to the other router. I'd like Netware to send an ICMP redirect for
these routes that can be reached faster by bypassing netware (we can't
change netware from being our default gateway though.)
Marcel Cox
table is such that the packet to be routed will be sent out on the same
interface as it arrived.
--
Marcel Cox
http://support.novell.com/forums/
sje...@mb.bluecross.ca
routing
> table is such that the packet to be routed will be sent out on the same
> interface as it arrived.
> --
In Inetcfg we have IP Packet Forwarding Enabled, and several static routes
that are all setup as "passive". Several of these are routes that packets
will be sent out the same interface that the request came in on.
If I do a ping to one of these networks I should get a route ("route
print") on my workstation then? I'm not. Every packet goes to the
netware server. Multiple pings\traceroutes all go the same way.
Is there some other setting that can be changed? Anything to do with the
metrics associated with each route?
Marcel Cox
statistics to see if the server send out any redirects.
--
Marcel Cox (using XanaNews 1.15.8.5)
sje...@mb.bluecross.ca
> statistics to see if the server send out any redirects.
>
Hi,
I did that, and the server has sent out 321 icmp redirects. Looking at
that page in tcpcon and pinging one of these networks doesn't increment
the icmp redirects counter though. So at one point this server sent out
redirects but it doesn't appear to now.
Any settings that may effect this?
Marcel Cox
Does your server have multiple NICs? Are you sure the traffic you want
to redirect always goes out on the same interface as the incoming
packets?
Massimo Rosen
sje...@mb.bluecross.ca wrote:
>
> > I suggest you load TCPCON.NLM on the server and check the ICMP
> > statistics to see if the server send out any redirects.
> >
>
> Hi,
>
> I did that, and the server has sent out 321 icmp redirects. Looking at
> that page in tcpcon and pinging one of these networks doesn't increment
> the icmp redirects counter though.
That's not a valid test, as the workstation remembers the redirect, so
not every new ping will go back to the netware server.
Additionally, not every OS honors the redirects, IIRC e.g Windows NT
can't habndle redirects it receives and always uses the default router.
CU,
--
Massimo Rosen
Novell Support Connection Sysop
No emails please!
http://www.cfc-it.de
Marcel Cox
> That's not a valid test, as the workstation remembers the redirect, so
> not every new ping will go back to the netware server.
However I think remebered redirects should be visible by the "route print"
command. At least it is that way on Unix machines, bug I have never
verified on Windows machines.
--
Marcel (using XanaNews 1.15.8.5)
I can resist everything but temptation
Massimo Rosen
Marcel Cox wrote:
>
> Massimo Rosen wrote:
>
> > That's not a valid test, as the workstation remembers the redirect, so
> > not every new ping will go back to the netware server.
>
> However I think remebered redirects should be visible by the "route print"
> command.
That's correct.
> At least it is that way on Unix machines, bug I have never
> verified on Windows machines.
That's at least true for W2K also.
sje...@mb.bluecross.ca
> Does your server have multiple NICs? Are you sure the traffic you want
> to redirect always goes out on the same interface as the incoming
> packets?
There are two NICs, one to the private network and one to the public
network. The packets originate on the private network and must be routed
to another router on the private network. As far as I can see there is no
way that the traffic could be routed out any other interface than the one
they came in on for certain routes.
Shawn Jefferson
TCP Status: Enabled
IP Packet Forwarding: Enabled("Router")
RIP: Enabled
OSPF: Disabled
LAN Static Routing: Enabled
Dead Gateway Detection: Disabled
Load Balancing: Disabled
Fault Tolerance: Enabled
Filter Support: Enabled
NAT Implicit Filtering: Enabled
RIP Bind Options
Status: Enabled
Cost of Interface: 1
Originate Default Route: Disable: Present Normal Routes
Poison Reverse: Disabled
Split Horizon: Enabled
Update Time: 30
Expire Time: 180
Garbage Time: 120
RIP Version: RIPI
RIP Mode: Normal
RIPII Options: <blank>
Any suggestions?
Shawn Jefferson
Would packet filtering have any effect on icmp redirects being sent out
from the server? We do have packet filters enabled.
I wouldn't think that packet filters would stop the server from sending
out a packet itself on the private interface, but who knows! Anyone have
any suggestions as to why this server is not sending icmp redirects?
Massimo Rosen
Shawn Jefferson wrote:
>
> > Here's some more information on the setup (from inetcfg):
>
> Would packet filtering have any effect on icmp redirects being sent out
> from the server? We do have packet filters enabled.
Well, if you're filtering ICMP on all interfaces, of course.
> I wouldn't think that packet filters would stop the server from sending
> out a packet itself on the private interface, but who knows!
Packet filters themselfs don't filter anything. The filter rules someons
creates do. Simple test: can you ping the machine that is supposed to
receive the redirect from the server? If yes, you're fine.
> Anyone have
> any suggestions as to why this server is not sending icmp redirects?
Actually, I'm pretty certain that the server does send them if they're
needed. I've never seen a current Netware server *not* sending
redirects.
CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
Shawn Jefferson
> creates do. Simple test: can you ping the machine that is supposed to
> receive the redirect from the server? If yes, you're fine.
Yes, I can ping from the server to my workstation.
> > Anyone have
> > any suggestions as to why this server is not sending icmp redirects?
>
> Actually, I'm pretty certain that the server does send them if they're
> needed. I've never seen a current Netware server *not* sending
> redirects.
My server is not sending them for some reason. Does it have anything to
do with whether or not the route is sent to "Passive" or "Active" ?
I'm pinging a server at another location and then doing a "route print" on
my workstation. I never see the new route show up. ICMP statistics in
TCPCON have ICMP redirects at 304 and not rising. The strange thing is
that the server has sent 304 redirects but this must have been just after
it was brought up sine the number hasn't changed for days.
Massimo Rosen
Shawn Jefferson wrote:
>
> My server is not sending them for some reason.
Have you undoubtedly verified that? The only valid way to verify it's
not sending them is to install anetwork sniffer in parallel to the
problem workstation, bootup the problem ws from scratch with the sniffer
running, and do exactly one ping to a address that should be redirected.
Than check the sniffer trace if the server replied with a redirect or
not. Anything else is just assumption.
> Does it have anything to
> do with whether or not the route is sent to "Passive" or "Active" ?
No.
> I'm pinging a server at another location and then doing a "route print" on
> my workstation. I never see the new route show up. ICMP statistics in
> TCPCON have ICMP redirects at 304 and not rising. The strange thing is
> that the server has sent 304 redirects but this must have been just after
> it was brought up sine the number hasn't changed for days.
Can you post the tcpip.cfg, netinfo.cfg and gateways files of that
server, and provide full details which source IP is pinging which
target?
CU,
--
Massimo Rosen
Novell Support Connection Sysop
Shawn Jefferson
> not sending them is to install anetwork sniffer in parallel to the
> problem workstation, bootup the problem ws from scratch with the sniffer
> running, and do exactly one ping to a address that should be redirected.
> Than check the sniffer trace if the server replied with a redirect or
> not. Anything else is just assumption.
I have setup Ethereal on my own workstation and then initiated a
connection to a web server that is on one of these routes. I can verify
that every packet going to this route from my workstation has the MAC
address of the netware server. I don't see any ICMP redirects being sent
to my workstation. I can ping a node at one of these routes. No ICMP
redirect is being captured by Ethereal. No routes are being added as
checked by "route print".
> Can you post the tcpip.cfg, netinfo.cfg and gateways files of that
> server, and provide full details which source IP is pinging which
> target?
TCPIP.CFG:
AutonomousSystem 0
Protocol rip on {
Interface {
Address 172.16.3.2
Port N100_2_EII_EII
Status on
Cost 1
Poison off
SplitHorizon on
UpdateTime 30
GarbageTime 120
ExpireTime 180
OriginateDefault off
Version ripI
Mode receiveonly
}
Interface {
Address 167.74.160.1
Port N100_1_EII_EII
Status on
Cost 1
Poison off
SplitHorizon on
UpdateTime 30
GarbageTime 120
ExpireTime 180
OriginateDefault off
Version ripI
Mode normal
}
}
Protocol egp off {
}
Protocol ospf off {
Interface {
Address 172.16.3.2
Port N100_2_EII_EII
Status on
Cost 1
AreaId 0.0.0.0
Priority 1
RetransmissionInterval 5
TransitDelay 1
HelloInterval 10
RouterDeadInterval 40
Nbma {
PollInterval 120
Neighbor {
}
}
}
Interface {
Address 167.74.160.1
Port N100_1_EII_EII
Status on
Cost 1
AreaId 0.0.0.0
Priority 1
RetransmissionInterval 5
TransitDelay 1
HelloInterval 10
RouterDeadInterval 40
Nbma {
PollInterval 120
Neighbor {
}
}
}
}
Interface {
Address 172.16.3.2
AddressMask 255.255.255.0
Port N100_2_EII_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Both
PubAddress 172.16.3.8
PrvAddress 167.74.160.8
PrvMask 255.255.0.0
PubAddress 172.16.3.74
PrvAddress 167.74.160.74
PrvMask 255.255.0.0
PubAddress 172.16.3.73
PrvAddress 167.74.160.73
PrvMask 255.255.0.0
PubAddress 172.16.3.72
PrvAddress 167.74.160.72
PrvMask 255.255.0.0
PubAddress 172.16.3.68
PrvAddress 167.74.160.68
PrvMask 255.255.0.0
PubAddress 172.16.3.52
PrvAddress 167.74.160.52
PrvMask 255.255.0.0
PubAddress 172.16.3.31
PrvAddress 167.74.160.31
PrvMask 255.255.0.0
TOSStatus Disabled
TOSValue 0
ARPTimerStatus Disabled
ARPCacheUpdateTimeout 300
ARPCacheStaleTimeout 300
GroupedInterface no
PrimaryInterface no
LBPolicy 0
Arpable yes
NetworkAddress 172.16.3.0
}
Interface {
Address 167.74.160.1
AddressMask 255.255.254.0
Port N100_1_EII_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Disabled
TOSStatus Disabled
TOSValue 0
ARPTimerStatus Disabled
ARPCacheUpdateTimeout 300
ARPCacheStaleTimeout 300
GroupedInterface yes
PrimaryInterface yes
LBPolicy 0
Arpable yes
NetworkAddress 167.74.160.0
}
ForwardIPSourceRouting off
NATFiltering on
Deadgatewaydetection off {
T0 30
T1 2
}
LoadBalancing off {
LBInterval 30
}
FaultTolerance on {
FTInterval 2
FTMinError 20
}
NETINFO.CFG:
#!VERSION=2.3
#!
#! --- WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING ----
#! This file was created by the Internetworking Configuration Console.
#! It is intended to be modified ONLY by the configurator (INETCFG.NLM).
#! Tampering with this file may cause severe malfunctioning of the system.
#! The configurator will check for tampering and abort if it is detected.
#! -----------------------------------------------------------------------
#!
#!SERVERTYPE=NORMAL
#!
#!UIMODE=NORMAL
#!
#!BEGINGENLOAD
LOAD SNMP MonitorCommunity ControlCommunity TrapCommunity
LOAD BCALLSRV
#!END
#!
#!BEGINTSMLOAD
#!END
#!
#!BEGINBOARD DRVR=N100 NAME=N100_1_EII STATUS=ENABLED NUMPORTS=1
DRVRTYPE=LAN VARIABLEPORTS=NO PORTPARAM=CHANNEL SLOT=10005 SPEED=0
FORCEDUPLEX=0 TXTHRESHOLD=16 SPURIOUS=1
#Transferred from AUTOEXEC.NCF
#!BEGINPORT NAME=N100_1_EII NUMBER=1 STATUS=ENABLED FRAMES=YES NUMLINKS=1
MEDIA=EtherTsm WANFRAME=UNCONFIGURED
#Transferred from AUTOEXEC.NCF
#!REFCOUNT=1
LOAD N100 NAME=N100_1_EII_E83 FRAME=Ethernet_802.3 SLOT=10005 SPEED=0
FORCEDUPLEX=0 TXTHRESHOLD=16 SPURIOUS=1
#!REFCOUNT=1
LOAD N100 NAME=N100_1_EII_EII FRAME=ETHERNET_II SLOT=10005 SPEED=0
FORCEDUPLEX=0 TXTHRESHOLD=16 SPURIOUS=1
#!END
#!END
#!
#!BEGINBOARD DRVR=N100 NAME=N100_2_EII STATUS=ENABLED NUMPORTS=1
DRVRTYPE=LAN VARIABLEPORTS=NO PORTPARAM=CHANNEL SLOT=6 SPEED=10
FORCEDUPLEX=1 TXTHRESHOLD=16 SPURIOUS=1
#Transferred from AUTOEXEC.NCF
#!BEGINPORT NAME=N100_2_EII NUMBER=1 STATUS=ENABLED FRAMES=YES NUMLINKS=1
MEDIA=EtherTsm WANFRAME=UNCONFIGURED
#Transferred from AUTOEXEC.NCF
#!REFCOUNT=1
LOAD N100 NAME=N100_2_EII_EII FRAME=ETHERNET_II SLOT=6 SPEED=10
FORCEDUPLEX=1 TXTHRESHOLD=16 SPURIOUS=1
#!END
#!END
#!
#!BEGINPROTO PROTO=TCPIP STATUS=ENABLED
LOAD Tcpip RIP=Yes Static=Yes LoadSharing=No Forward=Yes
#
LOAD ipflt
#
#!BEGINBIND STATUS=ENABLED
BIND IP N100_1_EII_EII ProxyARP=Yes ARP=Yes Mask=255.255.254.0
Address=167.74.160.1
#167.74.160.1
#!END
#!BEGINBIND STATUS=ENABLED
BIND IP N100_2_EII_EII ARP=Yes Mask=255.255.255.0 Address=172.16.3.2
#172.16.3.2
#!END
#!END
#!
#!BEGINPROTO PROTO=IPX STATUS=ENABLED
SET Reply To Get Nearest Server=OFF
#
LOAD IPXRTR ROUTING=NLSP CFGDIR=SYS:ETC SEQ=1
#
LOAD IPXRTRNM SEQ=1
#
LOAD IPXFLT SEQ=5
#
LOAD IPRELAY name=IPRELAY
#
BIND IPX IPRELAY
#
LOAD SPXCONFG Q=1 A=540 V=54 W=108 R=10 S=1000 I=1200
#
SET IPX NetBIOS Replication Option=1
#
SET Load Balance Local LAN=OFF
#
#!BEGINBIND STATUS=ENABLED
BIND IPX N100_1_EII_E83 net=4 seq=4
#4
#!END
#!END
GATEWAYS:
Net 0.0.0.0 Gateway 172.16.3.1 Metric 1 Passive
Net 167.74.0.0/255.255.0.0 Gateway 167.74.160.2 Metric 1 Passive
Net 167.74.163.0/255.255.255.0 Gateway 167.74.160.16 Metric 1 Active
Net 172.16.2.0/255.255.255.0 Gateway 167.74.160.2 Metric 1 Passive
Net 192.168.144.0/255.255.255.0 Gateway 167.74.160.80 Metric 1 Passive
Net 192.168.200.0/255.255.255.0 Gateway 167.74.160.80 Metric 1 Passive
Host 198.135.72.2 Gateway 167.74.160.2 Metric 1 Passive
I connected to 167.74.100.164 which is a webserver. The node I pinged is
as 167.74.163.23.
This netware server has BorderManager installed on it. Might that make
any difference in the way it handles routing?
Thanks,
Massimo Rosen
> GATEWAYS:
> Net 0.0.0.0 Gateway 172.16.3.1 Metric 1 Passive
> Net 167.74.0.0/255.255.0.0 Gateway 167.74.160.2 Metric 1 Passive
> Net 167.74.163.0/255.255.255.0 Gateway 167.74.160.16 Metric 1 Active
There you go. You have conflicting routes in your gateway file, and even
worse, the first 167.74.X.X route above is actually within a range where
the server also itself has a local IP address in, the 167.74.160.1.
Would I be your server, I would have much more serious issues than just
not sending ICMP redirects. You need to get your routing table in order
on that server.
CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
Onno Molenkamp
> Hi,
>
>>GATEWAYS:
>>Net 0.0.0.0 Gateway 172.16.3.1 Metric 1 Passive
>>Net 167.74.0.0/255.255.0.0 Gateway 167.74.160.2 Metric 1 Passive
>>Net 167.74.163.0/255.255.255.0 Gateway 167.74.160.16 Metric 1 Active
>
>
> There you go. You have conflicting routes in your gateway file, and even
> worse, the first 167.74.X.X route above is actually within a range where
> the server also itself has a local IP address in, the 167.74.160.1.
Those routes are perfectly valid, since the interface with 167.74.160.1
has a less broad subnetmask. (255.255.254.0)
In fact, routes can *only* possibly conflict when both target and
netmask are the same. In all other combinations, the most specific route
will be used.
Remember that if this would be invalid, so would every default route be,
since all local IP addresses are in the 0.0.0.0/0 range. :)
Onno
Massimo Rosen
Onno Molenkamp wrote:
>
> Massimo Rosen wrote:
> > Hi,
> >
> >>GATEWAYS:
> >>Net 0.0.0.0 Gateway 172.16.3.1 Metric 1 Passive
> >>Net 167.74.0.0/255.255.0.0 Gateway 167.74.160.2 Metric 1 Passive
> >>Net 167.74.163.0/255.255.255.0 Gateway 167.74.160.16 Metric 1 Active
> >
> >
> > There you go. You have conflicting routes in your gateway file, and even
> > worse, the first 167.74.X.X route above is actually within a range where
> > the server also itself has a local IP address in, the 167.74.160.1.
>
> Those routes are perfectly valid, since the interface with 167.74.160.1
> has a less broad subnetmask. (255.255.254.0)
Not to Netware I'm afraid. Try it.
> In fact, routes can *only* possibly conflict when both target and
> netmask are the same. In all other combinations, the most specific route
> will be used.
>
> Remember that if this would be invalid, so would every default route be,
> since all local IP addresses are in the 0.0.0.0/0 range. :)
No, a default route is a special thing.
CU,
--
Massimo Rosen
Novell Support Connection Sysop
Onno Molenkamp
> Not to Netware I'm afraid. Try it.
I have routes like this with OSPF, and everything seems to be working.
If it doesn't work, TCPIP.NLM is broken and needs fixing.
Onno
Massimo Rosen
Possible, but first we have to verify that I'm right.
Shawn Jefferson
I don't seem to have any problems in my network, aside from the fact that
Netware doesn't want to send an icmp redirect. All traffic gets where it
is supposed to go.
Massimo Rosen
That is correct. We need to verify if the ICMP redirect doesn't get sent
because of the two conflicting routes.
Shawn Jefferson
>
> Shawn Jefferson wrote:
> >
> > > Possible, but first we have to verify that I'm right.
> >
> > I don't seem to have any problems in my network, aside from the fact
that
> > Netware doesn't want to send an icmp redirect. All traffic gets where
it
> > is supposed to go.
>
> That is correct. We need to verify if the ICMP redirect doesn't get sent
> because of the two conflicting routes.
One of my routes is for the network 192.168.144.0. If I ping
192.168.144.1 i get a response but no route is added (checked with route
print). This route is not one of the possibly conflicting ones, right?
Massimo Rosen
Shawn Jefferson wrote:
>
> One of my routes is for the network 192.168.144.0. If I ping
> 192.168.144.1 i get a response but no route is added (checked with route
> print). This route is not one of the possibly conflicting ones, right?
No, but the gateway is, as is your machine you ping from. This might
still confuse the server enough. I'm not sure what to tell you, as I
know for certain that Netware servers usually *do* send redirects.