Mailing List Archive

unless you are running into some silly IOS bug there is absolutely no
correlation between the ACL number and the actual filters that it applies.

its probably people copying sample configs...my favorite is 150 though :)

joshd.

----- Original Message -----
From: "Sean Donelan" <sean@donelan.com>
To: <cisco-nsp@puck.nether.net>
Sent: Wednesday, September 25, 2002 1:41 AM
Subject: [nsp] Favorite access lists


> Of course, an access-list is just an access-list. But there seem
> to be some "well-known" access-list conventions among ISPs. Say
> access-list 112, and folks know its probably a inbound BGP route prefix
> filter. Access-list 199 is probably a "deny any any". Instead of
> re-inventing things, any suggestions for other well known conventions
> for access lists?
>
>
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

I agree the number is technically meaningless, however the power of
convention is strong. Following commonly used conventions speeds up
training new engineers, and helps prevent "accidents" when dealing with
vendor support if you follow commonly used conventions. You can
re-configure almost every convention, like re-mapping the keyboard or
using a different identation style, but it slows people down.

Usually a provider will use the same access-list number across their
entire network to control access to the vty's, or the same access list
for DDOS tracking. I was wondering, with the movement of network
engineers from provider to provider, whether any of those conventions
had become common across larger parts of the ISP industry.

bgp filter 112
deny any access list 199
ddos tracking access list 169
vty access list 1
snmp RO access list 10
snmp RW access list 11


On Wed, 25 Sep 2002, Josh Duffek wrote:
> unless you are running into some silly IOS bug there is absolutely no
> correlation between the ACL number and the actual filters that it applies.
>
> its probably people copying sample configs...my favorite is 150 though :)
>
> > Of course, an access-list is just an access-list. But there seem
> > to be some "well-known" access-list conventions among ISPs. Say
> > access-list 112, and folks know its probably a inbound BGP route prefix
> > filter. Access-list 199 is probably a "deny any any". Instead of
> > re-inventing things, any suggestions for other well known conventions
> > for access lists?

Sean,

I think you make an excellent point. I'm not completely aware to the
extent that ACL, prefix-list and filter-list (named and numbered)
conventions exist today within the ISP community. However, making sure
they do exist and are published appropriately would add tremendous value
to simplifying the operations of our collective infrastructures, imho.

Sounds like a good (informational) RFC to me...

Thanks,

Chris

> -----Original Message-----
> From: Sean Donelan [mailto:sean@donelan.com]
> Sent: Thursday, September 26, 2002 12:56 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [nsp] Favorite access lists
>
>
>
> I agree the number is technically meaningless, however the power of
> convention is strong. Following commonly used conventions speeds up
> training new engineers, and helps prevent "accidents" when
> dealing with
> vendor support if you follow commonly used conventions. You can
> re-configure almost every convention, like re-mapping the keyboard or
> using a different identation style, but it slows people down.
>
> Usually a provider will use the same access-list number across their
> entire network to control access to the vty's, or the same access list
> for DDOS tracking. I was wondering, with the movement of network
> engineers from provider to provider, whether any of those conventions
> had become common across larger parts of the ISP industry.
>
> bgp filter 112
> deny any access list 199
> ddos tracking access list 169
> vty access list 1
> snmp RO access list 10
> snmp RW access list 11
>
>
> On Wed, 25 Sep 2002, Josh Duffek wrote:
> > unless you are running into some silly IOS bug there is
> absolutely no
> > correlation between the ACL number and the actual filters
> that it applies.
> >
> > its probably people copying sample configs...my favorite is
> 150 though :)
> >
> > > Of course, an access-list is just an access-list. But there seem
> > > to be some "well-known" access-list conventions among ISPs. Say
> > > access-list 112, and folks know its probably a inbound
> BGP route prefix
> > > filter. Access-list 199 is probably a "deny any any". Instead of
> > > re-inventing things, any suggestions for other well known
> conventions
> > > for access lists?
>
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

On Thu, Sep 26, 2002 at 01:48:59PM -0700, Chris Whyte wrote:
> I think you make an excellent point. I'm not completely aware to the
> extent that ACL, prefix-list and filter-list (named and numbered)
> conventions exist today within the ISP community. However, making sure
> they do exist and are published appropriately would add tremendous value
> to simplifying the operations of our collective infrastructures, imho.
>
> Sounds like a good (informational) RFC to me...

Also for as-path access-lists, e.g.:

