4

I am BGP peering with a Juniper OS router. When starting the connection, my system advertises 4-byte ASN capability, which is accepted by the Juniper router: Jul 28 00:33:00.664202 BGP RECV 4 Byte AS-Path capability (65), as_num 55002 Jul 28 00:33:00.664217 bgp_parse_4byte_aspath_cap():273 AS4-Peer (RECV): 4 byte AS capability received, AS 55002 Jul 28 00:33:00.664296 bgp_4byte_aspath_add_cap():199 AS4-Peer 10.17.206.131 (Internal AS 55002)(SEND): 4 byte AS capability added, AS 55002

The Juniper router sends back that 4-byte ASN capability: Jul 28 00:33:00.664405 BGP SEND 4 Byte AS-Path capability (65), as_num 55002

So I think it is safe to say that the two peers have established 4-byte ASN support.

Later on, we try to send a BGP UPDATE message, which includes the mp_reach_nlri attribute. If we send the BGP UPDATE message with a 2-octet AS/4-octet AN Extended Community attribute (ie, type 0x00, Transitive 2-Octet AS-Specific), Juniper router happily accepts. If we send the BGP UPDATE message with a 4-octet AS/2-octet AN Extended Community attribute (ie, type 0x00, Transitive 4-octet AS-Specific), Juniper router complains and rejects it due to "rejected due to the lack of a valid target community". bgp_rcv_nlri: 64999:0:193.193.193.193/96 rejected due to the lack of a valid target community

Take a look at the two pcap screenshots below. The ONLY difference in communication between the two peers is this single issue: 4-byte AS in the mp_reach_nlri packet, vs 2-byte AS in the mp_reach_nlri packet. The first image is working, the second is not.

Any clues why this is? How can we successfully send a mp_reach_nlri path attribute with a 4-byte AS as the target community?

working pcap

non-working pcap

Junos version information: Model: mx960 Junos: 15.1R7.8 JUNOS OS Kernel 64-bit [20180310.ba55661_builder_stable_10]

My router: proprietary; trying to craft our own packets for this BGP peering session

Junos show bgp neighbor: Peer: 10.17.206.131+37333 AS 55002 Local: 10.17.205.45+179 AS 55002 Type: Internal State: Established Flags: <Sync RSync> Peer supports 4 byte AS extension (peer-as 55002)

Improve this question
7
  • Please include software versions and configurations of both routers. A ‘show bgp neighbor’ on the juniper can be useful too.
    – Teun Vink
    Commented Jul 28, 2018 at 6:25
  • Added this information. I suppose what I also am looking for is a better understanding of the mp_reach_nlri path attribute. Does it require a valid target community as part of the Bgp UPDATE message? It seems that JunOS insists so. Where is this documented in an RFC? And if so, why does JunOS like the 2-byte AS target community but not the same encoding as a 4-byte AS target community?
    – Linux Ntwrk
    Commented Jul 30, 2018 at 14:54
  • "My router: proprietary; trying to craft our own packets for this BGP peering session" Unfortunately, your router is off-topic here. The manufacturer must offer optional, paid support for a device to be on-topic.
    – Ron Maupin ♦
    Commented Jul 30, 2018 at 14:58
  • @Ron Thanks for the comment. But I am not asking for help with a router/brand/configuration. I am moreso asking for help with understanding protocol. Why might JunOS think that a BGP UPDATE message mp_reach_nlri with 4-byte ASN target community is invalid?
    – Linux Ntwrk
    Commented Jul 31, 2018 at 1:31
  • How do we know that the proprietary router is actually performing correctly? It may be the Juniper that is acting correctly, and the other router that is misbehaving. We would really need to see the configurations. There are other configurations that can affect thing, but you have not included those. I just don't see anyone helping much with this.
    – Ron Maupin ♦
    Commented Jul 31, 2018 at 1:33

1 Answer 1

Reset to default
2

Your issue has nothing to do with how Juniper supports 4-byte ASNs or extended communities. The rejected due to the lack of a valid target community log messages is simply telling you that you don't have a routing instance configured with the target you specified.

You said that the only thing that changed between your two packet captures was the setting of the route-targets to use 4-byte ASNs. Which means, that you didn't change the routing-instance targets to match.

I did some basic lab testing to verify (using your examples).

2-Byte ASN Example

As you can see, this works as you'd expect.

R1:

set routing-instances VRF-A vrf-target target:55002:666

R2:

set routing-instances VRF-B vrf-target target:55002:666

R1:

Dec 30 04:31:30.051381 bgp_rcv_nlri: 55002:1111:202.202.202.0/88

root# run show route table VRF-A.inet.0 202.202.202.0/24

VRF-A.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

202.202.202.0/24   *[BGP/170] 00:01:06, localpref 100, from 2.2.2.2
                      AS path: 2222 I, validation-state: unverified
                    > to 5.5.5.1 via ge-0/0/0.0, Push 16

4-Byte ASN Example

Now, I make R2 send route targets with the 4-Byte ASN.

R1:

set routing-instances VRF-A vrf-target target:55002:666

R2:

set routing-instances VRF-B vrf-target target:55002L:666

R1:

We see the same error message you see because there is no routing instance configured on the device that uses the new route-target. 

Dec 30 04:35:35.879678 bgp_rcv_nlri: 55002:1111:202.202.202.0/88 rejected due to the lack of a valid target community

Also, no route in the VRF's routing table.

[edit]
root# run show route table VRF-A.inet.0 202.202.202.0/24

[edit]
root#

Now, for good measure let's change R1 to also use the 4-Byte ASN target.

R1:

set routing-instances VRF-A vrf-target target:55002L:666

Dec 30 04:41:08.515333 bgp_rcv_nlri: 55002:1111:202.202.202.0/88

root# run show route table VRF-A.inet.0 202.202.202.0/24

VRF-A.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

202.202.202.0/24   *[BGP/170] 00:00:56, localpref 100, from 2.2.2.2
                      AS path: 2222 I, validation-state: unverified
                    > to 5.5.5.1 via ge-0/0/0.0, Push 16
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.