RE: Frame-relay issues:

From: Darby Weaver (darbyweaver@yahoo.com)
Date: Sat Apr 21 2007 - 23:51:44 ART

Next message: Darby Weaver: "RE: Frame-relay issues:"
Previous message: Darby Weaver: "RE: Frame-relay issues:"
Maybe in reply to: Victor Cappuccio: "RE: Frame-relay issues:"
Next in thread: Darby Weaver: "RE: Frame-relay issues:"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

OK -

I hate to add to the weirdness, however, I'm expecting
some frame-relay inverse-arp mappings and I am not
getting them.

So far I did the following:

1. shut the interface s0/0/0
2. disabled frame-relay
3. still had debug running for interface s0/0/0 and
debugging fram packets - so I could see the fram
packets for inverse-arp.
4. Turned on the interface first.
5. Enabled Frame-Relay
6. Sh frame pvc before and after - one with a blank
for output and another populated.
7. Sh fram map - and...

=============================

Rack01R1#sh fram pvc

Rack01R1#conf t
Enter configuration commands, one per line. End with
CNTL/Z.
Rack01R1(config)#int s0/0/0
Rack01R1(config-if)#no shut
Rack01R1(config-if)#encap f
*Apr 22 02:48:26.107: %LINK-3-UPDOWN: Interface
Serial0/0/0, changed state to up
*Apr 22 02:48:27.107: %LINEPROTO-5-UPDOWN: Line
protocol on Interface Serial0/0/0, changed state to up
Rack01R1(config-if)#encap fram
Rack01R1(config-if)#do sh fram pvc

PVC Statistics for interface Serial0/0/0 (Frame Relay
DTE)
Rack01R1(config-if)#
*Apr 22 02:48:38.119: Serial0/0/0(o): dlci
115(0x1C31), pkt encaps 0x0300 0x8000 0x0000 0x806
(ARP), datagramsize 34
*Apr 22 02:48:38.119: FR: Sending INARP Request on
interface Serial0/0/0 dlci 115 for link 7(IP)
*Apr 22 02:48:38.119: Serial0/0/0(o): dlci
105(0x1891), pkt encaps 0x0300 0x8000 0x0000 0x806
(ARP), datagramsize 34
*Apr 22 02:48:38.119: FR: Sending INARP Request on
interface Serial0/0/0 dlci 105 for link 7(IP)
*Apr 22 02:48:38.211: broadcast dequeue
*Apr 22 02:48:38.211: Serial0/0/0(o):Pkt sent on dlci
115(0x1C31), pkt encaps 0x300 0x8000 0x0 0x806
(ARP), datagramsize 34
*Apr 22 02:48:38.211: broadcast dequeue
Rack01R1(config-if)#
*Apr 22 02:48:38.211: Serial0/0/0(o):Pkt sent on dlci
105(0x1891), pkt encaps 0x300 0x8000 0x0 0x806
(ARP), datagramsize 34
*Apr 22 02:48:38.231: Serial0/0/0(i): dlci
115(0x1C31), pkt encaps 0x0300 0x8000 0x0000 0x806
(ARP), datagramsize 34
*Apr 22 02:48:38.231: Serial0/0/0: frame relay INARP
received
*Apr 22 02:48:38.235: Serial0/0/0(i): dlci
105(0x1891), pkt encaps 0x0300 0x8000 0x0000 0x806
(ARP), datagramsize 34
*Apr 22 02:48:38.235: Serial0/0/0: frame relay INARP
received
Rack01R1(config-if)#do sh fram map

Rack01R1(config-if)#
*Apr 22 02:48:46.799: Serial0/0/0(i): dlci
115(0x1C31), NLPID 0x3CC(IP), datagramsize 332
*Apr 22 02:48:46.839: Serial0/0/0(i): dlci
105(0x1891), NLPID 0x3CC(IP), datagramsize 332
*Apr 22 02:48:46.883: Serial0/0/0(i): dlci
105(0x1891), NLPID 0x3CC(IP), datagramsize 332
Rack01R1(config-if)#
*Apr 22 02:49:03.699: Serial0/0/0(i): dlci
115(0x1C31), NLPID 0x3CC(IP), datagramsize 332
*Apr 22 02:49:03.739: Serial0/0/0(i): dlci
105(0x1891), NLPID 0x3CC(IP), datagramsize 332
*Apr 22 02:49:03.783: Serial0/0/0(i): dlci
105(0x1891), NLPID 0x3CC(IP), datagramsize 332
Rack01R1(config-if)#do sh fram pvc

PVC Statistics for interface Serial0/0/0 (Frame Relay
DTE)

              Active Inactive Deleted
Static
  Local 0 0 0
0
  Switched 0 0 0
0
  Unused 2 8 0
0

DLCI = 102, DLCI USAGE = UNUSED, PVC STATUS =
INACTIVE, INTERFACE = Serial0/0/0

  input pkts 5 output pkts 1 in
bytes 1362
  out bytes 34 dropped pkts 0 in
pkts dropped 0
  out pkts dropped 0 out bytes dropped
