From: Le Dinh An (anld@ispco.com.vn)
Date: Wed Dec 11 2002 - 00:07:22 GMT-3
Hi,
I don't know if I'm being with you or not, but I will show you here what
I had in my lab, hope it could help you somehow.
Doug Calton wrote:
Sorry - this is just too complicated to explain. Let me back this up to a
more "theoretical" level. Let's say I have a PC attached to an Ethernet
interface of a router - say 192.168.1.0 network, and that the router is
attached via a serial interface to a frame-relay cloud that accesses
multiple remote hubs. One of those remote hubs has another ethernet
interface - say 10.1.0.0 subnet.
The frame relay cloud has a subnet of its own defined between the spoke and
the various hubs. I have configured interface-dlci statements as required
(could also be map statements - no real difference) to establish my partial
mesh between the spoke and the hubs.
Next, I add a static route statement to the SPOKE router like "ip route
10.1.0.0 0.0.255.255 interface serial 0".
I see that you have two subinterfaces, have you tried pointing these
routes to them, serial 0.xx? In my lab I used dynamic routing protocol,
and only the prefered route was on the routing table regardless of two
physical links to the destination LAN subnet. So let say if in the
routing table, the route to the destination address is reached via serial
0.1, if i set ip next-hop to serial 0.2, i'll have encapsulation failed
messages. In my lab I only used the interface-dlci command.
The problem was then solved by changing some parameters in order to have
both two routes, using two subinterfaces in the routing table.
Don't know if this is similiar to your problem now :-) .
Finally , I try to ping from the PC on network 192.168.1.0, and what happens
is that I get "encapsulation failure" for the traffic being routed out
serial 0. This is not surprizing, because the frame relay network has no
idea which dlci to use to route 10.1.0.0 traffic - it only knows the
frame-relay subnet through inverse arp or map statements.
If I replace the dlci statement for the remote hub (that is connected to the
10.1 subnet) with a map statement linking the dlci to the pinged remote
address (such as 10.1.0.1), it works. This shows that - when you route to
an interface, the next hop address used for the output layer 2 is the
destination address. On a true broadcast network, proxy arp kicks in to
reply to arp requests, but Frame Relay has no such facility.
At least I think that is what is happening....
----- Original Message -----
From: "Chuck Church" <cchurch@optonline.net> To: "Doug Calton" <dcalton@fuse.net> ; <ccielab@groupstudy.com> Sent: Tuesday, December 10, 2002 11:05 AM
Subject: Re: Frame Relay and Policy Routing
So the problem is the hub router being able to reach the LAN on the other
side of the 2 MP spoke routers? Does the hub have a route for that
subnet?
Are you running a routing protocol? Also, you do have different subnets
on
the two subinterfaces, right?
Chuck Church
CCIE #8776, MCNE, MCSE
----- Original Message -----
From: "Doug Calton" <dcalton@fuse.net> To: "Chuck Church" <cchurch@optonline.net> ; <ccielab@groupstudy.com> Sent: Tuesday, December 10, 2002 10:54 AM
Subject: Re: Frame Relay and Policy Routing
The specific configuration is set up so that there are two
subinterfaces.
The first goes to a point-to-point (mandated in the lab) connection to
one
remote spoke router. The second subinterface connects via multipoint to
two
other spokes, with all these spoke interfaces sharing the same subnet
with
this second subinterface. The target LAN actually connects these two
other
spoke routers on another subnet.
In configuring the second subinterface, I can either specify both dlci's
for
the remote spoke routers (interface-dlci) and rely on inarp OR I could
use
frame relay map to manually associate the IPs for those remote spokes to
the
DLCIs. Using the latter, I can substitute an address for the target LAN
to
get the request to "work", but of course, I cannot then access that
spoke
router directly anymore. Of course, it is not the right solution.
----- Original Message -----
From: "Chuck Church" <cchurch@optonline.net> To: "Doug Calton" <dcalton@fuse.net> ; <ccielab@groupstudy.com> Sent: Tuesday, December 10, 2002 10:09 AM
Subject: Re: Frame Relay and Policy Routing
Doug,
You've got subinterfaces on the hub router, one of which is a
multipoint. What does the addressing scheme look like and what are
you
trying to ping from/to to test it?
Chuck Church
CCIE #8776, MCNE, MCSE
----- Original Message -----
From: "Doug Calton" <dcalton@fuse.net> To: "Chuck Church" <cchurch@optonline.net> ; <ccielab@groupstudy.com> Sent: Tuesday, December 10, 2002 4:15 AM
Subject: Re: Frame Relay and Policy Routing
Thanks - the exercise is very specific as to the placement of the
policy,
as
well as the use of set interface over set next-hop. Oddly, the
target
subnet is linked to both spokes of the hub, and the exercise has me
shutdown
the subnet I/F on the non-target IP. Frame maps is all I see, but
it
targets IP addrs, and not the whole subnet, unfortunately.
----- Original Message -----
From: "Chuck Church" <cchurch@optonline.net> To: "Doug Calton" <dcalton@fuse.net> ; <ccielab@groupstudy.com> Sent: Monday, December 09, 2002 8:21 PM
Subject: Re: Frame Relay and Policy Routing
Doug,
I'm not sure if I'm reading it right, but it sounds like
you're
policy
routing on the wrong router. I don't see why policy routing would
be
required at the hub router, as it's got PVCs to all the others,
right?
This
sounds a lot like one of the bootcamp labs, if I remember right.
If
router
A is your hub, with B and C as spokes, you could policy route on B
so
that
traffic to C, make A the next hop. Same principle is applied to
C.
The
other way of course would be using frame maps.
Chuck Church
CCIE #8776, MCNE, MCSE
----- Original Message -----
From: "Doug Calton" <dcalton@fuse.net> To: <ccielab@groupstudy.com> Sent: Monday, December 09, 2002 4:40 PM
Subject: Frame Relay and Policy Routing
I am working on a training scenario where we are to route
traffic
destined
for
a specific IP subnet through a Frame Relay partially meshed
network,
by
using
the "set interface" command of the route-map subcommand. The
router
to
which
the policy is applied uses subinterfaces, and the subinterface
that
I
am
setting in route-map is a multipoint interface acting as the hub
to
a
frame
relay subnet.
When configured normally, the routing policy works, but the
packet
is
dropped
because of encapsulation failure leaving the frame relay subint.
I
can
get
the configuration to "work" by configuring a frame-relay map
statement
for
a
destination IP address in the target subnet, but this is not an
ideal
solution. Is there an more generalized way to encapsulate the
exiting
traffic
to the appropriate dlci, or possibly another approach to
allowing
this
traffic
to traverse the frame-relay network? Thanks!
.
.
.
-- Le Dinh An Network Consultant Cell: 84 913 100 478 .
This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:43 GMT-3