«

Hi,
I have 2 spoke locations connected to a hub, but these two locations also
have a pvc between them which I dont want to use. I want all traffic to go
trhu central hub router.
I statically mapped all pvc-to-ip addresses and they all point to central
location.
For example, location1 have pvc 101 to hub, and location2 has pvc 102 to
hub. PVC between spokes is 112 and I dont want to use it.
I disabled arp and inverse arp on both spokes so they dont use pvc which I
didn't manually set.
But for some reason, despite all that, 2 spokes create adjacency over that
phantom pvc.
FR ip addresses:
hub: 10.10.1.9
spoke1: 10.10.1.10
spoke2: 10.10.1.11
PVCs
spoke1-hub: 101
spoke2-hub: 102
spoke1-spoke2: 112

Here is the config for spoke1 (spoke2 is similar)
interface Serial0/0
ip address 10.10.1.10 255.255.255.248
encapsulation frame-relay IETF
no arp frame-relay
! mapping for central hub
frame-relay map ip 10.10.1.9 101 broadcast
! mapping for another spoke so that two spokes can ping each other
! mapping to another spoke is made via hub's pvc
frame-relay map ip 10.10.1.11 101 broadcast
no frame-relay inverse-arp
frame-relay lmi-type ansi

# sh frame map
! there is no mapping for this one, everything looks fine
Serial0/0 (up): ip 0.0.0.0 dlci 112(0x70,0x1C00)
Serial0/0 (up): ip 10.10.1.9 dlci 101(0x65,0x1850), static,
Serial0/0 (up): ip 10.10.1.11 dlci 101(0x65,0x1850), static,

Spokes should create eigrp adjacency only with hub, and all traffic should
go thru hub.
But spokes somehow still manage to create adjacency with each other and
route traffic among them directly over that pvc. When I remove spoke-2-spoke
pvc from FR switch, then it works fine and all traffic goes thru hub.

But when I debug eigrp hello packets I see that they manage to go trhu pvc
112.
01:30:37: Serial0/0(i): dlci 112(0x1C01), pkt type 0x800, datagramsize 64
01:30:37: EIGRP: Received HELLO on Serial0/0 nbr 10.10.1.10

How can I forbid two spokes to use direct PVC between them ?

thanks,
jura

In article <bths5k$o3l$>, says...
> Spokes should create eigrp adjacency only with hub, and all traffic should
> go thru hub.
> But spokes somehow still manage to create adjacency with each other and
> route traffic among them directly over that pvc. When I remove spoke-2-spoke
> pvc from FR switch, then it works fine and all traffic goes thru hub.
>
> But when I debug eigrp hello packets I see that they manage to go trhu pvc
> 112.
> 01:30:37: Serial0/0(i): dlci 112(0x1C01), pkt type 0x800, datagramsize 64
> 01:30:37: EIGRP: Received HELLO on Serial0/0 nbr 10.10.1.10
>

Another thing. It seems that using 'passive interface' would not do much
good since you have just one interface for both connections. You can
always make path between spokes undesirable by using route filtering.

--
Ivan

Jura,

Maybe a neater way of connecting these three sites (which are in a full FR
mesh) would be to create 3 point-to-point connections and increase the
metric so that the connection between the two remote sites wont get used
unless one remote site loses its connection to the hub site?

Regards,

