RE: Prefix list question abouts odds and even routes

From: Steve Router (route2hell@hotmail.com)
Date: Thu Jun 19 2003 - 23:31:49 GMT-3


Thanks for your help, this is a good practice in learning prefix lists.
There are some real interesting things prefix lists can be used for I wish
cisco would enhance them to include more options the turbo /complied lists
access lists are interesting i havent had a chance to use them yet

Stephen R

>From: "Scott Morris" <swm@emanon.com>
>Reply-To: <swm@emanon.com>
>To: "'steve r'" <route2hell@hotmail.com>,"'Brian Dennis'"
><brian@labforge.com>,"'Nguyen Hoang Long'"
><ng-hlong@hn.vnn.vn>,<ZaferP@koc.net>,<ccielab@groupstudy.com>
>CC: <GokhanS@koc.net>
>Subject: RE: Prefix list question abouts odds and even routes
>Date: Thu, 19 Jun 2003 20:48:17 -0400
>
>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:02 GMT-3