0
  in FECN pkts 0 in BECN pkts 0
out FECN pkts 0
  out BECN pkts 0 in DE pkts 0
out DE pkts 0
  out bcast pkts 1 out bcast bytes 34
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:00:42, last time pvc status
changed 00:00:42

DLCI = 106, DLCI USAGE = UNUSED, PVC STATUS =
INACTIVE, INTERFACE = Serial0/0/0

  input pkts 0 output pkts 0 in
bytes 0
  out bytes 0 dropped pkts 0 in
pkts dropped 0
  out pkts dropped 0 out bytes dropped
0
  in FECN pkts 0 in BECN pkts 0
out FECN pkts 0
  out BECN pkts 0 in DE pkts 0
out DE pkts 0
  out bcast pkts 0 out bcast bytes 0
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:00:46, last time pvc status
changed 00:00:46
--More--
*Apr 22 02:49:23.795: Serial0/0/0(i): dlci
115(0x1C31), NLPID 0x3CC(IP), datagramsize 332
*Apr 22 02:49:23.839: Serial0/0/0(i): dlci
105(0x1891), NLPID 0x3CC(IP), datagramsize 332
*Apr 22 02:49:23.879: Serial0/0/0(i): dlci
105(0x1891), NLPID 0x3CC(IP), datagramsize 332
*Apr 22 02:49:24.195: Serial0/0/0(i): dlci
115(0x1C31), pkt type 0x2000, datagramsize 324
*Apr 22 02:49:24.235: Serial0/0/0(i): dlci
105(0x1891), pkt type 0x2000, datagramsize 324

DLCI = 114, DLCI USAGE = UNUSED, PVC STATUS =
INACTIVE, INTERFACE = Serial0/0/0

  input pkts 5 output pkts 1 in
bytes 1354
  out bytes 34 dropped pkts 0 in
pkts dropped 0
  out pkts dropped 0 out bytes dropped
0
  in FECN pkts 0 in BECN pkts 0
out FECN pkts 0
  out BECN pkts 0 in DE pkts 0
out DE pkts 0
  out bcast pkts 1 out bcast bytes 34
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:00:49, last time pvc status
changed 00:00:49

DLCI = 116, DLCI USAGE = UNUSED, PVC STATUS =
INACTIVE, INTERFACE = Serial0/0/0

Nada...

Hmmm...

Time for a wr and reload.

--- Darby Weaver <darbyweaver@yahoo.com> wrote:

