From: ccie2be (ccie2be@nyc.rr.com)
Date: Mon Nov 01 2004 - 20:01:46 GMT-3
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
This archive was generated by hypermail 2.1.4 : Thu Dec 02 2004 - 06:57:37 GMT-3