This is actually a very good question which required wireshark and some musing on my part to figure out.
Here’s the short answer:
If you included R1’s AS in the filter:
R1(config)#ip as-path access-list 1 permit ^4444$
It would indeed stop ISP1 and ISP2 from using R1 as a transit path. However, there is also a negative consequence. R1’s advertisements to ISP1 and ISP2 would also be filter out.
Here’s the long answer:
The interesting question is why does it do this? To answer this question, the first point to understand is what the ip as-path command is saying. It is using regex where the “^” means “beginning of string” and “$” means “end of string.” So, " ^4444$ " means “this string contains exactly 4444.” Since the as-path access list has an implicit deny at the end, everything except 4444 in the as-path is rejected.
To figure out why the R1 is filtering out its own route, you need to look at the BGP Topology table. Here’s what it looks like:
R1#show ip bgp topology *
For address family: IPv4 Unicast
BGP table version is 4, local router ID is 188.8.131.52
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 184.108.40.206/24 0.0.0.0 0 32768 i
Notice the Path field in the table–specifically what is NOT there. It lists only the origin code and no AS-Path. Self-originated routes are not stamped with the AS-Path in the host router’s BGP Topology table. The route is associated with the 4444 AS Path attribute once it leaves R1 (after the filter has already done its work).
Essentially, the reason putting 4444 in the as-path filter will not work comes down the order in which BGP operates: Filter based on Topology table first, then send BGP Update message with added AS-Path attribute to neighbors.