> 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 traffic I was
expecting:
```
127.0.0.1.36143 > 127.0.0.1.180: Flags [P.], cksum 0xfe4b (incorrect ->
0xfc0d), seq 9200:9235, ack 234, win 342, options [nop,nop,TS val
1972706066 ecr 1972699157], length 35
14:46:51.746910 IP (tos 0x0, ttl 64, id 34830, offset 0, flags [DF], proto
TCP (6), length 52)
127.0.0.1.180 > 127.0.0.1.36143: Flags [.], cksum 0xfe28 (incorrect ->
0x9b98), ack 9235, win 342, options [nop,nop,TS val 1972706066 ecr
1972706066], length 0
14:46:51.988455 IP (tos 0xc0, ttl 64, id 2700, offset 0, flags [DF], proto
TCP (6), length 91)
127.0.0.1.36143 > 127.0.0.1.180: Flags [P.], cksum 0xfe4f (incorrect ->
0x1b06), seq 9235:9274, ack 234, win 342, options [nop,nop,TS val
1972706308 ecr 1972706066], length 39
14:46:51.988488 IP (tos 0x0, ttl 64, id 34831, offset 0, flags [DF], proto
TCP (6), length 52)
127.0.0.1.180 > 127.0.0.1.36143: Flags [.], cksum 0xfe28 (incorrect ->
0x998d), ack 9274, win 342, options [nop,nop,TS val 1972706308 ecr
1972706308], length 0
```
Which aligns with:
```
{"timestamp": "2019-10-13 14:40:00", "peer_ip_src": "127.0.0.1",
"peer_tcp_port": 55881, "event_type": "dump_init", "dump_period": 120,
"seq": 0}
{"timestamp": "2019-10-13 14:40:00", "peer_ip_src": "127.0.0.1",
"peer_tcp_port": 55881, "event_type": "dump_close", "entries": 0, "tables":
1, "seq": 0}
{"timestamp": "2019-10-13 14:42:00", "peer_ip_src": "127.0.0.1",
"peer_tcp_port": 55881, "event_type": "dump_init", "dump_period": 120,
"seq": 1}
{"timestamp": "2019-10-13 14:42:00", "peer_ip_src": "127.0.0.1",
"peer_tcp_port": 55881, "event_type": "dump_close", "entries": 0, "tables":
1, "seq": 1}
```
Is it normal that `peer_tcp_port` is a random port and not 179? I know
pmacctd's BGP port is listening on 180, but the peer port (BIRD) is 179:
```
bgp_daemon: true
bgp_daemon_ip: 127.0.0.1
bgp_daemon_port: 180
```
I've also went ahead and removed any filters that were previously in place
in BIRD so it should be sending all prefixes.
On Sun, Oct 13, 2019 at 10:08 AM Paolo Lucente <pa...@pmacct.net> wrote:
>
> 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,
> ie. all looks good, could you try master code on GitHub? Should also
> that one not work, we should find a way for me to reproduce this (as i
> tested the scenario and it appears to work for me against an ExaBGP) or,
> let me just mention it, troubleshoot stuff on your box.
>
> Paolo
>
> On Sun, Oct 13, 2019 at 08:46:47AM -0400, Brooks Swinnerton wrote:
> > 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,
> > "seq": 0}
> > {"timestamp": "2019-10-13 12:42:00", "peer_ip_src": "127.0.0.1",
> > "peer_tcp_port": 39587, "event_type": "dump_close", "entries": 0,
> "tables":
> > 1, "seq": 0}
> > ```
> >
> > But looking at the BIRD side of things, I can see the routes are indeed
> > being exported:
> >
> > ```
> > bird> show route export AS000000v4 count
> > 172973 of 336950 routes for 173059 networks in table master4
> > ```
> >
> > On Sun, Oct 13, 2019 at 8:30 AM Paolo Lucente <pa...@pmacct.net> wrote:
> >
> > >
> > > 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 looks good as well as the log extract you posted. For more debug
> > > info you can perhaps dump routes received via BGP just to make extra
> > > sure all is well on that side of the things too, ie.:
> > >
> > > bgp_table_dump_file: /path/to/spool/bgp-$peer_src_ip-%H%M.log
> > > bgp_table_dump_refresh_time: 120
> > >
> > > Let us know how it goes.
> > >
> > > Paolo
> > >
> > > On Sat, Oct 12, 2019 at 11:36:12PM -0400, Brooks Swinnerton wrote:
> > > > 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
> > > > address, but in both the Kafka consumer and `pmacct -s`, I do not
> see the
> > > > AS values:
> > > >
> > > > ```
> > > > {"event_type": "purge", "as_src": 0, "as_dst": 0, "ip_src":
> "1.1.1.138",
> > > > "ip_dst": "5.9.43.211", "port_src": 443, "port_dst": 48268,
> "ip_proto":
> > > > "tcp", "stamp_inserted": "2019-10-13 02:50:00", "stamp_updated":
> > > > "2019-10-13 02:53:31", "packets": 1, "bytes": 52, "writer_id":
> > > > "default_kafka/3725"}
> > > > ```
> > > >
> > > > The pmacct log seems good:
> > > >
> > > > ```
> > > > Oct 13 02:51:37 bdr-nyiix pmacctd[3666]: INFO ( default/core ):
> > > Promiscuous
> > > > Mode Accounting Daemon, pmacctd 1.7.3-git (20190418-00+c4)
> > > > Oct 13 02:51:37 bdr-nyiix pmacctd[3666]: INFO ( default/core ):
> > > > '--enable-kafka' '--enable-jansson' '--enable-l2' '--enable-64bit'
> > > > '--enable-traffic-bins' '-
> > > > Oct 13 02:51:37 bdr-nyiix pmacctd[3666]: INFO ( default/core ):
> Reading
> > > > configuration file '/etc/pmacct/pmacctd.peering.conf'.
> > > > Oct 13 02:51:37 bdr-nyiix pmacctd[3666]: INFO ( default_kafka/kafka
> ):
> > > > cache entries=16411 base cache memory=54878384 bytes
> > > > Oct 13 02:51:38 bdr-nyiix pmacctd[3666]: INFO ( default/core ):
> [ens3,0]
> > > > link type is: 1
> > > > Oct 13 02:51:38 bdr-nyiix pmacctd[3666]: INFO ( default/core ):
> > > > [/etc/pmacct/peering_agent.map] (re)loading map.
> > > > Oct 13 02:51:38 bdr-nyiix pmacctd[3666]: INFO ( default/core ):
> > > > [/etc/pmacct/peering_agent.map] map successfully (re)loaded.
> > > > Oct 13 02:51:38 bdr-nyiix pmacctd[3666]: INFO ( default_kafka/kafka
> ):
> > > > JSON: setting object handlers.
> > > > Oct 13 02:51:38 bdr-nyiix pmacctd[3666]: INFO ( default/core/BGP ):
> > > maximum
> > > > BGP peers allowed: 2
> > > > Oct 13 02:51:38 bdr-nyiix pmacctd[3666]: INFO ( default/core/BGP ):
> > > waiting
> > > > for BGP data on 127.0.0.1:180
> > > > Oct 13 02:51:41 bdr-nyiix pmacctd[3666]: INFO ( default_kafka/kafka
> ):
> > > ***
> > > > Purging cache - START (PID: 3673) ***
> > > > Oct 13 02:51:41 bdr-nyiix pmacctd[3666]: INFO ( default_kafka/kafka
> ):
> > > ***
> > > > Purging cache - END (PID: 3673, QN: 0/0, ET: 0) ***
> > > > Oct 13 02:51:41 bdr-nyiix pmacctd[3666]: INFO ( default/core/BGP ):
> > > > [127.0.0.1] BGP peers usage: 1/2
> > > > Oct 13 02:51:41 bdr-nyiix pmacctd[3666]: INFO ( default/core/BGP ):
> > > > [1.1.1.1] Capability: MultiProtocol [1] AFI [1] SAFI [1]
> > > > Oct 13 02:51:41 bdr-nyiix pmacctd[3666]: INFO ( default/core/BGP ):
> > > > [1.1.1.1] Capability: 4-bytes AS [41] ASN [300000]
> > > > Oct 13 02:51:41 bdr-nyiix pmacctd[3666]: INFO ( default/core/BGP ):
> > > > [1.1.1.1] BGP_OPEN: Local AS: 300000 Remote AS: 397143 HoldTime: 90
> > > > Oct 13 02:51:51 bdr-nyiix pmacctd[3666]: INFO ( default_kafka/kafka
> ):
> > > ***
> > > > Purging cache - START (PID: 3678) ***
> > > > Oct 13 02:51:53 bdr-nyiix pmacctd[3666]: INFO ( default_kafka/kafka
> ):
> > > ***
> > > > Purging cache - END (PID: 3678, QN: 679/679, ET: 0) ***
> > > > ```
> > > >
> > > > And the configuration is as follows:
> > > >
> > > > ```
> > > > !
> > > > ! pmacctd configuration example
> > > > !
> > > > ! Did you know CONFIG-KEYS contains the detailed list of all
> > > configuration
> > > > keys
> > > > ! supported by 'nfacctd' and 'pmacctd' ?
> > > > !
> > > > ! debug: true
> > > > daemonize: false
> > > > pcap_interface: ens3
> > > > aggregate: src_host, dst_host, src_port, dst_port, src_as, dst_as,
> proto
> > > > sampling_rate: 10
> > > > !
> > > > plugins: kafka
> > > > kafka_output: json
> > > > kafka_broker_host: kafka-broker.fqdn.com
> > > > kafka_topic: pmacct.acct
> > > > kafka_refresh_time: 10
> > > > kafka_history: 5m
> > > > kafka_history_roundoff: m
> > > > !
> > > > bgp_daemon: true
> > > > bgp_daemon_ip: 127.0.0.1
> > > > bgp_daemon_port: 180
> > > > bgp_daemon_max_peers: 1
> > > > bgp_agent_map: /etc/pmacct/peering_agent.map
> > > > pmacctd_as: bgp
> > > > ```
> > > >
> > > > With the /etc/pmacct/peering_agent.map as:
> > > >
> > > > ```
> > > > bgp_ip=1.1.1.1 ip=0.0.0.0/0
> > > > ```
> > > >
> > > > And the other end of the BGP configuration (in BIRD) being:
> > > >
> > > > ```
> > > > protocol bgp AS300000v4c1 from transit_customer4 {
> > > > description "pmacctd";
> > > > local 127.0.0.1 port 179 as 300000;
> > > > neighbor 127.0.0.1 port 180 as 300000;
> > > > rr client;
> > > > }
> > > > ```
> > > >
> > > > And it has exported ~150k routes.
> > > >
> > > > Is there anything obvious that I'm doing wrong or perhaps a way that
> I
> > > can
> > > > turn on more debugging to lead me on the right trail?
> > >
> > > > _______________________________________________
> > > > pmacct-discussion mailing list
> > > > http://www.pmacct.net/#mailinglists
> > >
> > >
> > > _______________________________________________
> > > pmacct-discussion mailing list
> > > http://www.pmacct.net/#mailinglists
> > >
>
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
