Routing

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  bgp community and 32-bit as

    Posted 04-04-2012 05:14

    Hi

    How is it possible to use 32-bit as number in regular BGP community, using format
    ASN:NUMBER. Or is it possible at all?

    With extended communities (e.g. target) it is possible by postfixing the as-number with L.

    [edit]
    admin@lab# show policy-options community customer-test
    members 4000003L:5555;

    [edit]
    admin@lab# show policy-options policy-statement FROMCE1
    term 1 {
        then {
            community add customer-test;
            accept;
        }
    }

    admin@lab# commit check
    [edit]
      'policy-options'
        Policy error: customer-test community contains no non-wildcard members in set or add action (in term 1)
    error: configuration check-out failed


    Without L:

    admin@lab# show policy-options community customer-test                        
    members 4000003:5555;

    admin@lab# commit check
    [edit policy-options community customer-test members]
      '4000003:5555'
        invalid autonomous system value at '4000003' not in range 0 to 65535
    error: configuration check-out failed


    Junos 10.4R7.5. Tested with few other versions, too.


    Thanks.



  • 2.  RE: bgp community and 32-bit as

    Posted 04-04-2012 12:43

    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".



  • 3.  RE: bgp community and 32-bit as

    Posted 01-12-2015 14:19

    Hi,

     

    I'm having the same 'problem' as the OP.

     

    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)

     

    Thanks,

    Niall


    #rfc1997
    #extendedcommunities
    #JUNOS
    #rfc7153
    #BGP
    #rfc4360


  • 4.  RE: bgp community and 32-bit as

     
    Posted 08-06-2019 03:57

    I was seeing the same error:

     

    'policy-options' Policy error: customer-test community contains no non-wildcard members in set or add action (in term 1) error: configuration check-out failed 

     

    Then i tried using it as below:

     

    set  policy-options community customer-test members target:4000003L:5555;

     

     

    instead of:

     

    set policy-options community customer-test members 4000003L:5555;

    and it works fine, maybe you can test this way.

     

    Thanks!



  • 5.  RE: bgp community and 32-bit as

     
    Posted 08-06-2019 08:56

    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. 

     

    as-path-> 4000003 

    community-> 5555:0

     

    2. Use the route to carry 2 communities and match both 

    4000003 equals to 61.2307 if i calculated correctly

     

    community1-> 61:2307

    community2-> 5555:0

     

     

     



  • 6.  RE: bgp community and 32-bit as

    Posted 08-12-2019 02:04

    Ok, so in order to solve your problems you have to understand communities:

     

    1. 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
    2. 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.
    3. 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:

     

    set community large-as members large:65800:1:1

     

    Cheers,

    Carsten