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
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
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
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
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":
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
> assuming birds Router ID is 1.1.1.1
Yep, that's correct (I obviously modified that before submitting the email).
> 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).
That's a good point, it looks like the default
Hey Brooks,
I can confirm I have a similar setup collecting Netflow so in principle this
should do what you want. The bgp_agent_map also looks 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
11 matches
Mail list logo