> Todd,
>
> Seriously what version of IOS and what model of
> routers.
>
> When this happens to me, if it happens to me (which
> it
> rarely does as I make it a rule to shut the
> interface
> before enabling frame-relay encapsulation - however
> I
> realize how this happens and that it could be
> present
> in any given lab), what I do is:
>
> 1. clear fram inarp - ought to work but I never
> trust
> it.
>
> 2. shut down the interface with two commands
> prominent
> under the interface:
>
> encap fram
> no fram inv
>
> 3. reload the router
>
> 4. no shut the interface and then...
>
> 5. sh fram map
>
> Are they gone yet...
>
>
> Now we could just as easily change the encapsulation
> and change it back.
>
> But if we did and the int was not down - ooops they
> would be back again.
>
> Let me know if you are doing this and it is still
> happening.
>
>
> However it helps to remember what the technology is
> doing whenever inverse arp is being performed.
>
> And a good debug command may be in order:
>
> debug frame packet - ought to do the trick.
>
> What is the output - turn it on as you are
> completing
> each step.
>
> And if you have more interfaces with frame-relay
> enabled get a little more specific.
>
> debug interfaces s0/0/0
>
> and then debug fram packet.
>
> That should do it...
>
>
> What are you seeing...
>
>
> Might be weird, but help us out a bit.
>
>
> --- "Todd, Douglas M." <DTODD@PARTNERS.ORG> wrote:
>
> > UGH!!! This is driving me nuts....
> >
> > Rack1R1(config)#default int s1/0
> > Building configuration...
> > % Invalid input detected at '^' marker.
> > %Cannot remove PVC as being referenced by map
> > statement
> > % Error(s) seen setting interface Serial1/0 to
> it's
> > default config
> > Rack1R1(config)#
> >
> > pasted the config back on:
> >
> > in a 60 seconds the 0.0.0.0's come back again.
> >
> > NEXT:
> > Shut the interface:
> > removed the config
> > pasted the config
> > no sh the interface
> > they are back again...
> >
> > Even after a reload they come back.
> >
> > DMT
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: John Jones [mailto:acer0001@gmail.com]
> > Sent: Sat 4/21/2007 1:22 PM
> > To: Todd, Douglas M.
> > Cc: Victor Cappuccio; ccielab@groupstudy.com
> > Subject: Re: Frame-relay issues:
> >
> > Shut down the interface, change the encapsulation
> to
> > another protocol, say
> > PPP, bring the interface up again. This should
> clear
> > all mappings. Shut down
> > interface again and specify encap frame. Setup
> your
> > fr maps again, save
> > to nvram, and then bring up the interface; your
> > mapping should be correct.
> > If not, a reboot of the router is needed to remove
> > the mappings to 0.0.0.0.
> >
> > HTH,
> >
> > John
> >
> >
> > On 4/21/07, Todd, Douglas M. <DTODD@partners.org>
> > wrote:
> > >
> > > Thanks-
> > >
> > > I have already disabled inverse arp on the
> > physical interfaces. Seems the
> > > router is still building a table for those DLCIs
> > which are not used in
> > > this lab.
> > > I am getting ospf/pim adjs from routers which
> are
> > in different networks
> > > even
> > > with inverse arp disabled on the physical
> > interfaces.
> > >
> > > DMT
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Victor Cappuccio
> > [mailto:victor@ccbootcamp.com]
> > > Sent: Sat 4/21/2007 10:45 AM
> > > To: Todd, Douglas M.; ccielab@groupstudy.com
> > > Subject: RE: Frame-relay issues:
> > >
> > >
> > > Good Point of reference
> > >
> > >
> >
>
http://www.groupstudy.com/archives/ccielab/200503/msg00398.html
> > >
> > >
> > >
> > > thanks,
> > > Victor Cappuccio.-
> > > Network Learning Inc - A Cisco Sponsored
> > Organization (SO) YES! We take
> > > Cisco Learning credits!
> > > victor@ccbootcamp.com
> > > http://www.ccbootcamp.com (Cisco Training and
> > Rental Racks)
> > > http://www.ccbootcamp.com/groupstudy.html
> > (groupstudy member discounts!)
> > > Voice: 702-968-5100
> > > FAX: 702-446-8012
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com on behalf of Todd,
> > Douglas M.
> > > Sent: Sat 4/21/2007 7:35
> > > To: ccielab@groupstudy.com
> > > Subject: FW: Frame-relay issues:
> > >
> > > All:
> > >
> > > I am getting these bogus frame-relay maps on 2
> > routers. I have reloaded
> > > the
> > > router w/the interfaces shutdown with the
> > configuration below. It's like
> > > frame-relay arp is "kind" of working when it's
> not
> > enabled at all on the
> > > interface.
> > >
> > > Ideas?
> > >
> > > Thanks..
> > > Rack1R1#sh run int s1/0
> > > Building configuration...
> > >
> > > Current configuration : 321 bytes
> > > !
> > > interface Serial1/0
> > > ip address 136.1.15.1 255.255.255.0
> > > ip pim sparse-dense-mode
> > > encapsulation frame-relay
> > > ip ospf authentication message-digest
> > > ip ospf message-digest-key 1 md5 CISCO
> > > ip ospf network point-to-point
> > > no arp frame-relay
> > > frame-relay map ip 136.1.15.5 105 broadcast
> > > no frame-relay inverse-arp
> > > end
> > > Rack1R1#sh frame-relay map
> > > Serial1/0 (up): ip 0.0.0.0 dlci 102(0x66,0x1860)
> > > broadcast,
> > > CISCO, status defined, active
> > > Serial1/0 (up): ip 0.0.0.0 dlci 103(0x67,0x1870)
> > > broadcast,
> > > CISCO, status defined, inactive
> > > Serial1/0 (up): ip 0.0.0.0 dlci 104(0x68,0x1880)
> > > broadcast,
> > > CISCO, status defined, active
> > > Serial1/0 (up): ip 136.1.15.5 dlci
> > 105(0x69,0x1890), static,
> > > broadcast,
> > > CISCO, status defined, active
> > > Serial1/0 (up): ip 0.0.0.0 dlci 113(0x71,0x1C10)
> > > broadcast,
> > > CISCO, status defined, inactive
> > > Rack1R1#
> > >
> > >
> > >
> > >
> > >
> > > The information transmitted in this electronic
> > communication is intended
> > > only
> > > for the person or entity to whom it is addressed
> > and may contain
> > > confidential
> > > and/or privileged material. Any review,
> > retransmission, dissemination or
> > > other
> > > use of or taking of any action in reliance upon
> > this information by
> > > persons or
> > > entities other than the intended recipient is
> > prohibited. If you received
> > > this
> > > information in error, please contact the
> > Compliance HelpLine at
> > > 800-856-1983 and
> > > properly dispose of this information.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > The information transmitted in this electronic
> > communication is intended
> > > only
> > > for the person or entity to whom it is addressed
> > and may contain
> > > confidential
> > > and/or privileged material. Any review,
> > retransmission, dissemination or
> > > other
> > > use of or taking of any action in reliance upon
> > this information by
> > > persons or
> > > entities other than the intended recipient is
> > prohibited. If you received
> > > this
> > > information in error, please contact the
> > Compliance HelpLine at
> > > 800-856-1983 and
> > > properly dispose of this information.
> > >
> > >
> >
>

Next message: Darby Weaver: "RE: Frame-relay issues:"
Previous message: Darby Weaver: "RE: Frame-relay issues:"
Maybe in reply to: Victor Cappuccio: "RE: Frame-relay issues:"
Next in thread: Darby Weaver: "RE: Frame-relay issues:"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Tue May 01 2007 - 08:28:36 ART