Hi Brooks,
We can certainly take this off list. The next step is to 100% confirm
that the IPv6 prefixes are landing onto pmacct. The fact a BGP dump does
not reveal IPv6 prefixes means this is not a mapping issue but either a
decoding one (super weird plus you would find tracks of this in the log)
or the IPv6 prefixes are not really being sent onto pmacct by BIRD (also
weird but we already kind of ran in such a situation so ..).
For this i propose again to look in wire traffic with tcpdump/wireshark,
perhaps make a trace with tcpdump so that then it can be analised in
more comfort with wireshark via UI.
Paolo
On Sat, Oct 19, 2019 at 11:49:28PM -0400, Brooks Swinnerton wrote:
> Thank you for the suggestion, Paolo. I went ahead and dumped the BGP table
> but don't see any IPv6 routes in there (though it's quite large as it has
> the V4 table from an IX). I can share this off list if it would be helpful.
>
> To recap, my `/etc/pmacct/peering_agent.map` file is:
>
> ```
> bgp_ip=1.1.1.1 ip=0.0.0.0/0
> ```
>
> (where `1.1.1.1` is the router ID of the BGP [bird] server pmacctd is
> peering with).
>
> And my configuration file is:
>
> ```
> !
> ! 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_interfaces_map: /etc/pmacct/interfaces.map
> pre_tag_map: /etc/pmacct/pretag.map
> pmacctd_as: bgp
> pmacctd_net: bgp
> sampling_rate: 1
> !
> bgp_daemon: true
> bgp_daemon_ip: 127.0.0.2
> bgp_daemon_port: 180
> bgp_daemon_max_peers: 10
> bgp_agent_map: /etc/pmacct/peering_agent.map
> !
> aggregate: src_host, dst_host, src_port, dst_port, src_as, dst_as, label,
> proto
> !
> plugins: kafka
> kafka_output: json
> kafka_broker_host: kafka.fqdn.com
> kafka_topic: pmacct.acct
> kafka_refresh_time: 5
> kafka_history: 5m
> kafka_history_roundoff: m
> ```
>
> And BIRD does appear to be announcing the V6 routes to the pmacctd daemon:
>
> ```
> bird> show protocols all pmacctd46
> Name Proto Table State Since Info
> pmacctd46 BGP --- up 2019-10-20 03:39:08 Established
> Description: pmacctd
> Message: pmacct received SIGINT - shutting down
> BGP state: Established
> Neighbor address: 127.0.0.2
> Neighbor AS: 000000
> Local AS: 000000
> Neighbor ID: 127.0.0.2
> Local capabilities
> Multiprotocol
> AF announced: ipv4 ipv6
> Route refresh
> Graceful restart
> Restart time: 120
> AF supported: ipv4 ipv6
> AF preserved:
> 4-octet AS numbers
> Enhanced refresh
> Long-lived graceful restart
> Neighbor capabilities
> Multiprotocol
> AF announced: ipv4 ipv6
> 4-octet AS numbers
> Session: internal multihop route-reflector AS4
> Source address: 127.0.0.1
> Hold timer: 69.116/90
> Keepalive timer: 13.114/30
> Channel ipv4
> State: UP
> Table: master4
> Preference: 100
> Input filter: (unnamed)
> Output filter: (unnamed)
> Routes: 0 imported, 185041 exported, 0 preferred
> Route change stats: received rejected filtered ignored
> accepted
> Import updates: 0 0 0 0
> 0
> Import withdraws: 0 0 --- 0
> 0
> Export updates: 185248 0 0 ---
> 185248
> Export withdraws: 42 --- --- ---
> 42
> BGP Next hop: 127.0.0.1
> IGP IPv4 table: master4
> Channel ipv6
> State: UP
> Table: master6
> Preference: 100
> Input filter: (unnamed)
> Output filter: (unnamed)
> Routes: 0 imported, 74840 exported, 0 preferred
> Route change stats: received rejected filtered ignored
> accepted
> Import updates: 0 0 0 0
> 0
> Import withdraws: 0 0 --- 0
> 0
> Export updates: 75161 0 0 ---
> 75161
> Export withdraws: 81 --- --- ---
> 81
> BGP Next hop: ::
> IGP IPv6 table: master6
> ```
>
> On Mon, Oct 14, 2019 at 2:47 AM Paolo Lucente <pa...@pmacct.net> wrote:
>
> >
> > Could we repeat the same troubleshooting as for the other issue: let's
> > enable dumping of BGP data to a file just to make sure data is making it
> > over. Even just to check the route is among those 74479 of 132180 routes
> > exported.
> >
> > Paolo
> >
> > On Sun, Oct 13, 2019 at 07:19:09PM -0400, Brooks Swinnerton wrote:
> > > Hmph, no dice. It looks like BIRD is exporting IPv6 routes:
> > >
> > > ```
> > > bird> show route export pmacctd46 count
> > > 173376 of 337458 routes for 173376 networks in table master4
> > > 74479 of 132180 routes for 74479 networks in table master6
> > > Total: 247855 of 469638 routes for 247855 networks in 2 tables
> > > ```
> > >
> > > But the flows in Kafka still appear to have 0 as the AS for both src and
> > > dst:
> > >
> > > ```
> > > {"event_type": "purge", "as_src": 0, "as_dst": 0, "ip_src":
> > > "2607:f8b0:4006:814::200e", "ip_dst":
> > "2602:fe2e:42:8:8489:bdf6:1bbe:cc60",
> > > "port_src": 443, "port_dst": 51609, "ip_proto": "tcp", "stamp_inserted":
> > > "2019-10-13 23:10:00", "stamp_updated": "2019-10-13 23:13:51", "packets":
> > > 1, "bytes": 352, "writer_id": "default_kafka/25373"}
> > > ```
> > >
> > > The destination AS being zero makes sense, as that's my own:
> > >
> > > ```
> > > $ sudo birdc show route for 2602:fe2e:42:8:8489:bdf6:1bbe:cc60 all
> > > BIRD 2.0.6 ready.
> > > Table master6:
> > > 2602:fe2e:42::/48 unicast [static4 2019-10-10] * (200)
> > > via 2602:fe2e:1::135 on ens5
> > > Type: static univ
> > > ```
> > >
> > > But there should be an AS present for the source:
> > >
> > > ```
> > > $ sudo birdc show route for 2607:f8b0:4006:814::200e all | grep as_path
> > > BGP.as_path: 15169
> > > BGP.as_path: 6939 15169
> > > ```
> > >
> > > On Sun, Oct 13, 2019 at 4:28 PM Paolo Lucente <pa...@pmacct.net> wrote:
> > >
> > > >
> > > > Super cool. It would remain the one-liner you have got at the moment:
> > > >
> > > > bgp_ip=1.1.1.1 ip=0.0.0.0/0
> > > >
> > > > Keep me posted.
> > > >
> > > > Paolo
> > > >
> > > > On Sun, Oct 13, 2019 at 04:21:21PM -0400, Brooks Swinnerton wrote:
> > > > > I’m actually already doing option 1 : ), what would the map look
> > like for
> > > > > that?
> > > > >
> > > > > On Sun, Oct 13, 2019 at 3:47 PM Paolo Lucente <pa...@pmacct.net>
> > wrote:
> > > > >
> > > > > >
> > > > > > Hi Brooks,
> > > > > >
> > > > > > You are in an unsupported use-case, ie. same BGP Agent ID maped
> > onto
> > > > two
> > > > > > different entries. You can get out of it in three different ways:
> > 1) my
> > > > > > top recommendation: travel both addrress families as part of the
> > same
> > > > BGP
> > > > > > session; 2) use two different BGP Agent ID for ipv4 and for ipv6;
> > 3)
> > > > use
> > > > > > session IP addesses (that is, not BGP Agent ID) for the mapping
> > > > (although
> > > > > > in your case i am afaid this won't work since it's all taking place
> > > > over
> > > > > > loopback interfaces). Let me know if any of this can work for you.
> > > > > >
> > > > > > Paolo
> > > > > >
> > > > > > On Sun, Oct 13, 2019 at 01:45:36PM -0400, Brooks Swinnerton wrote:
> > > > > > > Hello again!
> > > > > > >
> > > > > > > I'm using pmacct with Kafka to stream flows. This is paired with
> > the
> > > > BGP
> > > > > > > functionality to add the `src_as` and `dst_as`. This all works
> > great
> > > > for
> > > > > > > IPv4, but I'm struggling to figure out how to do this for IPv6 as
> > > > well.
> > > > > > >
> > > > > > > Here is the current configuration:
> > > > > > >
> > > > > > > ```
> > > > > > > !
> > > > > > > ! 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
> > > > > > > pmacctd_as: bgp
> > > > > > > pmacctd_net: bgp
> > > > > > > sampling_rate: 10
> > > > > > > !
> > > > > > > bgp_daemon: true
> > > > > > > bgp_daemon_ip: 127.0.0.2
> > > > > > > bgp_daemon_port: 180
> > > > > > > bgp_daemon_max_peers: 10
> > > > > > > bgp_agent_map: /etc/pmacct/peering_agent.map
> > > > > > > !
> > > > > > > aggregate: src_host, dst_host, src_port, dst_port, src_as,
> > dst_as,
> > > > proto
> > > > > > > !
> > > > > > > plugins: kafka
> > > > > > > kafka_output: json
> > > > > > > kafka_broker_host: kafka.fqdn.com
> > > > > > > kafka_topic: pmacct.acct
> > > > > > > kafka_refresh_time: 10
> > > > > > > kafka_history: 5m
> > > > > > > kafka_history_roundoff: m
> > > > > > > ```
> > > > > > >
> > > > > > > Where `/etc/pmacct/peering_agent.map` is defined as:
> > > > > > >
> > > > > > > ```
> > > > > > > bgp_ip=1.1.1.1 ip=0.0.0.0/0 filter='ip'
> > > > > > > bgp_ip=1.1.1.1 ip=::/0 filter='ip6'
> > > > > > > ```
> > > > > > >
> > > > > > > (1.1.1.1 is the router ID on the other side of the BGP session)
> > > > > > >
> > > > > > > This works well for IPv4 traffic, resulting in the following
> > Kafka
> > > > > > events:
> > > > > > >
> > > > > > > ```
> > > > > > > {"event_type": "purge", "as_src": 0, "as_dst": 396507, "ip_src":
> > > > > > > "23.157.160.138", "ip_dst": "23.129.64.208", "port_src": 37649,
> > > > > > "port_dst":
> > > > > > > 443, "ip_proto": "tcp", "stamp_inserted": "2019-10-13 17:40:00",
> > > > > > > "stamp_updated": "2019-10-13 17:43:11", "packets": 3, "bytes":
> > 156,
> > > > > > > "writer_id": "default_kafka/15635"}
> > > > > > > {"event_type": "purge", "as_src": 0, "as_dst": 0, "ip_src":
> > > > > > > "2607:f8b0:400d:c01::bc", "ip_dst": "2602:fe2e:42:2::2",
> > "port_src":
> > > > > > 5228,
> > > > > > > "port_dst": 63746, "ip_proto": "tcp", "stamp_inserted":
> > "2019-10-13
> > > > > > > 17:40:00", "stamp_updated": "2019-10-13 17:43:11", "packets": 1,
> > > > "bytes":
> > > > > > > 72, "writer_id": "default_kafka/15635"}
> > > > > > > ```
> > > > > > >
> > > > > > > But for IPv6 traffic, neither the `as_src` or `as_dst` comes
> > through.
> > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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
