From: Chuck Church (cchurch@optonline.net)
Date: Tue Dec 10 2002 - 18:12:43 GMT-3
I think that is the correct behavior. Even if that destination workstation
was 10 hops away, as long as the spoke router on your end can associate a
DLCI with the destination address, it would work. If there was such a think
as 'proxy inverse arp' it would work here.
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 3:57 PM
Subject: Re: Frame Relay and Policy Routing
> 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".
>
> 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!
> > > > > > > .
> > > > > .
.
This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:43 GMT-3