I have a customer with Novell servers at a Central site, and they are connected to the remote site via SMDS cloud. On the remote router, SAP table is showing partial update for some SAPs. For some of the SAP entries, the Route/Hops/Interface entries are not there, and so the remote clients are not able to connect to the novell servers at central site.
Snipped o/p below:-
B465#sh ipx serv
Codes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail
U - Per-user static
676 Total IPX Servers
Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf
P 4 B005 B005.0000.0000.0001:0451
P 4 B006 B006.0000.0000.0001:0451 8/02 2 Se0/0
P 4 B009 B009.0000.0000.0001:0451
P 4 B013 B013.0000.0000.0001:0451 8/02 2 Se0/0
P 4 B014 B014.0000.0000.0001:0451 8/02 2 Se0/0
P 4 B016 B016.0000.0000.0001:0451
P 4 B032 B032.0000.0000.0001:0451
The IPX routing table on the remote router has the ipx network on which the servers are, but the sap table is showing partial update for an entry. They have a msfc that is connected to the novell servers, from msfc goes to a 7206 router that is connected to the SMDS cloud. The remote 2611 router is connected to the SMDS cloud. The 7206 router has all the sap information but when the sap updates are crossing the SMDS cloud and reaching the 2611 router, we are getting partial update for an sap entry.
Any suggestions will be appreciated !!
What does the config look like, Are there any sap filters added to the interfaces, filtering out some of the saps ? How many sap entries does the 7200 have (i see that 676 is the total on the remote).
Yes, there are sap filters, and the 7206 has more than 676 saps. But thing is sap filter will not filter partial information from the sap update (like filter route/hops/interface and keep the ipx server name and sap type in the table). There are other same 2611 routers at other remote sites with same config and IOS version that donot have the problem. IOS version on remote router is 11.3(7)T.
There are a couple of bugs related to SAP inconsistencies on IPX EIGRP. If you are using IPX EIGRP, check that out using the bug toolkit.
Also try to do a clear ipx sap and see if that helps in any way.
I have seen this before and I beleive that the incomplete output indicates that the route is in holddown. Did you have anything flapping ?
When you do a 'sh ipx route' to these networks are there routes ?
B465# sh ipx route
Codes: C - Connected primary network, c - Connected secondary network
S - Static, F - Floating static, L - Local (internal), W - IPXWAN
R - RIP, E - EIGRP, N - NLSP, X - External, A - Aggregate
s - seconds, u - uses, U - Per-user static
507 Total IPX routes. Up to 3 parallel paths and 16 hops allowed.
No default route known.
C 254 (SMDS), Se0/0
C 465 (NOVELL-ETHER), Et0/0
R B005 [08/02] via 254.0008.e3b6.e9e0, 35s, Se0/0
R B006 [08/02] via 254.0000.0c47.1db1, 19s, Se0/0
R B007 [17/04] via 254.000a.4256.3c08, 1s, Se0/0
via 254.000a.4256.3808, 31s, Se0/0
R B008 [08/02] via 254.0002.165a.5d60, 29s, Se0/0
R B009 [08/02] via 254.0000.0c4a.187d, 21s, Se0/0
R B016 [08/02] via 254.0000.0c13.d75c, 23s, Se0/0
R B032 [08/02] via 254.0009.b7fe.50e0, 43s, Se0/0
R B033 [08/02] via 254.0000.0c13.d7e8, 34s, Se0/0
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
Internet address is 204.X.X.X/24
Backup interface BRI0/0, kickin load not set, kickout load not set
failure delay 10 sec, secondary disable delay 120 sec
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 2/255
SMDS hardware address is c131.0319.9615
Encapsulation SMDS, loopback not set, keepalive set (10 sec)
ARP type: SMDS, ARP Timeout 04:00:00
Mode(s): D15 compatibility, DXI 3.2
DXI heartbeat sent 9063, DXI heartbeat received 9063
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 13000 bits/sec, 11 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
1102193 packets input, 178027652 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
6 input errors, 0 CRC, 4 frame, 0 overrun, 0 ignored, 2 abort
128202 packets output, 19510048 bytes, 0 underruns
0 output errors, 0 collisions, 13 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
backup delay 10 120
backup interface BRI0/0
ip address 204.X.X.X 255.255.255.0
ip hello-interval eigrp 4 60
ip hold-time eigrp 4 180
no ip split-horizon eigrp 4
no ip mroute-cache
smds address c131.0319.9615
smds glean-mode NOVELL
smds multicast NOVELL e171.4635.3305
smds multicast IP e171.4635.3305 126.96.36.199 255.255.255.0
smds multicast ARP e171.4635.3305 188.8.131.52 255.255.255.0
ipx network 254
ipx output-sap-filter 1000
Pick a server and a network , for example server B005 and network B005 jump to your next hop then do a sh ipx route & sh ipx server , until you find the point of failure , I suspect you will come across a Novel server advertising routes.
unfortunately troubleshooting IPX rip is painful.
also I noticed you have split horizon disabled for IP , you may need to diable it for ipx , do a sh ipx interface s0/0 this will show if it is enabled or disabled .
The amount of servers is quite considerable. To tackle the issue try to reduce the amount of advertised services to just that what is required. This is adviseable anyway because the SAP advertisements take quite some bandwidth.
A different approach would be to switch over to NLSP. This causes less overhead on the WAN.
We had problems with an early super2/msfc2. We had to turn of mls for ipx until an ios fix was released. It had something to do with packets getting forwarded with source addresses all zeros. You might try turning off mls for ipx (if it is on) in the switch with the msfc.