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]
