Hi Stuart,
Thanks for the reply, our partner updated his software a few days ago, so it works now with a 32b ASN.

Regards,
Cédric

Le 11/08/2013 00:23, Stuart Henderson a écrit :
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)



--
OCEANET
---------------------------------------------------------------
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00

http://www.oceanet.com
http://www.oceanet-telecom.com

Reply via email to