On 2013-08-02, OCEANET - Cédric BASSAGET <ced...@oceanet.com> wrote: > Always working on my problem, if anybody can help me.... please. > > Here's a tcpdump of BGP exchanges between the neighbor (192.168.53.118) > and me (192.168.53.113) : > > _Open from my neighbor, no 4 Byte AS capability :_ > 17:26:04.529327 IP (tos 0xc0, ttl 1, id 16154, offset 0, flags [DF], > proto TCP (6), length 79) > 192.168.53.113.44169 > 192.168.53.118.bgp: Flags [P.], cksum 0x6e87 > (correct), seq 687533061:687533100, ack 2368601536, win 16384, length > 39: BGP, length: 39 > Open Message (1), length: 39 > Version 4, my AS 65426, Holdtime 20s, ID 46.226.128.1 > Optional parameters, length: 10 > Option Capabilities Advertisement (2), length: 8 > Multiprotocol Extensions (1), length: 4 > AFI IPv4 (1), SAFI Unicast (1) > 0x0000: 0001 0001 > > _Open from me, 4 Byte AS capability :_ > 17:26:04.530298 IP (tos 0xc0, ttl 1, id 61896, offset 0, flags [DF], > proto TCP (6), length 93) > 192.168.53.118.bgp > 192.168.53.113.44169: Flags [P.], cksum 0x7ecf > (correct), seq 1:54, ack 39, win 16345, length 53: BGP, length: 53 > Open Message (1), length: 53 > Version 4, my AS 35330, Holdtime 180s, ID 192.168.53.118 > Optional parameters, length: 24 > Option Capabilities Advertisement (2), length: 6 > Multiprotocol Extensions (1), length: 4 > AFI IPv4 (1), SAFI Unicast (1) > 0x0000: 0001 0001 > Option Capabilities Advertisement (2), length: 2 > Route Refresh (Cisco) (128), length: 0 > Option Capabilities Advertisement (2), length: 2 > Route Refresh (2), length: 0 > Option Capabilities Advertisement (2), length: 6 > * 32-Bit AS Number (65), length: 4** > ** 4 Byte AS 35330* > 0x0000: 0000 8a02 > > _Keepalives..._ > 17:26:04.530350 IP (tos 0xc0, ttl 1, id 61897, offset 0, flags [DF], > proto TCP (6), length 59) > 192.168.53.118.bgp > 192.168.53.113.44169: Flags [P.], cksum 0x320e > (correct), seq 54:73, ack 39, win 16345, length 19: BGP, length: 19 > Keepalive Message (4), length: 19 > > 17:26:04.530479 IP (tos 0xc0, ttl 1, id 28050, offset 0, flags [DF], > proto TCP (6), length 59) > 192.168.53.113.44169 > 192.168.53.118.bgp: Flags [P.], cksum 0x31e7 > (correct), seq 39:58, ack 73, win 16365, length 19: BGP, length: 19 > Keepalive Message (4), length: 19 > > _Update :_ > 17:26:04.530926 IP (tos 0xc0, ttl 1, id 37630, offset 0, flags [DF], > proto TCP (6), length 94) > 192.168.53.113.44169 > 192.168.53.118.bgp: Flags [P.], cksum 0x4a46 > (correct), seq 58:112, ack 73, win 16384, length 54: BGP, length: 54 > Update Message (2), length: 54 > Origin (1), length: 1, Flags [T]: IGP > 0x0000: 00 > * AS Path (2), length: 4, Flags [T]: 23456 * > 0x0000: 0201 5ba0 > Next Hop (3), length: 4, Flags [T]: 192.168.53.113 > 0x0000: c0a8 3571 > * AS4 Path (17), length: 6, Flags [OT]: <4 byte AS>* > 0x0000: 0201 0003 039c > Updated routes: > <net>/21 > > _Error notification :_ > 17:26:04.531860 IP (tos 0xc0, ttl 1, id 61899, offset 0, flags [DF], > proto TCP (6), length 68) > 192.168.53.118.bgp > 192.168.53.113.44169: Flags [P.], cksum 0xc800 > (correct), seq 73:101, ack 112, win 16272, length 28: BGP, length: 28 > * Notification Message (3), length: 28, UPDATE Message Error (3), > subcode Malformed AS_PATH (11)* > > Regards, > C�dric
I think this is a config error, bgpd behaviour seems correct according to RFC 4893. To represent 4-octet AS numbers (which are not mapped from 2-octets) as 2-octet AS numbers in the AS path information encoded with 2-octet AS numbers, this document reserves a 2-octet AS number. We denote this special AS number as AS_TRANS for ease of description in the rest of this specification. This AS number is also placed in the "My Autonomous System" field of the OPEN message originated by a NEW BGP speaker, if the speaker does not have a (globally unique) 2-octet AS number. so, the rfc says: 1. in the OPEN you use either AS_TRANS or a unique other 16-bit AS number but, 2. in AS_PATH when talking to an old bgp speaker, you use AS_TRANS (*not* some other ASN) to replace any 32-bit ASN. additionally, whenever peers that handle 32-bit ASN talk to each other, they *always* use just AS_PATH (writing 32-bit ASNs in full), but when they talk to an old 16-bit-only peer, they *regenerate* AS_PATH as 16 bits by writing AS_TRANS in place of any 32-bit ASNs in the path - so even if you were allowed to use a number other than AS_TRANS in the (16-bit) path, that would be overwritten anyway when the update is received by another 32-bit speaker and then passed on to another 16-bit speaker. I think your options are: - ask the 16-bit-only peer to update to current software (usually preferred) - ask the 16-bit-only peer to disable "enforce neighbor-as" or equivalent - use the default AS_TRANS rather than specifying another 16-bit ASN (I suppose this will only be possible if the 16-bit-only peer has no other peers with 32-bit ASNs)
