Back on topic at last! In my review of frame relay, I am examining every routing protocol over a frame cloud in a hub and spoke setup. IPX is the topic of the day, and I thought I was so clever when I devised this scenario. I was writing this post well before I ran into The Problem. As we all know, with IPX RIP one cannot disable split horizon. There are a few work arounds, but I thought I would be clever and practice IPX default routes. If called upon in the lab, I would wow the proctor with my brilliance. check CCO. is this documentation poor or what? well, I'm pretty smart, so I start mucking around. I also check the CCIE lab list archives, and find only one post that is halfway helpful. the layout: R7 logical layout only - physical layout is a frame cloud with 3 pvc's | at R1, which is the hub of the frame cloud r1 r7 and r1 on the same ethernet segment /|\ / | \ r4 r5 r2 | | r6 r3 using physical interfaces, and inverse arp on the frame side. OK R1 has all the routes, and as expected does not advertise them back out the frame cloud to the other routers. after a period of trial and error I finally derive the proper way to configure default networks. My plan is to advertise an IPX default out of router 1 into the frame cloud. this should give me end to end connectivity. now IPX default network advertisements are created much differently that is done in IP routing protocols. here's how you do it. on the router from which you want to originate the default you must: 1) create a static route to the default using the ipx route default n.x.x.x command this route must be directly connected. the x.x.x is the network / mac address of the next hop. example - R1----------------r2 mac=1.1.1 AAA mac=2.2.2 if you want r2 to advertise a default route to r1, the command would be ipx route default aaa.1.1.1 2) on the interface out which you want to advertise the default you configure ipx advertise-default-route-only net number. the net number is the ipx net address of the interface out which the default will go. 3) the ipx advertise statement must be configured on downstreams if there are further routers on the network. 4) on every router receiving the default route, you must configure ipx default-route command. OK. so what do I have? Hub router ---------- R1#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 17 Total IPX routes. Up to 1 parallel paths and 16 hops allowed. Current default route is: S FFFFFFFE via 1A.0010.7bc7.3643, Et0 C 1A (NOVELL-ETHER), Et0 C A1A (UNKNOWN), Lo0 C 1245 (FRAME-RELAY), Se0 R 23 [07/01] via 1245.0002.0002.0002, 53s, Se0 R 2B [07/01] via 1245.0002.0002.0002, 53s, Se0 R 3C [13/02] via 1245.0002.0002.0002, 53s, Se0 R 4D [07/01] via 1245.0004.0004.0004, 49s, Se0 R 56 [07/01] via 1245.0005.0005.0005, 53s, Se0 R 5E [07/01] via 1245.0005.0005.0005, 53s, Se0 R 6F [13/02] via 1245.0005.0005.0005, 53s, Se0 R B2B [07/01] via 1245.0002.0002.0002, 53s, Se0 R C3C [13/02] via 1245.0002.0002.0002, 53s, Se0 R D4D [07/01] via 1245.0004.0004.0004, 17s, Se0 R E5E [07/01] via 1245.0005.0005.0005, 22s, Se0 R F6F [13/02] via 1245.0005.0005.0005, 22s, Se0 R DC1DE [02/01] via 1A.0010.7bc7.3643, 51s, Et0 R1# R2#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 7 Total IPX routes. Up to 1 parallel paths and 16 hops allowed. Current default route is: R FFFFFFFE [07/02] via 1245.0001.0001.0001, 48s, Se0 C 23 (HDLC), Se1 C 2B (NOVELL-ETHER), Et0 C B2B (UNKNOWN), Lo0 C 1245 (FRAME-RELAY), Se0 R 3C [07/01] via 23.0003.0003.0003, 26s, Se1 R C3C [07/01] via 23.0003.0003.0003, 26s, Se1 R2# ok - the default is being advertised - this is true on all routers in the pod. R3#ping d4d.4.4.4 Translating "d4d.4.4.4" Type escape sequence to abort. Sending 5, 100-byte IPX Novell Echoes to D4D.0004.0004.0004, timeout is 2 second s: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/20 ms R3#ping d4d.4.4.4 Translating "d4d.4.4.4" Type escape sequence to abort. Sending 5, 100-byte IPX Novell Echoes to D4D.0004.0004.0004, timeout is 2 second s: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/16 ms R3# R3 ( downstream of R2 - can ping a couple other routers just fine. but from R4: R4#ping d2d.2.2.2 Translating "d2d.2.2.2" Type escape sequence to abort. Sending 5, 100-byte IPX cisco Echoes to D2D.0002.0002.0002, timeout is 2 seconds : ..... Success rate is 0 percent (0/5) R4#ping c3c.3.3.3 Translating "c3c.3.3.3" Type escape sequence to abort. Sending 5, 100-byte IPX cisco Echoes to C3C.0003.0003.0003, timeout is 2 seconds : ..... Success rate is 0 percent (0/5) R4# didn't I just successfully ping the other way? so I've been testing for a while. end to end pings from r6 to r3 work with no problem. r3 and r6 have no problem pinging their direct upstream, and visa versa. but spoke to spoke pinging is haphazard. I'm thinking a split horizon issue, but I can't lay my finger on anything consistant or definite. I have resorted to static mapping of the dlci's, with no improvement. R4#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 4 Total IPX routes. Up to 1 parallel paths and 16 hops allowed. Current default route is: R FFFFFFFE [07/02] via 1245.0001.0001.0001, 39s, Se0 C 4D (SAP), To0 C D4D (UNKNOWN), Lo0 C 1245 (FRAME-RELAY), Se0 R4#ping a1a.1.1.1 Translating "a1a.1.1.1" Type escape sequence to abort. Sending 5, 100-byte IPX cisco Echoes to A1A.0001.0001.0001, timeout is 2 seconds : !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms R4# actually, there is one other possibility. it is that I am seeing a similar phenomenon to what I see when I do this same scenario using RIP or EIGRP. that is, that pinging from routers with interfaces directly connected to the frame cloud pinging fails. however, using extended ping, the test succeeds. my debugs do show that the source address of my pings is the directly connected interface. IPX ping does not have an option allowing one to designate a source interface, thus forcing the packet through the routing process. As I said - longish. if you are still awake, got any insight? Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=19715&t=19715 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]