He he he, 'fallback' is the legacy keyword for 'longest'. You should use
'longest', yes. High moments for a developer :-)
Paolo
On Sun, Oct 20, 2019 at 10:37:51AM -0400, Brooks Swinnerton wrote:
> I tried switching over the iBGP session to eBGP but it oddly started
> putting my AS as the `dst_
Hi Brooks,
There would be a few ways to achieve that:
1) change the iBGP session into an eBGP session;
2) set pmacctd_as and pmacctd_net to 'fallback' and add a networks_file
where you list (some of your) prefixes and associated ASN. While the
map can be refreshed at runtime - no need to
Wonderful. Thank you Brooks for sharing your finding. I will add a note
to documentation, it seems very relevant.
Paolo
On Sun, Oct 13, 2019 at 12:50:43PM -0400, Brooks Swinnerton wrote:
> Got it! I think for some reason BIRD didn't like that both BGP instances
> were sharing the same address.
So the session comes up and gets established: this would rule out firewall
filters, TCP MD5 or session mis-configurations (AS numbers, capabilities,
etc.). This should also mean that the BGP OPEN process is successful (this
is also confirmed by pmacct log you sent earlier on).
Now, from the tcpd
Oops, sorry I mismatched the tcpdump and bgp table dump values. They were
both indeed using 55881 at the time, but here is another capture that will
make more sense:
```
{"timestamp": "2019-10-13 14:48:00", "peer_ip_src": "127.0.0.1",
"peer_tcp_port": 36143, "event_type": "dump_close", "entries":
> 1) as super extra check, can you capture stuff with Wireshark and see
what is going on 'on the wire'? Do you see the routes being sent and
landing onto pmacct, etc.?
Gosh, I'm stumped. I do see traffic on port 180 and the port that is
referenced in the table dump, but it's not the cleartext BGP
Hi Brooks,
Wow, interesting yes. Your decoding is right: BGP table is empty. May i
ask you two things: 1) as super extra check, can you capture stuff with
Wireshark and see what is going on 'on the wire'? Do you see the routes
being sent and landing onto pmacct, etc.? 2) Should that be the case,
Thank you Paolo,
Interesting, it looks like the pmacctd end of the BGP session isn't picking
up the routes if I'm reading the `bgp_table_dump_file` correctly:
```
{"timestamp": "2019-10-13 12:42:00", "peer_ip_src": "127.0.0.1",
"peer_tcp_port": 39587, "event_type": "dump_init", "dump_period": 120
Hi Brooks,
+1 to Felix's answer. Also maybe two obvious pointsa: 1) with an iBGP
peering setup, AS0 can mean unknown or your own ASN (being a number
rather than a string, null is not an option) and 2) until routes are
received, source/destination IP prefixes can get associated to AS0.
Config lo
ooks fine, assuming
> birds Router ID is 1.1.1.1?
>
> Just a thought, as per the docs it’s recommended to set pmacctd_net to the
> same value as pmacctd_as (bgp in this case). Can you add src_net and
> dst_net to your aggregates and check if they also show up as zero?
>
>
>
acct-discussion@pmacct.net"
Betreff: [pmacct-discussion] BGP AS values are 0
Hello there!
I have pmacctd working with the Kafka addon and am attempting to include
`src_as` and `dst_as` information based on the BGP sessions running on the same
machine using the [BIRD
router](https://b
Hello there!
I have pmacctd working with the Kafka addon and am attempting to include
`src_as` and `dst_as` information based on the BGP sessions running on the
same machine using the [BIRD router](https://bird.network.cz).
I was able to successfully get the BGP session stood up using a loopback
12 matches
Mail list logo