RE: Frame-relay issues:

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


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.
> >
> >
>



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