I would suggest filtering at the customer interface and then tagging the route with a community that indicates "I have accepted this route as a customer route and will transport it to and through the edge of my network". Here is some example code. Let me know if you need more help with this. ON the ISPEdge router (facing the customer) router bgp nnnn neighbor x.x.x.x remote-as y neighbor x.x.x.x Description customerxyz neighbor x.x.x.x route-map customerxyz-in in neighbor n.n.n.n remote-as nnnn neighbor n.n.n.n Description IBGP connection to ISPCore neighbor n.n.n.n route-map ibgp-out out neighbor n.n.n.n send-community ip prefix-list customerxyz-in permit y.y.y.y/20 le 24 ip prefix-list customerxyz-in permit z.z.z.z/22 le 24 route-map customerxyz-in permit 10 match ip address prefix-list customerxyz-in set community nnnn:999 (Implicit deny any for Items not matching the route-map) ip community-list 1 permit nnnn:999 route-map ibgp-out permit 10 match community 1 route-map ibgp-out permit 20 Statements To match and transport your non-customer ibgp routes go here Ejay Hire Network Engineer -----Original Message----- From: Mark Radabaugh [mailto:mark@amplex.net] Sent: Thursday, May 15, 2003 9:29 PM To: nanog@merit.edu Subject: BGP Path Filtering I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's. I find lots of references (and understand) the basic ip as-path access-list 3 permit ^$ and it would seem that should we wish to provide transit for a bgp customer AS12345 we would use: ip as-path access-list 3 permit ^12345$ but I think this breaks if AS12345 prepends their advertisement. Next up is: ip as-path access-list 3 permit ^12345_[0-9]$* Which seems correct to me. Is this still best practice (or even correct)? Mark Radabaugh Amplex (419) 720-3635