Scott.
\|/
(o o)
---------------------oOOO--(_)--OOOo----------------------
Out the 100Base-T, off the firewall, through the router, down
the T1, over the leased line, off the bridge, nothing but Net.
(Use ROT13 to see my email address)
.oooO Oooo.
----------------------( )---( )-----------------------
\ ( ) /
\_) (_/


"jmarkotic" <> wrote in message
news:bths5k$o3l$...
> Hi,
> I have 2 spoke locations connected to a hub, but these two locations also
> have a pvc between them which I dont want to use. I want all traffic to go
> trhu central hub router.
> I statically mapped all pvc-to-ip addresses and they all point to central
> location.
> For example, location1 have pvc 101 to hub, and location2 has pvc 102 to
> hub. PVC between spokes is 112 and I dont want to use it.
> I disabled arp and inverse arp on both spokes so they dont use pvc which I
> didn't manually set.
> But for some reason, despite all that, 2 spokes create adjacency over that
> phantom pvc.
> FR ip addresses:
> hub: 10.10.1.9
> spoke1: 10.10.1.10
> spoke2: 10.10.1.11
> PVCs
> spoke1-hub: 101
> spoke2-hub: 102
> spoke1-spoke2: 112
>
> Here is the config for spoke1 (spoke2 is similar)
> interface Serial0/0
> ip address 10.10.1.10 255.255.255.248
> encapsulation frame-relay IETF
> no arp frame-relay
> ! mapping for central hub
> frame-relay map ip 10.10.1.9 101 broadcast
> ! mapping for another spoke so that two spokes can ping each other
> ! mapping to another spoke is made via hub's pvc
> frame-relay map ip 10.10.1.11 101 broadcast
> no frame-relay inverse-arp
> frame-relay lmi-type ansi
>
> # sh frame map
> ! there is no mapping for this one, everything looks fine
> Serial0/0 (up): ip 0.0.0.0 dlci 112(0x70,0x1C00)
> Serial0/0 (up): ip 10.10.1.9 dlci 101(0x65,0x1850), static,
> Serial0/0 (up): ip 10.10.1.11 dlci 101(0x65,0x1850), static,
>
> Spokes should create eigrp adjacency only with hub, and all traffic should
> go thru hub.
> But spokes somehow still manage to create adjacency with each other and
> route traffic among them directly over that pvc. When I remove
spoke-2-spoke
> pvc from FR switch, then it works fine and all traffic goes thru hub.
>
> But when I debug eigrp hello packets I see that they manage to go trhu pvc
> 112.
> 01:30:37: Serial0/0(i): dlci 112(0x1C01), pkt type 0x800, datagramsize 64
> 01:30:37: EIGRP: Received HELLO on Serial0/0 nbr 10.10.1.10
>
> How can I forbid two spokes to use direct PVC between them ?
>
> thanks,
> jura
>
>

Huh,
I was not clear enough. There are so many good ways to work around this
situation, but this is a leb scenario from "CCIE practical studies" and
there it says that disabling FR inverse-arp/arp you effectively disable
unwanted PVC.
Well, for some reason that doesn't work for me and I wonder why.
thanks,
j

"scott enwright" <> wrote in message
news:h_8Lb.745$...
> Jura,
>
> Maybe a neater way of connecting these three sites (which are in a full FR
> mesh) would be to create 3 point-to-point connections and increase the
> metric so that the connection between the two remote sites wont get used
> unless one remote site loses its connection to the hub site?
>
> Regards,
>
> Scott.
> \|/
> (o o)
> ---------------------oOOO--(_)--OOOo----------------------
> Out the 100Base-T, off the firewall, through the router, down
> the T1, over the leased line, off the bridge, nothing but Net.
> (Use ROT13 to see my email address)
> .oooO Oooo.
> ----------------------( )---( )-----------------------
> \ ( ) /
> \_) (_/
>
>
> "jmarkotic" <> wrote in message
> news:bths5k$o3l$...
> > Hi,
> > I have 2 spoke locations connected to a hub, but these two locations
also
> > have a pvc between them which I dont want to use. I want all traffic to
go
> > trhu central hub router.
> > I statically mapped all pvc-to-ip addresses and they all point to
central
> > location.
> > For example, location1 have pvc 101 to hub, and location2 has pvc 102 to
> > hub. PVC between spokes is 112 and I dont want to use it.
> > I disabled arp and inverse arp on both spokes so they dont use pvc which
I
> > didn't manually set.
> > But for some reason, despite all that, 2 spokes create adjacency over
that
> > phantom pvc.
> > FR ip addresses:
> > hub: 10.10.1.9
> > spoke1: 10.10.1.10
> > spoke2: 10.10.1.11
> > PVCs
> > spoke1-hub: 101
> > spoke2-hub: 102
> > spoke1-spoke2: 112
> >
> > Here is the config for spoke1 (spoke2 is similar)
> > interface Serial0/0
> > ip address 10.10.1.10 255.255.255.248
> > encapsulation frame-relay IETF
> > no arp frame-relay
> > ! mapping for central hub
> > frame-relay map ip 10.10.1.9 101 broadcast
> > ! mapping for another spoke so that two spokes can ping each other
> > ! mapping to another spoke is made via hub's pvc
> > frame-relay map ip 10.10.1.11 101 broadcast
> > no frame-relay inverse-arp
> > frame-relay lmi-type ansi
> >
> > # sh frame map
> > ! there is no mapping for this one, everything looks fine
> > Serial0/0 (up): ip 0.0.0.0 dlci 112(0x70,0x1C00)
> > Serial0/0 (up): ip 10.10.1.9 dlci 101(0x65,0x1850), static,
> > Serial0/0 (up): ip 10.10.1.11 dlci 101(0x65,0x1850), static,
> >
> > Spokes should create eigrp adjacency only with hub, and all traffic
should
> > go thru hub.
> > But spokes somehow still manage to create adjacency with each other and
> > route traffic among them directly over that pvc. When I remove
> spoke-2-spoke
> > pvc from FR switch, then it works fine and all traffic goes thru hub.
> >
> > But when I debug eigrp hello packets I see that they manage to go trhu
pvc
> > 112.
> > 01:30:37: Serial0/0(i): dlci 112(0x1C01), pkt type 0x800, datagramsize
64
> > 01:30:37: EIGRP: Received HELLO on Serial0/0 nbr 10.10.1.10
> >
> > How can I forbid two spokes to use direct PVC between them ?
> >
> > thanks,
> > jura
> >
> >
>
>

In article <btkhi0$qjj$>, says...
> Huh,
> I was not clear enough. There are so many good ways to work around this
> situation, but this is a leb scenario from "CCIE practical studies" and
> there it says that disabling FR inverse-arp/arp you effectively disable
> unwanted PVC.
> Well, for some reason that doesn't work for me and I wonder why.

Did you pop the interface *after* disabling inverse arp?


--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
************************************************** ******************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
************************************************** ******************

You mean shut/no shut ? Yes, many times with same results.


"Hansang Bae" <> wrote in message
news:...
> In article <btkhi0$qjj$>, says...
> > Huh,
> > I was not clear enough. There are so many good ways to work around this
> > situation, but this is a leb scenario from "CCIE practical studies" and
> > there it says that disabling FR inverse-arp/arp you effectively disable
> > unwanted PVC.
> > Well, for some reason that doesn't work for me and I wonder why.
>
> Did you pop the interface *after* disabling inverse arp?
>
>
> --
>
> hsb
>
> "Somehow I imagined this experience would be more rewarding" Calvin
> *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
> ************************************************** ******************
> Due to the volume of email that I receive, I may not not be able to
> reply to emails sent to my account. Please post a followup instead.
> ************************************************** ******************

In article <btlq6l$hmg$>, says...
> You mean shut/no shut ? Yes, many times with same results.
>
>

Did you check bugs for your IOS version?

--
Ivan

Try

[no] frame-relay inverse-arp protocol dlci


Regards,

Scott.
\|/
(o o)
---------------------oOOO--(_)--OOOo----------------------
Out the 100Base-T, off the firewall, through the router, down
the T1, over the leased line, off the bridge, nothing but Net.
(Use ROT13 to see my email address)
.oooO Oooo.
----------------------( )---( )-----------------------
\ ( ) /
\_) (_/


"jmarkotic" <> wrote in message
news:btkhi0$qjj$...
> Huh,
> I was not clear enough. There are so many good ways to work around this
> situation, but this is a leb scenario from "CCIE practical studies" and
> there it says that disabling FR inverse-arp/arp you effectively disable
> unwanted PVC.
> Well, for some reason that doesn't work for me and I wonder why.
> thanks,
> j
>
> "scott enwright" <> wrote in message
> news:h_8Lb.745$...
> > Jura,
> >
> > Maybe a neater way of connecting these three sites (which are in a full
FR
> > mesh) would be to create 3 point-to-point connections and increase the
> > metric so that the connection between the two remote sites wont get used
> > unless one remote site loses its connection to the hub site?
> >
> > Regards,
> >
> > Scott.
> > \|/
> > (o o)
> > ---------------------oOOO--(_)--OOOo----------------------
> > Out the 100Base-T, off the firewall, through the router, down
> > the T1, over the leased line, off the bridge, nothing but Net.
> > (Use ROT13 to see my email address)
> > .oooO Oooo.
> > ----------------------( )---( )-----------------------
> > \ ( ) /
> > \_) (_/
> >
> >
> > "jmarkotic" <> wrote in message
> > news:bths5k$o3l$...
> > > Hi,
> > > I have 2 spoke locations connected to a hub, but these two locations
> also
> > > have a pvc between them which I dont want to use. I want all traffic
to
> go
> > > trhu central hub router.
> > > I statically mapped all pvc-to-ip addresses and they all point to
> central
> > > location.
> > > For example, location1 have pvc 101 to hub, and location2 has pvc 102
to
> > > hub. PVC between spokes is 112 and I dont want to use it.
> > > I disabled arp and inverse arp on both spokes so they dont use pvc
which
> I
> > > didn't manually set.
> > > But for some reason, despite all that, 2 spokes create adjacency over
> that
> > > phantom pvc.
> > > FR ip addresses:
> > > hub: 10.10.1.9
> > > spoke1: 10.10.1.10
> > > spoke2: 10.10.1.11
> > > PVCs
> > > spoke1-hub: 101
> > > spoke2-hub: 102
> > > spoke1-spoke2: 112
> > >
> > > Here is the config for spoke1 (spoke2 is similar)
> > > interface Serial0/0
> > > ip address 10.10.1.10 255.255.255.248
> > > encapsulation frame-relay IETF
> > > no arp frame-relay
> > > ! mapping for central hub
> > > frame-relay map ip 10.10.1.9 101 broadcast
> > > ! mapping for another spoke so that two spokes can ping each other
> > > ! mapping to another spoke is made via hub's pvc
> > > frame-relay map ip 10.10.1.11 101 broadcast
> > > no frame-relay inverse-arp
> > > frame-relay lmi-type ansi
> > >
> > > # sh frame map
> > > ! there is no mapping for this one, everything looks fine
> > > Serial0/0 (up): ip 0.0.0.0 dlci 112(0x70,0x1C00)
> > > Serial0/0 (up): ip 10.10.1.9 dlci 101(0x65,0x1850), static,
> > > Serial0/0 (up): ip 10.10.1.11 dlci 101(0x65,0x1850), static,
> > >
> > > Spokes should create eigrp adjacency only with hub, and all traffic
> should
> > > go thru hub.
> > > But spokes somehow still manage to create adjacency with each other
and
> > > route traffic among them directly over that pvc. When I remove
> > spoke-2-spoke
> > > pvc from FR switch, then it works fine and all traffic goes thru hub.
> > >
> > > But when I debug eigrp hello packets I see that they manage to go trhu
> pvc
> > > 112.
> > > 01:30:37: Serial0/0(i): dlci 112(0x1C01), pkt type 0x800, datagramsize
> 64
> > > 01:30:37: EIGRP: Received HELLO on Serial0/0 nbr 10.10.1.10
> > >
> > > How can I forbid two spokes to use direct PVC between them ?
> > >
> > > thanks,
> > > jura
> > >
> > >
> >
> >
>
>