According to RFC1997 BGP community is a 32 bit length value. So, you cannot use 32 bit AS number in standart bgp communities. However, you can use 4-octet AS number in extended BGP communities with types "target" or "origin".
For example, I want to define communities in the form: <type>64512:444333L, with the first two 'type' bytes being 0x42 and 0x04, that is, a non-transitive extended community of 'generic' type (See here: RFC7153).
This is instead of using the syntactic sugar 'origin' or 'target'; I want to explicitly encode 0x42 and 0x04 as the two high-order bytes. Does anyone know how this is achieved in JunOS? (I'm using versions 13.2R4-S2, 13.3R1.6, 14.1R2.5)
To my limited knowledge, there's no easy way to do it. Also haven't seen similar implementation
You can do this:
1. Use as-path to match the as-path. I am not sure the motivation behind converting as-path to community. You can use as-path as matching condition in your import / export policy to manipulate the routes. Use another community conbined with as-path and match both.
2. Use the route to carry 2 communities and match both
4000003 equals to 61.2307 if i calculated correctly
Ok, so in order to solve your problems you have to understand communities:
Standard communities are 32bit values which should be encoded as <as-number>:<comm value> and both fields are 16bit, so NO way to encode a 4byte AS number due to limited size of attribute
Extended communities are 64bit values with uses a 8bit type + 8bit subtype field and 48bit of values. The type=0x02 defines 4-byte AS specific extended communities (supported subtypes are route target or route origin). Thus, 4byte ASN are supported in general but the use case is for BGP VPNs.
Large communities 96bit value according to RFC8092. They are encoded as <as-number>:<value1>:<value2> each of which are 32bit, so 4-byte AS supported.
Therefore, large communities is obviously the way to go and also supported in JUNOS: