From: Scott Morris (swm@emanon.com)
Date: Thu Jun 19 2003 - 21:48:17 GMT-3
Interesting idea, but no. Because in the prefix list syntax, you have
no place to put a mask, you simply put a prefix length.
ip prefix-list list-name [seq seq-value] {deny network/length | permit
network/length}[ge ge-value] [le le-value]
To deny the default route 0.0.0.0/0:
ip prefix-list abc deny 0.0.0.0/0
To permit the prefix10.0.0.0/8:
ip prefix-list abc permit10.0.0.0/8
To accept a mask length of up to 24 bits in routes with the prefix
192/8:
ip prefix-list abc permit 192.168.0.0/8 le 24
To deny mask lengths greater than 25 bits in routes with a prefix of
192/8:
ip prefix-list abc deny 192.168.0.0/8 ge 25
To permit mask lengths from 8 to 24 bits in all address space:
ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24
To deny mask lengths greater than 25 bits in all address space:
ip prefix-list abc deny 0.0.0.0/0 ge 25
To deny all mask lengths within the network 10/8:
ip prefix-list abc deny 10.0.0.0/8 le 32
To deny all masks with a length greater than or equal to 25 bits within
the network 192.168.1/24:
ip prefix-list abc deny 192.168.1.0/24 ge 25
To permit all routes:
ip prefix-list abc permit 0.0.0.0/0 le 32
So you get a network with an overall mask (impossible to specify even or
odd by # of bits) and then a ge/le argument.
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_command_
reference_chapter09186a00800ca79d.html#1215231
(So the short (or long) of it is that you would have to spell out each
network being even or odd in order to make it work, no summary method)
Hope that helps,
Scott
-----Original Message-----
From: steve r [mailto:route2hell@hotmail.com]
Sent: Thursday, June 19, 2003 7:29 PM
To: Brian Dennis; 'Nguyen Hoang Long'; 'Scott Morris'; ZaferP@koc.net;
ccielab@groupstudy.com
Cc: GokhanS@koc.net
Subject: Prefix list question abouts odds and even routes
Can prefix lists block all the odd or even routes like permiting only
even subnets in 192.168.2-254.X by matching a bit in the prefix list ?
Steve R
----- Original Message -----
From: "Brian Dennis" <brian@labforge.com>
To: "'Nguyen Hoang Long'" <ng-hlong@hn.vnn.vn>; "'Scott Morris'"
<swm@emanon.com>; <ZaferP@koc.net>; <ccielab@groupstudy.com>
Cc: <GokhanS@koc.net>
Sent: Wednesday, June 18, 2003 1:15 AM
Subject: RE: CBWFQ-FRTS-RSVP
> Did you mean to send this to someone else? I was just commenting on
> the default serial interface bandwidth.
>
> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
>
> -----Original Message-----
> From: Nguyen Hoang Long [mailto:ng-hlong@hn.vnn.vn]
> Sent: Tuesday, June 17, 2003 10:09 PM
> To: Brian Dennis; 'Scott Morris'; ZaferP@koc.net;
> ccielab@groupstudy.com
> Cc: GokhanS@koc.net
> Subject: Re: CBWFQ-FRTS-RSVP
>
> But Cisco does not say so, here the link:
>
> http://www.cisco.com/warp/public/105/cbwfq_frpvs.html#configurationnot
> es
>
> <quote>
> a.. When the bandwidth and priority commands calculate the total
> amount of bandwidth available on an entity, the following guidelines
> are invoked when
> the entity is a shaped Frame Relay permanent virtual circuit (PVC):
>
> a.. If a Minimum Acceptable Committed Information Rate (minCIR) is
> not configured, the CIR is divided by two.
>
> b.. If a minCIR is configured, the minCIR setting is used in the
> calculation.
>
> c.. The full bandwidth from the above rate can be assigned to
> bandwidth and priority classes. Thus, the max-reserved-bandwidth
> command is not supported on Frame Relay PVCs, although you should take
> care to ensure that
> the amount of bandwidth configured is large enough to also accommodate
> Layer
> 2 overhead. See What Bytes Are Counted by IP to ATM CoS Queueing?.
>
> a.. Avoid setting the CIR or minCIR at the access rate. Otherwise, you
> may see output queues building up and causing big delays in CBWFQ
> classes. The
> reason is that the shape rate does not take into account the overhead
> bytes
> of the flag and Cyclic Redundancy Check (CRC) fields, so shaping at
line
> rate is actually oversubscribing and will cause interface congestion.
> There
> really is no reason to shape at the access rate. You should always
> traffic
> shape at 95 percent of the access rate or, more generally, the
aggregate
> shaped rate should always be 95 percent below the access rate.
>
> <quote>
>
> I have tested and it works as documented, do you have any comment on
> that?
>
> Thanks,
> Long
>
> ----- Original Message -----
> From: "Brian Dennis" <brian@labforge.com>
> To: "'Scott Morris'" <swm@emanon.com>; <ZaferP@koc.net>;
> <ccielab@groupstudy.com>
> Cc: <GokhanS@koc.net>
> Sent: Wednesday, June 18, 2003 2:30 AM
> Subject: RE: CBWFQ-FRTS-RSVP
>
>
> > As a side note "low speed" physical interfaces default to 128k.
> >
> > Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Scott Morris
> > Sent: Tuesday, June 17, 2003 4:59 AM
> > To: ZaferP@koc.net; ccielab@groupstudy.com
> > Cc: GokhanS@koc.net
> > Subject: RE: CBWFQ-FRTS-RSVP
> >
> > The default reservable bandwidth is 75% of the presumed link
> bandwidth,
> > whatever that may be. If you do a show interface, you can figure
> > that part out. Physical serial interfaces, the default assumed
> > bandwidth
> is
> > 1.544M. On sub-interfaces, it actually varies per IOS train on what
> the
> > default is, so just do a 'show interface' to see that.
> >
> > Scott
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > ZaferP@koc.net
> > Sent: Tuesday, June 17, 2003 4:07 AM
> > To: ccielab@groupstudy.com
> > Cc: GokhanS@koc.net
> > Subject: CBWFQ-FRTS-RSVP
> >
> >
> > Simple and straight question:
> >
> > When using FRTS with CBWFQ or RSVP, is the reservable bandwith is
> >
> > a) % 75 of CIR
> > b) %75 of MINCIR
> > c) CIR
> > d) MINCIR
> > e) None of the above
> >
> > Plese respond with an offical link if possible not just guessing.
> >
> > Regards
> >
> > Zafer
> >
> >
> ______________________________________________________________________
> __
> > _____
> > ________________________________________________________________
> >
> > Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor
> > olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa,
> > icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz.
> > Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz
> > ve tum
> kopyalarini
> > mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde,
> > herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi
> > satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri
> > tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin -
> > virus koruma sistemleri ile kontrol ediliyor olsa bile
> > - virus icermedigini garanti etmez ve meydana gelebilecek
> > zararlardan dogacak hicbir sorumlulugu kabul etmez.
> >
> > This message is intended solely for the use of the individual or
> entity
> > to whom it is addressed , and may contain confidential information.
> If
> > you are not the intended recipient of this message or you receive
> > this mail in error, you should refrain from making any use of the
> > contents and from opening any attachment. In that case, please
> > notify the
> sender
> > immediately and return the message to the sender, then, delete and
> > destroy all copies. This e-mail message, could not be copied,
> published
> > or sold for any reason. This e-mail message has been swept by
> anti-virus
> > systems for the presence of computer viruses. In doing so, however,
> > sender cannot warrant that virus or other forms of data corruption
> may
> > not be present and do not take any responsibility in any occurrence.
> >
> >
> ______________________________________________________________________
> __
> > _____
> > ________________________________________________________________
> >
> >
> >
> ______________________________________________________________________
> _
> > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> ______________________________________________________________________
> _
> > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> ______________________________________________________________________
> _
> > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> ______________________________________________________________________
> _
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:01 GMT-3