ip as-path access-list 1 permit .* (Permit all)
ip as-path access-list 2 deny .* (Deny all)
ip as-path access-list 3 permit ^$ (Permit only our routes)

and configuring route-maps so there is a final, explicit
permit statement that allows or denies appropriately.

Note these were taken from Avi Freedman's "Intro to BGP Tutorial".

I would personally like to hear accounts of ACL change procedures
at both the orgnaizational level as well as the technical details.

Example:
Business rules require two levels of authorization, one from a
2nd-level manager or supervisor (much like the 4 installer skill
levels from Telcordia) and another from the change/problem
management group that represents the network operations group.

Technical process includes loading the ACL (whether by tftp, ftp,
scp, etc or by pasting in the new configuration via telnet, ssh),
which also requires removing not the previous ACL (preventing
failback), but the second most recent ACL loaded. The process
is then official by listing all appropriate external interface
sources (determined with e.g. "sh ip bgp s" and "sh ip int br"
and/or "sh run | i interface | access-g") and preparing two
templates - one with the new ACL name/number, the other with
the current ACL name/number - then loaded/pasted config-wise
to apply the new ACL to the appropriate interfaces. Obviously,
you will also want to do a "show access-l <name/number>" and
note that the ACL is counting properly and again, check that
the ACL was applied to the correct interfaces. You also
might want to test the functionality externally with tools
like nmap/hping/fragrouter/etc.

All said, ACL work can be extremely complex (firewalls are
just as bad, but I don't even want to go there) and there
should be industry standards on how they are done.

Cisco policy language can also be much different than other
compteting vendors, so standardizing is even more difficult.

What *we* operators need is a language like RPSL to describe
other types of policy ... ACL's, firewall filtering, MPLS,
things your would find in Cisco's MQoS, etc.

I had a similar idea like this after reading RFC 3346 where
the authors note "What this means is that much more is required
in the form of various types of tools to simplify and automate
the MPLS TE function". An OO language like RPSL extensions
for MPLS could really help in building the tools.

The RPS-WG is probably not the place for this, maybe we need
a "Network Policy System" working group in the IETF.

I would appreciate any feedback (you can send mail to me
personally) on any of the above ideas.

-dre

Hi Sean,
I agree that standardization is a good thing, but in all honesty, I'd
rather see ISP cooperation on:

- customer anti-spoofing
- bogon filters
- BGP peer filters
- etc...

I would think these numbering conventions also tend to break down when
working with other gear from other vendors. A lot can be said for using
named ACLs which can provide a quick description of their purpose.

-- steve

-----Original Message-----
From: cisco-nsp-admin@puck.nether.net
[mailto:cisco-nsp-admin@puck.nether.net] On Behalf Of Sean Donelan
Sent: Thursday, September 26, 2002 2:56 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [nsp] Favorite access lists


I agree the number is technically meaningless, however the power of
convention is strong. Following commonly used conventions speeds up
training new engineers, and helps prevent "accidents" when dealing with
vendor support if you follow commonly used conventions. You can
re-configure almost every convention, like re-mapping the keyboard or
using a different identation style, but it slows people down.

Usually a provider will use the same access-list number across their
entire network to control access to the vty's, or the same access list
for DDOS tracking. I was wondering, with the movement of network
engineers from provider to provider, whether any of those conventions
had become common across larger parts of the ISP industry.

bgp filter 112
deny any access list 199
ddos tracking access list 169
vty access list 1
snmp RO access list 10
snmp RW access list 11


On Wed, 25 Sep 2002, Josh Duffek wrote:
> unless you are running into some silly IOS bug there is absolutely no
> correlation between the ACL number and the actual filters that it
applies.
>
> its probably people copying sample configs...my favorite is 150 though
:)
>
> > Of course, an access-list is just an access-list. But there seem
> > to be some "well-known" access-list conventions among ISPs. Say
> > access-list 112, and folks know its probably a inbound BGP route
prefix
> > filter. Access-list 199 is probably a "deny any any". Instead of
> > re-inventing things, any suggestions for other well known
conventions
> > for access lists?

_______________________________________________
cisco-nsp mailing list real_name)s@puck.nether.net
http://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 26 Sep 2002, Stephen Gill wrote:

