On Thu, Dec 14, 2000 at 04:39:41PM +0800, Miguel A.L. Paraz wrote:
> > when you say "longer than /24" is that /23, /22... or /25, /26... /32 ?
>
> Sorry, I meant "more specific."
>
> > access-list 102 deny ip any 255.255.255.128 0.0.0.127 log
>
> So this means, match any network, but the netmask may not have any bits towards
> the right, correct?
Means drop /25, /26, /27, /28, /29, /30, /31, /32... and
"access-list 102 permit ip any any" will match everything else.
> Customer A has 203.176.8.0/24 and ASN 9442. They are dual-homed to us and
> provider B. We have private peering with B.
>
> I hear this route both from the customer peer and private peering with B,
> such that if the customer link to us goes down we can still reach them.
>
> We have an upstream C who permits 203.176.8.0/24. However, we would only
> like to announce A's route if it was heard from the customer directly.
>
> If it was heard through peering with B, I don't want to send it out to C
> since if I do, I will be doing transit for A via B.
look into ip as-patch ACLs or you can attempt to set up communities (?)
to your transit (not peer or as9442),
neighbor YOUR-transit filter-list 119 out
where acl-119:
ip as-path access-list 119 deny ^PEER's-ASN 9442$
ip as-path access-list 119 permit .*
first line is to deny 9442$ routes if they are with PEER-ASN in path,
second will permit the rest (you should filter it with
ip prefix-lists and/or filter-lists).
someone please correct me if i'm wrong!! ;)
> I think there is no filter that matches (203.176.8.0/24 and _9442$), right?
> So I should instead mark incoming routes with communities and match them?
>
> BTW. What is the best current practice for communities?
;) I could not find a (white) paper on that... but
http://info.us.bb.verio.net/routing.html#communities
http://www.jippii.net/communities.html
should give you some idea...
-Basil Kruglov
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:23 EDT