There are many debug outputs if you use the new debug commands for AS4
debug bgp as4 debug bgp as4 segmentand 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.
# | 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. |
# | 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. |
# | 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) |