> Hi Sean,
> I agree that standardization is a good thing, but in all honesty, I'd
> rather see ISP cooperation on:
>
> - customer anti-spoofing
> - bogon filters
> - BGP peer filters
> - etc...
>
> I would think these numbering conventions also tend to break down
> when working with other gear from other vendors. A lot can be said
> for using named ACLs which can provide a quick description of their
> purpose.
>
> -- steve

Seriously. Moreover, assuming a convention where none exists or may
be applied inconsistently is much more devistating than the incredibly
marginal amount of time it might take to learn the practices of a new
employer.

No offense, but this notion is a waste of time.

Tony

>
> > Hi Sean,
> > I agree that standardization is a good thing, but in all
> honesty, I'd
> > rather see ISP cooperation on:
> >
> > - customer anti-spoofing
> > - bogon filters
> > - BGP peer filters
> > - etc...
> >
> > I would think these numbering conventions also tend to break down
> > when working with other gear from other vendors. A lot can be said
> > for using named ACLs which can provide a quick description of their
> > purpose.
> >
> > -- steve
>
> Seriously. Moreover, assuming a convention where none exists or may
> be applied inconsistently is much more devistating than the incredibly
> marginal amount of time it might take to learn the practices of a new
> employer.
>
> No offense, but this notion is a waste of time.

Possibly a disconnect but I wasn't thinking so much about a
numbering/naming convention as I was thinking about the contents of
these filters that follow under the above categories (ie customer
anti-spoofing, etc). Clearly, some progress has already been made in
these areas (eg. draft-manning-dsua-xx.txt -- status uknown to me).

So guys, I certainly understand and agree with your statements but
thought Sean's intention was an attempt to gain ISP cooperation. Maybe I
misunderstood...

Thanks,

Chris

>
> Tony
>
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

> bgp filter 112
> deny any access list 199
> ddos tracking access list 169
> vty access list 1
> snmp RO access list 10
> snmp RW access list 11



I gotta admit, you hit several of what we used at Digital Island. Convention is indeed strong...

scott





> > -----Original Message-----
> > From: Sean Donelan [mailto:sean@donelan.com]
>
> > Sent: Thursday, September 26, 2002 12:56 PM
> > To: cisco-nsp@puck.nether.net
> > Subject: Re: [nsp] Favorite access lists
> >
> >
> >
> > I agree the number is technically meaningless, however the power of
> > convention is strong. Following commonly used conventions speeds up
> > training new engineers, and helps prevent "accidents" when
> > dealing with
> > vendor support if you follow commonly used conventions. You can
> > re-configure almost every convention, like re-mapping the keyboard or
> > using a different identation style, but it slows people down.
> >
> > Usually a provider will use the same access-list number across their
> > entire network to control access to the vty's, or the same access list
> > for DDOS tracking. I was wondering, with the movement of network
> > engineers from provider to provider, whether any of those conventions
> > had become common across larger parts of the ISP industry.
> >
> > bgp filter 112
> > deny any access list 199
> > ddos tracking access list 169
> > vty access list 1
> > snmp RO access list 10
> > snmp RW access list 11
> >
> >
> > On Wed, 25 Sep 2002, Josh Duffek wrote:
> > > unless you are running into some silly IOS bug there is
> > absolutely no
> > > correlation between the ACL number and the actual filters
> > that it applies.
> > >
> > > its probably people copying sample configs...my favorite is
> > 150 though :)
> > >
> > > > Of course, an access-list is just an access-list. But there seem
> > > > to be some "well-known" access-list conventions among ISPs. Say
> > > > access-list 112, and folks know its probably a inbound
> > BGP route prefix
> > > > filter. Access-list 199 is probably a "deny any any". Instead of
> > > > re-inventing things, any suggestions for other well known
> > conventions
> > > > for access lists?
> >
> > _______________________________________________
> > cisco-nsp mailing list real_name)s@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

> > snmp RO access list 10
> > snmp RW access list 11

Out of curiosity, do you see many people allow snmp
RW? For what purpose?

Another thing also bothers me, who enables "snmp
manger"? why do we want to make a router a NMS?

Thanks
JJ



> I gotta admit, you hit several of what we used at
Digital Island. Convention is indeed strong...
>
> scott
>


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

On Fri, Sep 27, 2002 at 08:21:44PM -0700, JJ wrote:
> Another thing also bothers me, who enables "snmp
> manger"? why do we want to make a router a NMS?

internal vs. external polling. see cisco press
performance and fault management book. scalable
in some ways; not scalable in other ways.

dre

