<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Roman,<div class=""><br class=""></div><div class="">Brandon Leeberg in this ML also recently posted about the same issue (with the same prefix by the way), running SEOS-12.1.1.9 and 12.1.1.12p13. Nothing seems bad with this route.<br class=""><div><br class=""></div><div>In fact, I found back a pcap capture (from december 2017) of a BGP session from one of my Juniper MX gears toward a BGP/Netflow collector, where I can see this route.</div><div>And I can see after all that there's a difference between your version and what was transmitted by this MX</div><div>For the AGGREGATOR attribute, the "partial" bit is at 0 in my capture (meaning tat the attribute is "complete", that is everything is OK), whereas in your case it is set at 1 (so the attribute begins with c0 instead of e0).</div><div><br class=""></div><div>In Brandon's case the "partial" bit was also at 1.</div><div>So I suppose that this is what the SE code doesn't like.</div><div><br class=""></div><div>There's no serious reason for this flag to be set to 1 for this prefix (or it means that a BGP router transmitted this announcement without understanding what AGGREGATOR attribute was, which is ridiculous). That's probably a problem on the originator's side.</div><div>But there's no reason for SEOS to consider this attribute as bad (and no reason to close the session since RFC7606, but SEOS is now a dead end).</div><div><br class=""></div><div>However I guess that on Brandon case, the sessions was staying alive (juste error messages in the logs)...</div><div><div><br class=""></div><div>Seems like a bug to me, I guess that only an Ericsson TAC engineer could help fix this SEOS BGP piece of code.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Olivier</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class="">On 30 apr. 2018 at 23:54, Соловьёв Роман Анатольевич <<a href="mailto:romanse@serdi.ru" class="">romanse@serdi.ru</a>> wrote :</div><br class="Apple-interchange-newline"><div class=""><br class=""><blockquote class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Hi. Some issue is detected with SeOS version SEOS-12.1.1.12p13-Release<br class=""></div><div class="">The issue is about BGP protocol handling. <br class=""></div><div class="">The problem is, that SeOS close a BGP session on receiving mailformed UPDATE message from a peer. The peer is Juniper. <br class=""></div><div class=""><br class="">On the peer side:<br class=""><p class=""><font size="4" class=""><span style="font-family:Calibri,sans-serif;color:rgb(31,73,125);" lang="EN-US" class="">bgp_read_v4_message:11175:
NOTIFICATION received from 5.143.236.222 (External AS 48711): code 3
(Update Message Error) subcode 4 (attribute flags error), Data: e0
<span class=""><span class="">07 08 00 03 02</span></span> Apr 30 09:52:06 2018</span></font></p></div><div class=""><br class=""><b class="">On SeOS side:</b><br class=""><br class="">bgp neighbor 5.143.236.221<br class="">BGP neighbor: 5.143.236.221, remote AS: 12389, external link<br class=""> Version: 4, router identifier: 178.34.128.3<br class=""> State: Idle for 00:00:25<br class=""> Last read 00:00:25, last send 00:00:25<br class=""> Hold time: configured 180, negotiated 0<br class=""> Keepalive time: configured 30, negotiated 0<br class=""> Local restart timer 120 sec, stale route retain timer 180 sec<br class=""> Received restart timer 0 sec, flag 0x0<br class=""> Number of hops external BGP neighbor may be away: 1<br class=""> Minimum time between advertisement runs: 30 secs<br class=""> Source (local) IP address: 0.0.0.0<br class=""> Received messages: 0 (0 bytes), notifications: 0, in queue: 0<br class=""> Sent messages: 0 (0 bytes), notifications: 289, out queue: 0<br class=""> Last active open: 06:10:23, reason: Have not registered with RIB<br class=""> Reset count: 289, last reset time: 00:00:25, reset reason: N<b class="">otification sent (update: attribute flags error)</b><br class=""><br class="">show bgp neighbor 5.143.236.221 malform update <br class="">Apr 30 10:42:23
Malformed UPDATE msg (nbr 5.143.236.221, context 0x<span class=""><span class="">40080002</span></span>, 80 bytes,
repeated 1512 times, reason: Invalid msg) - <br class="">ffff ffff ffff ffff ffff
ffff ffff ffff <span class=""><span class="">0050 0200 0000 3540 0101 0040 020</span></span>e <span class=""><span class="">0203 0000 3065 0000</span></span>
0c<span class=""><span class="">97 0003 02</span></span>ed <span class=""><span class="">4003 0405 8</span></span>fec dd40 0600 e<span class=""><span class="">007 0800 0302</span></span> ed5b dc3f 01c0
<span class=""><span class="">0808 3065 0006 3065 0007 185</span></span>b dc3f<br class=""></div><br class=""></div>Lets parse this data.<br class="">ffff ffff ffff ffff ffff ffff ffff ffff - the init marker<br class=""></div>0050 - totak message length - 80 bytes<br class=""><div class=""><br class=""><b class="">02</b> - UPDATE <br class=""><div class=""><b class="">0000</b> Length of Withdrawn Routes <br class=""><b class="">0035</b> Total size of attributes (<b class="">53 bytes</b>)<br class=""></div><div class=""><br class=""></div><div class="">Attributes:<br class=""></div><div class=""><b class=""><span class=""><span class="">40 01 01 00</span></span></b><br class="">ORIGIN (IGP) <br class=""></div><div class=""><br class=""></div><div class=""><b class="">40 02 0e <span class=""><span class="">02 03 0000 3065 0000 0</span></span>c<span class=""><span class="">97 0003 02</span></span>ed</b><br class=""></div><div class="">40-flags<br class=""></div><div class="">02 - AS_PATH<br class=""></div><div class="">0e - length - 14 <b class="">bytes<br class=""></b></div><div class="">02 - segment type AS_SEQUENCE <br class="">03 - 3 AS length<br class=""><span class=""><span class="">0000 3065 0000 0</span></span>c<span class=""><span class="">97 0003 02</span></span>ed - ASN itself (12389,3223,197357)<br class=""></div><div class=""><br class=""><b class=""><span class=""><span class="">40 03 04 05 8</span></span>f ec dd<br class=""></b>NEXT_HOP<b class=""> </b>5.143.236.221<b class=""><br class=""></b></div><div class=""><b class=""><br class=""></b></div><div class=""><b class="">40 06 00 <br class=""></b>an empty ATOMIC_AGGREGATE attribute<br class=""></div><div class=""><br class=""><b class="">e<span class=""><span class="">0 07 08 0003 02</span></span>ed 5b dc 3f 01 </b><br class="">AGGREGATOR AS 197357 IP 93.220.63.1<br class=""></div><div class=""><br class=""></div><div class=""><b class="">c<span class=""><span class="">0 08 08 3065 0006 3065 0007</span></span> <br class=""></b></div><div class="">COMMUNITY 12389:6 12389:7<b class=""><br class=""></b></div><div class=""></div><div class=""><br class=""><b class="">18 5b dc 3f <br class=""></b></div>Prefixes<b class=""> </b><a href="http://91.220.63.0/24" target="_blank" class="">91.220.63.0/24</a><b class=""><br class=""></b><br class=""></div><div class="">According the notification message SeOS threats the AGGREGATOR attribute flags as mailfomed:<br class=""><b class="">e<span class=""><span class="">0 07 08 0003 02</span></span>ed 5b dc 3f 01 </b></div><div class="">I don't see anything wrong with it. <br class="">IMHO the AGGRETATOR attribute is composed with all RFC requirements<br class=""></div><div class=""><br class="">Can somebody explain me such unexpected behavior?<br class=""></div><div class=""><br class=""></div></div></blockquote></div></blockquote></div><br class=""></div></body></html>