|
Home > Archive > CCIE > September 2005 > Frame-relay configuration problem. Any Help?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Frame-relay configuration problem. Any Help?
|
|
| mosam 2002-08-23, 10:53 pm |
| I am trying to configure frame-relay on HUB-SPOKE topology. I have the classic problem of the HUB being able to reach all SPOKEs, but SPOKES can not reach each other.
I have already created PVCs in the HUB to each SPOKE. Only one PVC is created in the SPOKE to the HUB though.
Here is the tricky part, I need to be able to ping the SPOKEs from any other SPOKE withought creating any more PVCs in any of the SPOKEs.
The scenario states "The problem can be solved with multiple frame map ip statements, but that is not the solution we want, instead, solve the problem with routing not layer 3 to layer 2 mapping".
Any help? | |
| Worker 2002-08-24, 3:26 am |
| quote:
Originally posted by mosam
I am trying to configure frame-relay on HUB-SPOKE topology. I have the classic problem of the HUB being able to reach all SPOKEs, but SPOKES can not reach each other.
I have already created PVCs in the HUB to each SPOKE. Only one PVC is created in the SPOKE to the HUB though.
Here is the tricky part, I need to be able to ping the SPOKEs from any other SPOKE withought creating any more PVCs in any of the SPOKEs.
The scenario states "The problem can be solved with multiple frame map ip statements, but that is not the solution we want, instead, solve the problem with routing not layer 3 to layer 2 mapping".
Any help?
| |
| Worker 2002-08-24, 3:30 am |
| you haven't really given enough information about how you have configured the hub setup for the PVC's. Under Split horizon rules you will need to use Sub interfaces and this should work o.k with all spokes being able to reach the others.
I take it you are using
frame interface dlci and inverse ARP rather than using frame map ip statements? | |
| MadChef 2002-08-24, 6:10 am |
| Frame Relay the hard way. This is good.
Do you really want the answer?
Really?
Are you sure?
Wouldn't it be more satisfying to figure it out yourself?
No? Wuss.  Build route maps on your spokes to set you next hop for the hub. You have a frame map for that IP, so you'll stop getting all those encapsulation failed debugs.
That's probably what's tripping you up. Let us know if you still have questions.
MadChef | |
|
| No, I am actually using FR maps (a PVC from the HUB to each SPOKE and, only one PVC from each SPOKE to the HUB).
The HUB is using a sub-interface, while all other SPOKEs are using the physical interface itself.
I don't think it is a split-horizon thing, I am using OSPF already.
I tried the policy routing already setting the next hop to be the HUB, I thought this may solve it, but it didn't .. mm.. I will try again though since MadChef thinks that this will resolve it as well. | |
| mosam 2002-08-24, 10:32 am |
| No use..
I tried it again..
access-list 1 permit any
route-map fr_map permit 10
match ip address 1
set ip next-hop 10.10.1.1
int s0
ip policy route-map fr_map
Where int s0 (10.10.1.5/16) is the interface connected to the FR cloud. I am still getting encapsulation failed messeges..
"00:29:58: IP: s=10.10.1.5 (local), d=10.10.1.2 (Serial0), len 100, encapsulation
failed." | |
| darthfeces 2002-08-24, 4:29 pm |
| there is a problem with your layer 2 config
stay there and fix it. | |
|
| When debugging the frame relay packets.. here what I get
"09:06:23: Serial0:Encaps failed--no map entry link 7(IP)."
And, by debugging IP packets, I get...
"00:29:58: IP: s=10.10.1.5 (local), d=10.10.1.2 (Serial0), len 100, encapsulation failed."
Which basically mean that the router knows which interface to direct the packets to, but donno how.. in other words, it is an inverse ARP problem..
Remember that I should not create a FR map statement as originally posted in my first question... if I do so, the problem get resolved, but this is not whats being asked...!! | |
| MadChef 2002-08-25, 9:33 am |
| quote:
Originally posted by mosam
Remember that I should not create a FR map statement as originally posted in my first question... if I do so, the problem get resolved, but this is not whats being asked...!!
It says not to create MULTIPLE maps. You still need a single map to your next hop.
MadChef | |
|
| Yes of course, as I said, I created a single map from each SPOKE to the HUB, otherwise, I won't be able to ping anything in the first place. | |
| Worker 2002-08-26, 4:15 am |
| On the HUB how have you configured the PVC links for the IP addresses?
You have stated that you have a Map on the Spokes to the HUB. What have you got on the HUB for it to understand what IP address is associated with which PVC since you are not using inverse ARP or FR MAP statements how does the router know which DLCI to send the Ping out of. can you post the full config of the HUB and then it might make more sense. | |
| Worker 2002-08-26, 4:20 am |
| the only option i can think of to avoid using FR MAP statements would be to disable Inverse ARP and use frame int dlci statements with sub interfaces (this at least associates an IP address with a DLCI for teh router to send it out of) and means that you aren't using Inverse ARP. I haven't tried this though | |
| MadChef 2002-08-26, 8:12 am |
| quote:
Originally posted by mosam
route-map fr_map permit 10
match ip address 1
set ip next-hop 10.10.1.1
"00:29:58: IP: s=10.10.1.5 (local), d=10.10.1.2 (Serial0), len 100, encapsulation
failed."
You want to set the next hop to 10.10.1.1, yet the debug shows that this next hop is not being set. The failed packet shows a destination of 10.10.1.2, which I guess is another spoke.
My guess is that you're trying to ping that spoke from the other spoke router and don't have your policy applied to locally generated traffic.
ip local policy route-map 10
Other than that, you config looks OK.
MadChef | |
|
| Thanks MadChef.
Yes, "ip local policy route-map fr_map" did it.
Good thread though for everybody else...
 | |