----- Original Message -----
From: "JJ" <yulingna@yahoo.com>
To: <cisco-nsp@puck.nether.net>
Sent: Friday, September 27, 2002 10:21 PM
Subject: Re: [nsp] Favorite access lists


> Out of curiosity, do you see many people allow snmp
> RW? For what purpose?
>

to config/set items in the MIB.. I know, that is a pretty general answer,
but I have used snmp write access to alot of different things, from
admin'ing a port to a down state, to telling the router to write it's
configuration to a tftp server.





> Another thing also bothers me, who enables "snmp
> manger"? why do we want to make a router a NMS?
>

The best usage example I have found for this feature would be if you did not
have an NMS at all,
and you wanted a single place to look at logs for all your devices.
Typically, you have to
have a seperate, dedicated system to be your NMS, not all networks require
24/7 operation, and this
works out great if you ONLY want to manage network devices.




heck, here is an even better example, answering both your questions.....


you have 5 routers, one is setup as an snmp manager, and all other routers
have RW community and acl's permitting that access from the manager using
the RW community... now... the benefit....

Lets say you lose router #3's password, but you still know the snmp RW
community, you enable the tftp service on your snmp manager router, send an
snmpset command from your snmp manager router, telling router #3 to write
it's config via tftp to the snmp manager router ( just to some file in
nvram, not to write to the config of the snmp manager router ) .... you now
have a copy of the active config and procede to crack the enable and secret
passwords... voiala... your in! ( just an example )

Just out of curiosity, can u crack the "enable secret" as well?

-----Original Message-----
From: Brian Roberson [mailto:roberson@olug.org]
Sent: Saturday, September 28, 2002 10:25 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [nsp] Favorite access lists


----- Original Message -----
From: "JJ" <yulingna@yahoo.com>
To: <cisco-nsp@puck.nether.net>
Sent: Friday, September 27, 2002 10:21 PM
Subject: Re: [nsp] Favorite access lists


> Out of curiosity, do you see many people allow snmp
> RW? For what purpose?
>

to config/set items in the MIB.. I know, that is a pretty general
answer,
but I have used snmp write access to alot of different things, from
admin'ing a port to a down state, to telling the router to write it's
configuration to a tftp server.





> Another thing also bothers me, who enables "snmp
> manger"? why do we want to make a router a NMS?
>

The best usage example I have found for this feature would be if you did
not
have an NMS at all,
and you wanted a single place to look at logs for all your devices.
Typically, you have to
have a seperate, dedicated system to be your NMS, not all networks
require
24/7 operation, and this
works out great if you ONLY want to manage network devices.




heck, here is an even better example, answering both your questions.....


you have 5 routers, one is setup as an snmp manager, and all other
routers
have RW community and acl's permitting that access from the manager
using
the RW community... now... the benefit....

Lets say you lose router #3's password, but you still know the snmp RW
community, you enable the tftp service on your snmp manager router, send
an
snmpset command from your snmp manager router, telling router #3 to
write
it's config via tftp to the snmp manager router ( just to some file in
nvram, not to write to the config of the snmp manager router ) .... you
now
have a copy of the active config and procede to crack the enable and
secret
passwords... voiala... your in! ( just an example )









_______________________________________________
cisco-nsp mailing list real_name)s@puck.nether.net
http://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

I've been outta the big networks loop for about 6 months now so the mem is fragmenting, but I believe you need or can do cool things from an HPOV machine with RW. So allow the HPOV machine RW and shut down RW access from all others and then guard the folks with access to that machine with an iron fist or a machine gun... ;-)

scott


JJ <yulingna@yahoo.com> wrote :

> > > snmp RO access list 10
> > > snmp RW access list 11
>
> Out of curiosity, do you see many people allow snmp
> RW? For what purpose?
>
> Another thing also bothers me, who enables "snmp
> manger"? why do we want to make a router a NMS?
>
> Thanks
> JJ
>
>
>
> > I gotta admit, you hit several of what we used at
> Digital Island. Convention is indeed strong...
> >
> > scott
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

Scott Weeks <surfer@mauigateway.com> writes:

> I've been outta the big networks loop for about 6 months now so the
> mem is fragmenting, but I believe you need or can do cool things
> from an HPOV machine with RW. So allow the HPOV machine RW and shut
> down RW access from all others and then guard the folks with access
> to that machine with an iron fist or a machine gun... ;-)

the knowledge of the ip address of the machine itself can be somewhat
more difficult to guard. :)

---rob