The issue with this update message was caused by an incorrect configuration on
the junos host.
It is caused when the routing instance on the junos mx960 does not contain the
vrf-table-lable statement.
Output from tcpdump below for the broken update:
03:32:24.000211 IP (tos 0xc0, ttl 3, id 26575, offset 0, flags [none], proto
TCP (6), length 197)
x.x.x.x.56398 > y.y.y.y.179: Flags [P.], cksum 0x6182 (correct), seq
100:245, ack 324, win 16384, options [nop,nop,TS val 1199869749 ecr
1689478336], length 145: BGP, length: 145
Update Message (2), length: 46
Multi-Protocol Unreach NLRI (15), length: 19, Flags [OE]:
AFI: IPv4 (1), SAFI: labeled VPN Unicast (128)
RD: 11111:100151 (= 0.1.135.55), 100.100.100.0/30, label:0
(BOGUS: Bottom of Stack NOT set!)
0x0000: 0001 8076 0000 0000 002e 4500 0187 3764
0x0010: 6464 00
Update Message (2), length: 99
Origin (1), length: 1, Flags [T]: IGP
0x0000: 00
AS Path (2), length: 6, Flags [T]: 11111
0x0000: 0201 0000 2e45
Extended Community (16), length: 8, Flags [OT]:
target (0x0002), Flags [none]: 11111:100151 (= 0.1.135.55)
0x0000: 0002 2e45 0001 8737
Multi-Protocol Reach NLRI (14), length: 48, Flags [OE]:
AFI: IPv4 (1), SAFI: labeled VPN Unicast (128)
nexthop: RD: 0:0 (= 0.0.0.0), x.x.x.x, nh-length: 12, no SNPA
RD: 11111:100151 (= 0.1.135.55), 10.11.12.0/30, label:479577
(bottom)
RD: 11111:100151 (= 0.1.135.55), 10.0.1.0/24, label:479561
(bottom)
0x0000: 0001 800c 0000 0000 0000 0000 29c1 20fe
0x0010: 0076 7515 9100 002e 4500 0187 370a 0b0c
0x0020: 0070 7514 9100 002e 4500 0187 370a 0001
04:55:36.000106 IP (tos 0xc0, ttl 1, id 44739, offset 0, flags [DF], proto TCP
(6), length 92)
y.y.y.y.179 > x.x.x.x.56398: Flags [P.], cksum 0x3ad7 (correct), seq
324:364, ack 245, win 2172, options [nop,nop,TS val 1689478336 ecr
1199869749], length 40: BGP, length: 40
Notification Message (3), length: 40, UPDATE Message Error (3),
subcode Optional Attribute Error (9)
Output from tcpdump where vrf-table-label has been added to the routing
instance:
21:38:35.000181 IP (tos 0xc0, ttl 3, id 64040, offset 0, flags [none], proto
TCP (6), length 167)
x.x.x.x.59139 > y.y.y.y.179: Flags [P.], cksum 0xeb5e (correct), seq
100:215, ack 407, win 16384, options [nop,nop,TS val 1206417747 ecr
3324137366], length 115: BGP, length: 115
Update Message (2), length: 115
Origin (1), length: 1, Flags [T]: IGP
0x0000: 00
AS Path (2), length: 6, Flags [T]: 11111
0x0000: 0201 0000 2e45
Extended Community (16), length: 8, Flags [OT]:
target (0x0002), Flags [none]: 11111:100151 (= 0.1.135.55)
0x0000: 0002 2e45 0001 8737
Multi-Protocol Reach NLRI (14), length: 64, Flags [OE]:
AFI: IPv4 (1), SAFI: labeled VPN Unicast (128)
nexthop: RD: 0:0 (= 0.0.0.0), x.x.x.x, nh-length: 12, no SNPA
RD: 11111:100151 (= 0.1.135.55), 100.100.100.0/30, label:65572
(bottom)
RD: 11111:100151 (= 0.1.135.55), 10.11.12.0/30, label:65572
(bottom)
RD: 11111:100151 (= 0.1.135.55), 10.0.1.0/24, label:65572
(bottom)
0x0000: 0001 800c 0000 0000 0000 0000 29c1 20fe
0x0010: 0076 1002 4100 002e 4500 0187 3764 6464
0x0020: 0076 1002 4100 002e 4500 0187 370a 0b0c
0x0030: 0070 1002 4100 002e 4500 0187 370a 0001
So basically the problem here is incorrect configuration but my question is if
this is the correct behavior in dropping the bgp peering session? Should it
not rather just discard this update with an error and keep on processing?
I have been reading up a bit on rfc3032: MPLS Label Stack Encoding and they do
refer to just discarding the update.
On 06 Jun 2012, at 5:03 PM, Henning Brauer wrote:
> * Hendrik Meyburgh <hendri...@gmail.com> [2012-06-06 14:17]:
>> Hi Misc,
>>
>> I am having issues troubleshooting an issue where the error is:
>>
>> Jun 6 13:47:53 openbsd5132 bgpd[15919]: neighbor x.x.x.x (AS 65002 peer
1):
>> parse_capabilities: AFI 1, safi 4 unknown
>
> hmm, afi 1 is IPv4, safi 4 is MPLS (not MPLSVPN!), and we don't handle
> that indeed. but that's not fatal.
>
>> Jun 6 13:47:54 openbsd5132 bgpd[15940]: neighbor x.x.x.x (AS 65002 peer
1):
>> bad VPNv4 withdraw prefix
>
> and that is fatal as in the session is dropped by sending a
> notification, as the next line also sez. that in turn means either
> prefixlen is > 32 or rde_update_get_vpn4 failed. Which in turn means
> either one of the validity checks or rde_update_extract_prefix failed,
> and rde_update_extract_prefix again only fails on a validty check.
>
> guess we need to see that update.
>
>> Jun 6 13:47:54 openbsd5132 bgpd[15919]: neighbor x.x.x.x (AS 65002 peer
1):
>> sending notification: error in UPDATE message, optional attribute error
>>
>> And I have tried with the gdb debugging options explained in a previous
thread
>> but it looks like I am only able to get it to work when bgpd core dumps.
When
>> this error gets logged, bgpd does not core dump, so I need to be able to
debug
>> the running process, and I am failing horribly with that.
>>
>> To give some background, this is happening when I am exporting multiple
>> communities from a Junos host to the bgpd host, not when a single community
is
>> used. On a single rdomain it is working perfectly.
>>
>> Is it possible for you to make the info that was written down about
debugging
>> options for bgpd in the non-public list available here, as per the mail
>> below?
>
> see guenther's mail, but that doesn't help in your case, since you
> don't end up with the box crashing.
>
> --
> Henning Brauer, h...@bsws.de, henn...@openbsd.org
> BS Web Services, http://bsws.de, Full-Service ISP
> Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully
Managed
> Henning Brauer Consulting, http://henningbrauer.com/