| darthfeces 2002-08-27, 9:23 am |
| this peaked my interest so i went to simulate the
problem, but had my own, such is life.
such as i've formed my neighbor relationships,
but i'm not seeing routes on some routers.
anywho
so the soluton was that the route-map was not being applied by the ip_policy
so next hop was not set ... right ?
i'm going to a bootcamp in a month so i'm going to
crank out the labs to be ready. | |
| rickmb57 2002-09-01, 8:46 am |
| Assuming this is the same scenario I've seen, you only get to use 1 frame-relay map or frame-relay interface-dlci statement on each spoke router. There's also a router hanging off one of the spoke routers.
The issue of course is that you can't get to an IP that's not already described in the frame-relay map table.
If the hub router can get to all the spokes, just use route-mapping to change the next hop ip addr (sourced from a spoke and destined to a spoke router) to be the ip of the hub router.
The next sub issue is how you apply that route-map. Normally you'd apply this to interfaces, but you're pinging from a spoke router to a spoke router (or beyond). So on these routers, use ip local policy. This modifies route policy on packet ORIGINATED by the router. Of course, if you're passing through the router, you apply an ip policy statement to the appropriate interface. | |
| darthfeces 2002-09-02, 12:00 am |
| ok i like pain and suffering
that's why i want to be a ccie
here goes
i have this working
ospf the hard way
e0 of r2 is supposed to be your internet connection,
so in my infinate wisdom
i connected e0 on r2 to the inside of my lan
gave it 192.168.1.5 default route 192.168.1.1
my firewall inside int.
added 192.168.1.5 t ospf.
r1 (the hub)
and r2 can get to the net
r3,4,5 can ping 192.168.1.5 and .255
but not 192.168.1.1 (encapsulation failed)
any ideas ?
i'm tired and my brain hurts. | |
|
| quote:
Originally posted by darthfeces
ok i like pain and suffering
that's why i want to be a ccie
here goes
i have this working
ospf the hard way
e0 of r2 is supposed to be your internet connection,
so in my infinate wisdom
i connected e0 on r2 to the inside of my lan
gave it 192.168.1.5 default route 192.168.1.1
my firewall inside int.
added 192.168.1.5 t ospf.
r1 (the hub)
and r2 can get to the net
r3,4,5 can ping 192.168.1.5 and .255
but not 192.168.1.1 (encapsulation failed)
any ideas ?
i'm tired and my brain hurts.
What is your ospf type ? Try to use point to multipoint instead of the default non-broadcast.
cheers!
csyeo | |
|
| Actually if it is an ethernet interface, it should be BROADCAST and it should be the default network type..
Check this out using..
"show ip ospf interface e0" command.
If it is not broadcast.. use "ip ospf network broadcast" command on e0.
rickmb57, As for the route-map, I already applied that.. .jeee.. it was a pain in the bottom, I can tell u that.. u can easily cause a routing loop if the router you applying a policy routing on has more than two interface connected to other ip networks. Try to PING networks beyond this router point.. | |
| darthfeces 2002-09-02, 11:10 am |
| it is
Ethernet0 is up, line protocol is up
Internet Address 192.168.1.5/24, Area 10
Process ID 1, Router ID 172.168.32.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 172.168.32.1, Interface address 192.168.1.5
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:09
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s) | |
| mosam 2002-09-02, 12:14 pm |
| It is not clear what setup you are using. Is it the same thing I was talking about originally in this thread? Do you have a FR cloud having R1, R2, R3 and R5 connected to? If so, then as we posted originally, and as "csy71" has just indicated, you will have to use "ip ospf network point-to-multipoint" in all serial interfaces connected to the FR cloud.
The reason for having this encapsulation is basically R3, R4 and R5 know the route for 192.168.1.1 but donno how to map this IP to the appropriate DLCI ...
I hope this resolves it anyway.. always use "show ip ospf interface" command to check on the network type of the interface, I would assume it is NON_BROADCAST type. | |
| darthfeces 2002-09-02, 2:41 pm |
| yes,
my frame interfaces are non_broadcast
looks like i completely missed the point
i guess that's the ponit of doing the labs
i could ping all interfaces and assumed it was working.
yes i could ping the 192.168.1.5 interface from anywhere and all routes were present so i thought it was working
in the next hop thread i thought that was the only problem and missed the next evolution.
i 'll try it and let you know | |
| darthfeces 2002-09-02, 3:00 pm |
| i realize that
but it says you can't use
ip ospf network
anywhere in your configuration ?
so how else could it be done ? | |
| darthfeces 2002-09-02, 3:04 pm |
| ok it does work
but as i stated the instructions i have say to not
use ip ospf network anywhere in your config
sure way to lose point in the lab ?
hmmm solution ?
mc ..... please ? | |
|
| In this case, you will need to use policy routing. Take a look at page 1 and 2 of this thread, it should has it all. And be VERY carefull on the route-map you apply in R3, you may cause a loop if the route-map is not correct. After you apply it, make sure you can PING from R5 the networks beyond R3, like the ethernet of R3, and the IP addresses on R4.. | |
| csy71 2002-09-02, 10:38 pm |
| quote:
Originally posted by darthfeces
ok it does work
but as i stated the instructions i have say to not
use ip ospf network anywhere in your config
sure way to lose point in the lab ?
hmmm solution ?
mc ..... please ?
Have you try to redistribute your connect subnet into ospf. Need to setup my lab and have a look at it, will let you know any work around on that.
cheers!
csyeo | |
| darthfeces 2002-09-04, 11:09 am |
| this is what i get on r3
r3#en
12:18:53: IP: s=10.34.1.1 (local), d=224.0.0.5 (Serial1), len 68, sending broad/multicast
12:18:53: IP: s=10.10.1.3 (local), d=10.10.1.1 (Serial0), len 68, policy rejected -- normal forwarding
12:18:53: IP: s=10.10.1.3 (local), d=10.10.1.1 (Serial0), len 68, sending
12:18:53: IP: s=10.34.1.2 (Serial1), d=224.0.0.5, len 68, rcvdping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
12:18:55: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:18:55: IP: route map 10, item 10, permit
12:18:55: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:18:55: IP: local to Serial0 10.10.1.1.
12:18:57: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:18:57: IP: route map 10, item 10, permit
12:18:57: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:18:57: IP: local to Serial0 10.10.1.1.
12:18:59: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:18:59: IP: route map 10, item 10, permit
12:18:59: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:18:59: IP: local to Serial0 10.10.1.1.
12:19:01: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:19:01: IP: route map 10, item 10, permit
12:19:01: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:19:01: IP: local to Serial0 10.10.1.1.
12:19:03: IP: s=10.10.1.1 (Serial0), d=10.10.1.3, len 76, rcvd 0
12:19:03: IP: s=10.34.1.1 (local), d=224.0.0.5 (Serial1), len 68, sending broad/multicast
12:19:03: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:19:03: IP: route map 10, item 10, permit
12:19:03: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:19:03: IP: local to Serial0 10.10.1.1
12:19:03: IP: s=10.34.1.2 (Serial1), d=224.0.0.5, len 68, rcvd 0.
Success rate is 0 percent (0/5)
r3#ping 192.168.1.
12:19:13: IP: s=10.34.1.1 (local), d=224.0.0.5 (Serial1), len 68, sending broad/multicast
12:19:13: IP: s=10.10.1.3 (local), d=10.10.1.1 (Serial0), len 68, policy rejected -- normal forwarding
12:19:13: IP: s=10.10.1.3 (local), d=10.10.1.1 (Serial0), len 68, sending
12:19:13: IP: s=10.34.1.2 (Serial1), d=224.0.0.5, len 68, rcvd 05
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 ms
r3#
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5, len 100, policy match
12:19:15: IP: route map 10, item 10, permit
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5 (Serial0), len 100, policy routed
12:19:15: IP: local to Serial0 10.10.1.1
12:19:15: IP: s=192.168.1.5 (Serial0), d=10.10.1.3 (Serial0), len 100, rcvd 3
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5, len 100, policy match
12:19:15: IP: route map 10, item 10, permit
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5 (Serial0), len 100, policy routed
12:19:15: IP: local to Serial0 10.10.1.1
12:19:15: IP: s=192.168.1.5 (Serial0), d=10.10.1.3 (Serial0), len 100, rcvd 3
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5, len 100, policy match
12:19:15: IP: route map 10, item 10, permit
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5 (Serial0), len 100, policy routed
12:19:15: IP: local to Serial0 10.10.1.1
12:19:15: IP: s=192.168.1.5 (Serial0), d=10.10.1.3 (Serial0), len 100, rcvd 3
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5, len 100, policy match
12:19:15: IP: route map 10, item 10, permit
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5 (Serial0), len 100, policy routed
12:19:15: IP: local to Serial0 10.10.1.1
12:19:15: IP: s=192.168.1.5 (Serial0), d=10.10.1.3 (Serial0), len 100, rcvd 3
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5, len 100, policy match
12:19:15: IP: route map 10, item 10, permit
12:19:15: IP: s=10.10.1.3 (local), d=192.168.1.5 (Serial0), len 100, policy routed
12:19:15: IP: local to Serial0 10.10.1.1
12:19:15: IP: s=192.168.1.5 (Serial0), d=10.10.1.3 (Serial0), len 100, rcvd 3
r3#
r3#
12:19:23: IP: s=10.10.1.1 (Serial0), d=10.10.1.3, len 76, rcvd 0
12:19:23: IP: s=10.34.1.1 (local), d=224.0.0.5 (Serial1), len 68, sending broad/multicast
12:19:23: IP: s=10.34.1.2 (Serial1), d=224.0.0.5, len 68, rcvd 0
r3#
r3#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
12:19:30: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:19:30: IP: route map 10, item 10, permit
12:19:30: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:19:30: IP: local to Serial0 10.10.1.1.
12:19:32: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:19:32: IP: route map 10, item 10, permit
12:19:32: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:19:32: IP: local to Serial0 10.10.1.1
12:19:33: IP: s=10.34.1.1 (local), d=224.0.0.5 (Serial1), len 68, sending broad/multicast
12:19:33: IP: s=10.10.1.3 (local), d=10.10.1.1 (Serial0), len 68, policy rejected -- normal forwarding
12:19:33: IP: s=10.10.1.3 (local), d=10.10.1.1 (Serial0), len 68, send.ing
12:19:33: IP: s=10.34.1.2 (Serial1), d=224.0.0.5, len 68, rcvd 0
12:19:34: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:19:34: IP: route map 10, item 10, permit
12:19:34: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:19:34: IP: local to Serial0 10.10.1.1.
12:19:36: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:19:36: IP: route map 10, item 10, permit
12:19:36: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:19:36: IP: local to Serial0 10.10.1.1.
12:19:38: IP: s=10.10.1.3 (local), d=192.168.1.1, len 100, policy match
12:19:38: IP: route map 10, item 10, permit
12:19:38: IP: s=10.10.1.3 (local), d=192.168.1.1 (Serial0), len 100, policy routed
12:19:38: IP: local to Serial0 10.10.1.1.
Success rate is 0 percent (0/5)
r3#
12:19:43: IP: s=10.10.1.1 (Serial0), d=10.10.1.3, len 76, rcvd 0
12:19:43: IP: s=10.34.1.1 (local), d=224.0.0.5 (Serial1), len 68, sending broad/multicast
12:19:43: IP: s=10.34.1.2 (Serial1), d=224.0.0.5, len 68, rcvd 0
12:19:46: IP: s=10.10.1.3 (local), d=128.59.59.177, len 76, policy rejected -- normal forwarding
12:19:46: IP: s=10.10.1.3 (local), d=128.59.59.177 (Serial0), len 76, sending
12:19:46: IP: s=10.10.1.3 (local), d=128.59.59.177 (Serial0), len 76, encapsulation failed
12:19:46: IP: s=10.34.1.2 (Serial1), d=128.59.59.177 (Serial0), len 76, policy rejected -- normal forwarding
12:19:46: IP: s=10.34.1.2 (Serial1), d=128.59.59.177 (Serial0), g=10.10.1.2, len 76, forward
12:19:46: IP: s=10.34.1.2 (Serial1), d=128.59.59.177 (Serial0), len 76, encapsulation failed
12:19:53: IP: s=10.34.1.1 (local), d=224.0.0.5 (Serial1), len 68, sending broad/multicast
12:19:53: IP: s=10.10.1.3 (local), d=10.10.1.1 (Serial0), len 68, policy rejected -- normal forwarding
12:19:53: IP: s=10.10.1.3 (local), d=10.10.1.1 (Serial0), len 68, sending
12:19:53: IP: s=10.34.1.2 (Serial1), d=224.0.0.5, len 68, rcvd 0
r3#
12:20:03: IP: s=10.10.1.1 (Serial0), d=10.10.1.3, len 76, rcvd 0
12:20:03: IP: s=10.34.1.1 (local), d=224.0.0.5 (Serial1), len 68, sending broad/multicast
12:20:03: IP: s=10.34.1.2 (Serial1), d=224.0.0.5, len 68, rcvd 0u all
All possible debugging has been turned off
r3# | |
| csy71 2002-09-05, 12:05 am |
| Have test it on the lab since like there is no connectivity problem, i use the the frame-relay map statement to map the spoke ip address to the same dlci on every spoke router. I do not use the neighbor command at the spoke router, only at the hub router only.
cheers!
csyeo | |
| darthfeces 2002-09-05, 9:18 am |
| hmmmm ...
i also thought about manually disabling
frame inarp
but if i can ping 192.168.1.5 ? | |
| flox01 2005-08-31, 12:15 am |
| Hi,
try to disable inverse arp ! | |
| haseeb_eng 2005-09-04, 3:20 am |
| Hi guys,
I am glad to see a nice and knowledgable discussion after a long time on this forum. | |
| darthfeces 2005-09-04, 1:09 pm |
| that was sooo.. long ago i barely remember it  | |
| haseeb_eng 2005-09-05, 12:22 am |
| hay darth u r right i didn't checked the date  |
|
|
|
|