I've been having an email discussion with a couple of Cisco engineers about how useful BGP community based IP filtering might be. The following IOS config fragment might help explain what I'm getting at: int fddi0 ip access-group community-list 10 in ! ip community-list 10 permit AA:BB ip community-list 10 permit CC:DD ! If you are using communities to make your prefix announcements to peers, this then allows the router to filter incoming IP packets that match your announcements. Excepting things like CPU load, implementation details, etc do you think this would be helpful, or am I way off with this? Regards Matt. --- Matt Ryan - Network Engineer matt@planet.net.uk Planet OnLine Ltd, The White House, Tel: +44 113 2345566 Melbourne Street, Leeds, LS2 7PS, UK Fax: +44 113 2240003
I've been having an email discussion with a couple of Cisco engineers about how useful BGP community based IP filtering might be. The following IOS config fragment might help explain what I'm getting at:
int fddi0 ip access-group community-list 10 in ! ip community-list 10 permit AA:BB ip community-list 10 permit CC:DD !
If you are using communities to make your prefix announcements to peers, this then allows the router to filter incoming IP packets that match your announcements. Excepting things like CPU load, implementation details, etc do you think this would be helpful, or am I way off with this?
IMO, this still has the problem of there being a local agreement between the peers that require them to have a clue or everyone has bogus announces. There is hopefully going to be a presentation at NANOG by Tony and Yakov about cryptographic signing of prefix origination. This is a load more work in several ways, but it does strike at the heart of the problem. jerry
Regards
Matt.
--- Matt Ryan - Network Engineer matt@planet.net.uk Planet OnLine Ltd, The White House, Tel: +44 113 2345566 Melbourne Street, Leeds, LS2 7PS, UK Fax: +44 113 2240003
I've been having an email discussion with a couple of Cisco engineers about how useful BGP community based IP filtering might be. The following IOS config fragment might help explain what I'm getting at:
int fddi0 ip access-group community-list 10 in ! ip community-list 10 permit AA:BB ip community-list 10 permit CC:DD !
If you are using communities to make your prefix announcements to peers, this then allows the router to filter incoming IP packets that match your announcements. Excepting things like CPU load, implementation details, etc do you think this would be helpful, or am I way off with this?
I think this would be helpful; especially if were scaled as a ubiquitous implementation mechanism. Further implementations of BGP community based decision criteria could include Class of Service/Type of Service Priority Setting; based upon a particular community, give packets with this network source/destination X priority. Additionally, other services such as selective NAT (do or do not NAT based upon communities, NAT into which address space based upon communities), etc... can be implemented. Similar to the regexp niftiness being put into access lists, it'd be keen to see all features using ACLs accept communities as determining factors. Bear in mind this is not terribly useful to the world if Cisco does it alone, it should be tracked through IETF, but it would be nice if Cisco did the proof-of-concept and led the pack. -alan
On Thu, Jan 15, 1998 at 11:26:40AM -0500, Alan Hannan wrote:
Bear in mind this is not terribly useful to the world if Cisco does it alone, it should be tracked through IETF, but it would be nice if Cisco did the proof-of-concept and led the pack.
But isn't what you described implementation details? I'm not sure if I see a standard to track in this... Perhaps a better venue to track something like this is an IEPG/RIPE/IOPS/etc. -dorian
You're absolutely correct. The current protocol requires no modification, it's just relevant to the way the router handles other services. The thrust of my goal, mangled as it was, was that this become fairly common and expected. If so, then one could communicate and act upon routes based upon their associated BGP communities. This, imho, would be a very good thing. -alan
Bear in mind this is not terribly useful to the world if Cisco does it alone, it should be tracked through IETF, but it would be nice if Cisco did the proof-of-concept and led the pack.
But isn't what you described implementation details? I'm not sure if I see a standard to track in this... Perhaps a better venue to track something like this is an IEPG/RIPE/IOPS/etc.
On Thu, Jan 15, 1998 at 07:54:30PM -0500, Alan Hannan wrote:
The thrust of my goal, mangled as it was, was that this become fairly common and expected. If so, then one could communicate and act upon routes based upon their associated BGP communities.
This, imho, would be a very good thing.
Agreed. An operator community concensus to this affect to the vendors would be a good thing. I did not mean to dispute this point, and meant only to point out that some venues are better than others for efforts such as this. -dorian
On Thu, 15 Jan 1998, Dorian R. Kim wrote:
But isn't what you described implementation details? I'm not sure if I see a standard to track in this... Perhaps a better venue to track something like this is an IEPG/RIPE/IOPS/etc.
Since you suggest IOPS as a body to track this issue, what do people think about IOPS as a pseudo-standards group. This also came up at the December IETF when Curtis suggested that draft-berkowitz-multirqmt document would not be necessary since IOPS had a draft on the same subject. The IDR WG seemed very sceptical of having a small closed body fill that role. How do people see IOPS meshing with NANOG and the operational side of IETF? thanks, -chris
On Fri, Jan 16, 1998 at 06:07:27AM -0500, Chris Layton wrote:
On Thu, 15 Jan 1998, Dorian R. Kim wrote:
But isn't what you described implementation details? I'm not sure if I see a standard to track in this... Perhaps a better venue to track something like this is an IEPG/RIPE/IOPS/etc.
Since you suggest IOPS as a body to track this issue, what do people think
Well, sort of.. I just threw the name out there as a possibility, since it exists. This was not in any way an endorsement of IOPS as anything more than just that. -dorian
At 8:08 -0500 1/16/98, Dorian R. Kim wrote:
On Fri, Jan 16, 1998 at 06:07:27AM -0500, Chris Layton wrote:
On Thu, 15 Jan 1998, Dorian R. Kim wrote:
But isn't what you described implementation details? I'm not sure if I see a standard to track in this... Perhaps a better venue to track something like this is an IEPG/RIPE/IOPS/etc.
Since you suggest IOPS as a body to track this issue, what do people think
Well, sort of.. I just threw the name out there as a possibility, since it exists. This was not in any way an endorsement of IOPS as anything more than just that.
-dorian
Haven't had a chance to follow up, but my head is now above water. I had never heard of IOPS before.
From past experience with consortia, both inside and outside, I am a bit uncomfortable with them in a standards-setting role compared with the openness of IETF, IEPG, or NANOG. This is very pertinent to me at the moment as I hunt for a new job, as it would be quite impractical for me individually to participate in a group with significant up-front membership fees. ARIN is a current example of that.
Way back when OSI Was The Answer, I used to work for the Corporation for Open Systems -- in fact was the first technical person on staff. It had a model where members had the only input, which may well have led to the success of OSI. I've watched various consortia first restrict access to documents, and see an increasing trend in openness in such things as the ATM Forum. Somehow, the networking community has managed to escape the tyranny of Formal Standards Organizations. I well remember putting several performance standards through ANSI, getting to the Public Comment phase, and having to stop progressing the document until we responded formally to the "Digital Communications Performance Parameters are all very nice, but this document is flawed because it says nothing about saving the whales." I am _quite_ serious. So there is a delicate path to walk between the closed organization and the standards bureaucracy. It's my observation that we really lack a mechanism for propagating "operational" or "deployment" experience. IETF/IDR at least was willing to look at my multihoming draft. I have another document, tutorial/experienced based in a similar way, that deals with OSPF deployment methods. But since it's focused on enterprise networks, it really doesn't seem to fit the inter-carrier operations audiences. Howard
I've been having an email discussion with a couple of Cisco engineers about how useful BGP community based IP filtering might be. The following IOS config fragment might help explain what I'm getting at: int fddi0 ip access-group community-list 10 in ! ip community-list 10 permit AA:BB ip community-list 10 permit CC:DD ! If you are using communities to make your prefix announcements to peers, this then allows the router to filter incoming IP packets that match your announcements. Excepting things like CPU load, implementation details, etc do you think this would be helpful, or am I way off with this? I'm not sure about this but communities would be a lot more useful if there was more facilities to mask them out, delete individual communities etc. I would really like to be able to say "remove any of my private (ie local) communities" that I might receive from a customer while accepting the ones I have told them they can use. Similarly I would like to be able to say "remove this specific community" on announcements down this specific link(s). Mark.
I've been trying to get a response out of whois from whois.ra.net for the better part of an hour. Tia, JimL
Try it now. -abha ;) On Fri, 16 Jan 1998, Network Operations Center wrote:
I've been trying to get a response out of whois from whois.ra.net for the better part of an hour.
Tia, JimL
__________________________________________________________________________ -------------------------------------------------------------------------- abha ahuja ahuja@merit.edu Merit Network, Inc. 313.764.0294
I've been trying to get a response out of whois from whois.ra.net for the better part of an hour.
Despite evidence to the contrary (like the presence of the string "merit.edu" in the string "nanog@merit.edu"), "nanog@merit.edu" is not the same as "db-admin@ra.net". Nor is it the same as "noc@ra.net". Perhaps this isn't completely obvious. Anyhow, now you know. An obvious conclusion you might draw from this data is that reporting problems with the RA.NET whois server should really be done through a different mechanism. I suppose there are a number of other conclusions you might draw from this data, such as the fact that perhaps your mail message wasn't really appropriate for the North American Network Operators' Group mailing list. I only include nanog@merit.edu in the envelope of this message since a number of other members of the mailing list may be operating under similiar, somewhat understandable, misconceptions. I omit it from the headers to contrain replies. --jhawk
participants (10)
-
Abha Ahuja -
Alan Hannan -
Chris Layton -
Dorian R. Kim -
Howard C. Berkowitz -
Jerry Scharf -
John Hawkinson -
Mark Prior -
Matt Ryan -
Network Operations Center