AS4 debugging

There are many debug outputs if you use the new debug commands for AS4

debug bgp as4
debug bgp as4 segment
and this section lists and explains them. Be aware that the log messages in the table below have been folded into several lines, you'll find them in one line each in your bgpd.log.

The numbers are only for easier reference. Black numbers/messages are normal functioning. Red numbers/messages indicate a message which is caused by an abnormal situation which will be handled. Blue numbers/messages are something which may well happen but is suspect if we look what it means in real life (tm).

The errors listed at the end cause a session to be dropped; they are all due to a neighbor which sends some bogus data. The errors will be logged even if no debugging is active.

'debug bgp as4' messages

# Message Explanation
1
[AS4] <neighbor ip>
   fiddling with aspath and newaspath,
   hopnumdifference is <num>
quagga did get an AS4 aspath and an aspath from this AS2 neighbour, and realizes that the AS4 path is shorter by <num> hops. The difference in hops is a deciding item in synthesizing as paths (please refer to the draft if you want to know more).
2
[AS4] <neighbor ip>
   got AS_PATH <as_path>
   and AS4_PATH <as4_path>
   synthesizing now
After telling us the difference in hops, we now see the paths quagga got, and quagga will now synthesize the internally used as_path.
3
[AS4] <neighbor ip>
   result of synthesizing is <as_path>
This is the result of the synthesizing of an as_path.
4
[AS4] <neighbor ip>
   rcv OPEN w/ OPTION parameter len: 24, peeking for as4
Quagga received an open message, and there are capability options present. As first activity, it will now look whether this neighbor advertises the AS4 capability (which would then have its true as number as value).
5
[AS4] <neighbor ip>
   OPEN peeking found AS4 capability
Quagga found the AS4 capability in the options of an open message.
6
[AS4] <neighbor ip>
   about to set cap PEER_CAP_AS4_RCV
   at address <hexaddress>,
   value now <decimal value of capability bitfield>,
   as4cap is <value of as4 capability, i.e as number>
The fact that this is an AS4 capable peer will be put into a bitfield, and the value of the as4 capability is presented (this is the as number of the peer).
7
[AS4] <neighbor ip>
   set cap PEER_CAP_AS4_RCV at
   address <hexaddress>,
   value now <decimal value of capability bitfield>
This logs the value of the bitfield after putting the AS4 capability into it. Should be 256 greater than without it.
8
[AS4] AS4PATHmangle:
   AS_CONFED_SEQUENCE would have been cut in two,
   taking AS_PATH instead of mangling
If quagga had tried to employ the synthesizing of as_path and as4_path, that would have cut off a sequence of confederation as numbers somewhere in the middle. Thus it concludes that as_path and as4_path are out of kilter: they can not be merged. Thus quagga will ignore as4_path and stick to the as_path.
9
[AS4] <neighbor ip>
   BGP AS4 capable peer send AS4_PATH
Quagga has received an AS4 path from an AS4 peer. This is not supposed to happen (between AS4 capable peers, the as_path attributes are exchanged with 4 byte asnumbers in them, so as4_path will never be exchanged). The peer has a faulty AS4 implementation! This AS4 path attribute will be ignored by quagga.
10
[AS4] <neighbor ip>
   BGP AS4 capable peer send AS4_AGGREGATOR
Quagga has received an AS4 aggregator from an AS4 peer. This is not supposed to happen (between AS4 capable peers, the aggregator attributes are exchanged with 4 byte asnumbers in them, so as4_aggregator will never be exchanged). The peer has a faulty AS4 implementation! This AS4 aggregator attribute will be ignored by quagga.
11
[AS4] <neighbor ip>
   BGP not AS4 capable peer send
   AGGREGATOR != AS_TRANS and AS4_AGGREGATOR,
   so ignore AS4_AGGREGATOR and AS4_PATH
Receiving an AS4 aggregator from an AS2 peer and at the same time finding that the aggregator is not AS_TRANS means that something which was aggregated by an AS4 speaker was aggregated again by an AS2 speaker later. In this situation AS4 aggregator and AS4 path are to be ignored because we can not determine anything useful out of them.
12
[AS4] <neighbor ip>
   BGP not AS4 capable peer send AS4_AGGREGATOR
   but no AGGREGATOR,
   will take it as if AGGREGATOR with AS_TRANS
   had been there
This time we are missing the AGGREGATOR with the value AS_TRANS, which should accompany the AS4_AGGREGATOR which comes from an AS2 peer. Quagga will tolerate the missing attribute.

'debug bgp as4 segment' messages

Looking into the segments was necessary once when programming the AS4 patch because I hit problems not directly related with my own patch, and they were very helpful in realizing what was happening.

You should never be forced to go that deep into as path segment particulars... but the command is still there, just in case. Be aware that this debug command will fill your log up pretty fast; I would not recommend enabling this with a full bgp feed.

# Message Explanation
13
[AS4SEG] 
   Parse aspath segment: got total byte length <length>
Quagga got an as path with this length. (An as-path can consist out of many segments, and this is the length over all segments).
14
[AS4SEG] 
   Parse aspath segment: got type <type in decimal>, length <length>
You see the type of a segment (in code) and the length of this one.
15
[AS4SEG] 
   Parse aspath segment: Read <asnumber> into this segment
This is one as number which is in this segment.
16
[AS4SEG] 
   Parse aspath segment: Bytes now: <number of bytes>
This number of bytes has now been munched up. Munching will continue until we reach the overall length which was logged some lines before.

error messages

Finally, there are a few errors the AS4 handling may stumble over. The corresponding connection will be NOTIFIED and ceased in all these cases and no session will be established.

# Message Explanation
17
<neighbor ip>
    Capability length error <length>
The capability in the open had a wrong length. (NOTIFY_CEASE,0)
18
<neighbor ip>
    bad OPEN, got AS_TRANS but no AS4 capability address
    peer->cap is <address>, value <value> 
We have a neighbor which uses AS_TRANS for its 16 bit as in the OPEN, but it does not advertise AS4 capability. That SHALL NOT be as per the draft (this is an AS2 that uses AS_TRANS for its as number). (NOTIFY_CEASE,BGP_NOTIFY_CEASE_CONNECT_REJECT)
19
<neighbor ip>
    bad OPEN, got AS4 capability, but remote_as <as> mismatch
    with 16bit 'myasn' <as> in open
A neighbor with AS4 capability and an AS number smaller 65536 gives us different as numbers in the capability and the open. (NOTIFY_CEASE,BGP_NOTIFY_CEASE_CONNECT_REJECT)