From: Cisco Net (network.cisco@gmail.com)
Date: Mon Nov 01 2004 - 20:13:14 GMT-3
I hop eyou have the correct network types on all these routers.
And Check whether the fragmentation is proper on all the rotuers.
Mostly the fagmentation issue. :)
Regards
Cert
On Mon, 1 Nov 2004 18:01:46 -0500, ccie2be <ccie2be@nyc.rr.com> wrote:
> Hi all,
>
> After, with the assistence of people here on GS, I got the FRTS working
> properly, another problem arose.
>
> I have R4 and R3 in 2 different isis areas. Before FRTS is applied to the
> circuit connecting these 2 routers, R3 and R4 form an L2 isis adjacency.
> After I apply the FRTS, the adjacency goes down.
>
> Here's some output from various commands:
>
> Rack1R4#sh clns is
>
> System Id Interface State Type Priority Circuit Id Format
> Rack1R5 Di1 Up L2 0 00 Phase V
> Rack1R3 Se0/0 Init L2 0 00 Phase V
>
> Rack1R3#sh clns is-neighbors
>
> System Id Interface State Type Priority Circuit Id Format
> Rack1R5 Se1/0.35 Up L2 0 00 Phase V
> Rack1R4 Se1/0.34 Up IS 0 00 Phase V
>
> Rack1R4#deb isis adj-packets
> IS-IS Adjacency related packets debugging is on
> Rack1R4#
> *Mar 1 06:07:29.565: ISIS-Adj: Rec serial IIH from DLCI 403 (Serial0/0),
> cir ty
> pe L2, cir id 00, length 1499
> *Mar 1 06:07:29.565: ISIS-Adj: rcvd state DOWN, old state INIT, new state
> INIT
> *Mar 1 06:07:29.565: ISIS-Adj: Action = GOING UP, new type = L2
> *Mar 1 06:07:30.034: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499
> *Mar 1 06:07:30.366: ISIS-Adj: Rec serial IIH from DLCI 403 (Serial0/0),
> cir ty
> pe L2, cir id 00, length 1499
> *Mar 1 06:07:30.366: ISIS-Adj: rcvd state DOWN, old state INIT, new state
> INIT
> *Mar 1 06:07:30.366: ISIS-Adj: Action = GOING UP, new type = L2
> Rack1R4#
>
> Rack1R4#sh policy-map int s0/0
> Serial0/0: DLCI 403 -
>
> Service-policy output: VOIP
>
> Class-map: VOIP (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: access-group 100
> Queueing
> Strict Priority
> Output Queue: Conversation 40
> Bandwidth 200 (kbps) Burst 5000 (Bytes)
> (pkts matched/bytes matched) 0/0
> (total drops/bytes drops) 0/0
>
> Class-map: class-default (match-any)
> 2039 packets, 2853130 bytes
> 5 minute offered rate 13000 bps, drop rate 0 bps
> Match: any
> Rack1R4#sh traffic
>
> Interface Se0/0
> Access Target Byte Sustain Excess Interval Increment Adapt
> VC List Rate Limit bits/int bits/int (ms) (bytes)
> Active
> 403 256000 320 2560 0 10 320 -
> <--- Circuit to R3
>
> But, as I said, as soon as I remove the traffic shaping from the interface,
> isis forms a L2 adjacency between R3 and R4.
>
> Now, with traffic shaping removed, the isis adjacency comes right up.
>
> Rack1R4(config-if)#fram interface-dlci 403
> Rack1R4(config-fr-dlci)#no class SHAPE
> Rack1R4(config-fr-dlci)#
> Rack1R4#
> *Mar 1 06:17:38.343: %SYS-5-CONFIG_I: Configured from console by console
> Rack1R4#SH clns is
> Rack1R4#SH clns is-neighbors
>
> System Id Interface State Type Priority Circuit Id Format
> Rack1R5 Di1 Up L2 0 00 Phase V
> Rack1R3 Se0/0 Up L2 0 00 Phase V
>
> Anyone have any ideas why traffic is causing this problem?
>
> While there's on voice traffic, even if voice was using all 200k reserved
> for it, there would still be 56k left for isis. Isn't that enough?
>
> TIA, Tim
>
> ----- Original Message -----
> From: "ccie2be" <ccie2be@nyc.rr.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study" <ccielab@groupstudy.com>
> Sent: Monday, November 01, 2004 4:24 PM
> Subject: Re: Interesting FRTS problem
>
> > Thanks to everyone that replied. Adding mincir fixed the problem
> > immediately.
> >
> > Unfortunately, when I thought about using the mincir parameter what I
> > remembered about that was that it is only used in combo with adaptive
> > shaping - at least, that's what stuck in my head even though I had heard
> > about this exception.
> >
> > So everyone take note:
> >
> > frame-relay mincir MUST be configured if you're using MQC to reserve more
> > than half the cir on a pvc regardless of whether adaptive shaping is
> > configured.
> >
> > Thanks again. Tim
> >
> >
> > ----- Original Message -----
> > From: "ccie2be" <ccie2be@nyc.rr.com>
> > To: "Group Study" <ccielab@groupstudy.com>
> > Sent: Monday, November 01, 2004 3:52 PM
> > Subject: Interesting FRTS problem
> >
> >
> > > Hi guys,
> > >
> > > I configured the following frame relay shaping parameters on an
> interface
> > with
> > > 2 p2p sub-interfaces:
> > >
> > > map-class frame-relay SHAPE
> > > frame-relay cir 256000
> > > frame-relay bc 2560
> > > frame-relay fair-queue
> > > frame-relay fragment 320
> > >
> > > I then applied this class to the physical interface with the command,
> > frame
> > > class SHAPE, thinking that each sub-interface will inherit the
> parameters
> > I
> > > had already configured.
> > >
> > > Then I configured MQC to prioritize voice traffic by doing the
> following:
> > >
> > > class-map match-all VOIP
> > > match access-group 100
> > > !
> > > !
> > > policy-map VOIP
> > > class VOIP
> > > priority 200
> > >
> > > But, when I tried to apply to service-policy to the map-class
> frame-relay,
> > I
> > > got the following console message:
> > >
> > > I/f Serial1/0 DLCI 301 class VOIP requested bandwidth 200 (kbps),
> > available
> > > only 128 (kbps)
> > >
> > > I did a show traffic-shaping and got this:
> > >
> > > Rack1R3#SH TRAFfic-shape
> > >
> > > Interface Se1/0
> > > Access Target Byte Sustain Excess Interval Increment
> > Adapt
> > > VC List Rate Limit bits/int bits/int (ms) (bytes)
> > Active
> > > 301 256000 320 2560 0 10 320 -
> > > 302 256000 320 2560 0 10 320 -
> > >
> > > Interface Se1/0.34
> > > Access Target Byte Sustain Excess Interval Increment
> > Adapt
> > > VC List Rate Limit bits/int bits/int (ms) (bytes)
> > Active
> > > 304 256000 320 2560 0 10 320 -
> > >
> > > Interface Se1/0.35
> > > Access Target Byte Sustain Excess Interval Increment
> > Adapt
> > > VC List Rate Limit bits/int bits/int (ms) (bytes)
> > Active
> > > 305 256000 320 2560 0 10 320 -
> > >
> > >
> > > It seems like the router is taking the 256k cir and dividing up between
> > the 2
> > > sub-interfaces so that only 128k is available rather than giving each
> dlci
> > > 256k of cir. Is this what is going on?
> > >
> > > I also tried to apply the map-class to each dlci individually and got
> the
> > same
> > > error message. So now I can't apply the service-policy to either the
> > physical
> > > interface or to the individual sub-interfaces.
> > >
> > > How do I fix this problem?
> > >
> > > Any help or advice would be greatly appreciated.
> > >
> > > TIA, Tim
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:37 GMT-3