Hi Jordan, Outcome of our exchange was that it was actually not a bug; rather packets were VLAN-tagged (and libpcap filters are sensible to both VLAN tags and MPLS labels). So, in the end, the filter had to be written as:
set_tag=4 ip=0.0.0.0/0 filter='ip or (vlan and ip)' set_tag=6 ip=0.0.0.0/0 filter='ip6 or (vlan and ip6)' (this was a pre_tag_map rather than a bgp_agent_map) Wrt your issue: did you try not using the BGP Router ID but the actual session IP address? While i see the issue with trying to match against a BGP Router ID presented twice, using the session IP address should work. Finally, you are right that bgp_daemon_msglog does not work anymore. The feature has been expanded greatly recently and it does require a file to be pointed at a file. You can do a grep over bgp_daemon_msglog_file in QUICKSTART. Cheers, Paolo On Wed, Aug 24, 2016 at 05:24:31PM +0300, Jordan wrote: > Hello Paolo, Derrick > > Would you share us your findings here? We're having the same problem > using a bit different setup. > > We're running a couple of sessions(IPv4 and IPv6) both using the > same router id (IPv4 address). > In the agent_to_peer we're having pure configuration using only the > IPv4 address for bgp_id(without any filters and etc.). > > We're getting either IPv4 or IPv6 BGP attributes in the database > depending on the sequence the BGP sessions are established. > > Please note that we're injecting full IPv4/IPv6 BGP tables into the > daemon(if it's some kind of a memory limitation). > > > Also I tried to perform some BGP debug using the /bgp_daemon_msglog > /but it seems there's no such valid key in the last version?! > > Thanks in advance. > > Best Regards, > > > > > > > On 4.03.2016 21:52, Derrick Sawyer wrote: > >Hi Paolo, > >Yes very perplexing. If you can ping me privately, I can give you > >more detail and show you what I am seeing. > > > >Thanks, > >-/-Derrick > > > >On Fri, Mar 4, 2016 at 6:40 AM, Paolo Lucente <pa...@pmacct.net > ><mailto:pa...@pmacct.net>> wrote: > > > > Hi Derrick, > > > > You mean you get only v4 or v6 in the /tmp/pmacct.json? When records > > are purged from the cache to the print_output_file, there is no > > distinction as v4 vs v6 (ie. separate loops or so) so i'm a bit > > puzzled - i can confirm you i've never been reported anything like > > that plus you have no filtering whatsoever in your config that can > > lead to such behaviour. > > > > I'd be more than happy to support you verifying whether this is > > actually somehow originated by the sFlow exporter. > > > > Cheers, > > Paolo > > > > On Fri, Mar 04, 2016 at 01:17:32AM -0800, Derrick Sawyer wrote: > > > Hi Paolo, > > > Seeing something weird with this setup. When I restart the > > sflow process, > > > I will get either all IPv4 or all IPv6 for each refresh. Have > > you seen > > > this before? Below is my config. > > > > > > == > > > !e Defaults > > > debug: false > > > daemonize: true > > > plugins: print > > > print_refresh_time: 60 > > > print_history_roundoff: m > > > print_history: 15m > > > print_output: json > > > print_output_file: /tmp/pmacct.json > > > print_cache_entries: 300007 > > > networks_cache_entries: 300007 > > > sfacctd_port: 7000 > > > !sfacctd_time_new: true > > > interface: eth0 > > > sfacctd_as: bgp > > > sfacctd_net: bgp > > > sfacctd_peer_as: true > > > sfacctd_renormalize: true > > > sfacctd_ip: 10.10.10.22 > > > plugin_buffer_size: 102400 > > > plugin_pipe_size: 102400000 > > > !pkt_len_distrib_bins: > > > 0-199,200-399,400-599,600-799,800-999,1000-1499,1500-9000 > > > pkt_len_distrib_bins: > > > > > > > 0-49,50-99,100-149,150-199,200-249,250-299,300-349,350-399,400-449,450-499,500-699,700-899,900-109 > > > 9,1100-1299,1300-1499,1500-9000 > > > > > > !BGP > > > bgp_daemon: true > > > bgp_daemon_max_peers: 10 > > > bgp_aspath_radius: 15 > > > bgp_table_per_peer_buckets: 4 > > > bgp_peer_src_as_type: bgp > > > bgp_src_as_path_type: bgp > > > bgp_src_local_pref_type: bgp > > > bgp_src_med_type: bgp > > > bgp_neighbors_file: /tmp/bgp.peers > > > bgp_peer_src_as_map: /opt/knifefish/etc/pmacct/peers.map > > > bgp_agent_map: /opt/knifefish/etc/pmacct/agent_to_peer.map > > > bgp_daemon_msglog_file: /tmp/bgp-peer.log > > > == > > > > > > Thanks, > > > -/-Derrick > > > > > > On Thu, Mar 3, 2016 at 4:47 PM, Derrick Sawyer > > <sawye...@gmail.com <mailto:sawye...@gmail.com>> wrote: > > > > > > > Hi Paolo, > > > > Opps ;) I forgot about that. That did the trick! The bgp > > agent mapping > > > > config with dual v4/v6 sessions seems to be the key for me. > > > > > > > > Again appreciate the help and quick responses! > > > > > > > > -/-Derrick > > > > > > > > On Thu, Mar 3, 2016 at 4:36 PM, Paolo Lucente > > <pa...@pmacct.net <mailto:pa...@pmacct.net>> wrote: > > > > > > > >> Hi Derrick, > > > >> > > > >> This should be because, according to the config you sent in > > the first > > > >> email, you have 'bgp_daemon_ip: X.X.X.X' - which effectively > > binds the > > > >> BGP daemon to only X.X.X.X. Please comment it out and if > > necessary do > > > >> any filtering via iptables or such. All working well, we can > > refine it > > > >> afterwards. > > > >> > > > >> Cheers, > > > >> Paolo > > > >> > > > >> PS: should this still not put us on the right path and should > > your box > > > >> be accessible remotely, vi'd be more than happy to have a > > look myself. > > > >> > > > >> > > > >> On Thu, Mar 03, 2016 at 04:12:41PM -0800, Derrick Sawyer wrote: > > > >> > Hi Paolo, > > > >> > It looks like I am not receiving IPv6 prefixes and the > > MP-BGP is not > > > >> > working. I will have to configured dual sessions but the > > IPv6 session > > > >> is > > > >> > not working. Below is my agent mapping file and router config. > > > >> > > > > >> > I am also running the latest pull from the git repo. > > > >> > > > > >> > --- > > > >> > bgp_ip=10.10.10.0 ip=10.10.10.0 filter=ip > > > >> > bgp_ip=2000:3000:404c:0000:0000:0000:0000:0000 > > ip=10.10.10.0 filter=ip6 > > > >> > ---- > > > >> > > > > >> > router bgp 65531 > > > >> > neighbor TESTv6 peer-group > > > >> > neighbor TESTv6 remote-as 65531 > > > >> > neighbor TESTv6 update-source Loopback0 > > > >> > neighbor TESTv6 timers 7 21 > > > >> > neighbor TESTv6 route-map NOTHING in > > > >> > neighbor TESTv6 route-map EVERYTHING out > > > >> > neighbor TESTv6 maximum-routes 0 > > > >> > neighbor 2000:3000:404c:1::1:a peer-group TESTv6 > > > >> > address-family ipv6 > > > >> > neighbor TESTv6 activate > > > >> > > > > >> > > > > >> > I dont see where pmacct is listening on th local IPv6 > > address for port > > > >> 179 > > > >> > so the router cant create a session. The only thing I see is: > > > >> > > > > >> > netstat -anp | grep 179 > > > >> > tcp 0 0 10.10.10.22:179 > > <http://10.10.10.22:179> 0.0.0.0:* LISTEN > > > >> > 13006/sfacctd: Core > > > >> > tcp6 0 0 :::1790 :::* > > > >> LISTEN > > > >> > 13006/sfacctd: Core > > > >> > > > > >> > Do I need to set the remote port to 1790? I tried to > > connect to 179 on > > > >> the > > > >> > local IPv6 address but get a connection refused. > > > >> > > > > >> > Any insight will be much appreciated. > > > >> > > > > >> > Thanks, > > > >> > -/-Derrick > > > >> > > > > >> > > > > >> > > > > >> > On Thu, Mar 3, 2016 at 2:38 AM, Paolo Lucente > > <pa...@pmacct.net <mailto:pa...@pmacct.net>> wrote: > > > >> > > > > >> > > Hi Derrick, > > > >> > > > > > >> > > Inline: > > > >> > > > > > >> > > On Wed, Mar 02, 2016 at 03:00:17PM -0800, Derrick Sawyer > > wrote: > > > >> > > > > > >> > > > Also, are you sending v4 and v6 AFs over a v4 BGP > > session or > > > >> > > > you have two BGP sessions, one v4 and one v6? > > > >> > > > *-- Sending v4 & v6 over v4 session. What be the best > > way to have > > > >> a v4 > > > >> > > an > > > >> > > > v6 session? 2 config files or can this be done from a > > single conf?* > > > >> > > > > > >> > > I recommend sending v4 and v6 AF's over the same v4 BGP > > session; this > > > >> > > is because v4 and v6 flows are both sent via the same > > NetFlow v4 > > > >> address > > > >> > > and this eases correlation. Otherwise you would need a > > bgp_agent_map, > > > >> > > ie. overhead, to make it work; something like: > > > >> > > > > > >> > > bgp_ip=10.10.10.0 ip=10.10.10.0 filter=ip > > > >> > > bgp_ip=<IPv6 address> ip=10.10.10.0 filter=ip6 > > > >> > > > > > >> > > Which reads: correlate v4 flows from 10.10.10.0 to the > > BGP session > > > >> > > with 10.10.10.0 and correlate v6 flows from 10.10.10.0 to > > the BGP > > > >> > > session with <IPv6 address>. This is only a > > recommendation and if, > > > >> > > for whatever reason including architectural policies, one > > has to > > > >> > > build two BGP sessions, v4 and v6, then this is supported > > (via a > > > >> > > a bgp_agent_map snippet like the above). > > > >> > > > > > >> > > > What is the content of the file pointed by bgp_agent_map? > > > >> > > > *-- This is the peering routers IPs (changed but looks > > like this)* > > > >> > > > *bgp_ip=10.10.10.0 ip=10.10.10.0bgp_ip=10.10.11.0 > >ip=10.10.10.0* > > > >> > > > > > >> > > This is not needed, you can skip the map all together as > > this kind > > > >> > > of correlation is the only one done automagically for you > > (ie. see > > > >> > > if there is a BGP session from an IP address or with a > > BGP session > > > >> > > ID same as the IP address with which NetFlow packets are > > exported). > > > >> > > > > > >> > > > do you see v6 prefixes landing allright onto pmacct, > > ie. as part of > > > >> the > > > >> > > > content of the file pointed by bgp_daemon_msglog_file? > > > >> > > > *-- When I use the src_host agg, I see v6 addresses but > > not when > > > >> using > > > >> > > the > > > >> > > > src_net agg. I do not see any v6 prefixes in > > > >> bgp_daemon_msglog_file* > > > >> > > > > > >> > > Then here could be the issue: can you check on your > > router that it > > > >> > > is actually sending the v6 prefixes? With something > > equivalent to > > > >> > > "show ip bgp neighbors <nfacctd VM IP address> > > advertised-routes" > > > >> > > on IOS? > > > >> > > > > > >> > > Cheers, > > > >> > > Paolo > > > >> > > > > > >> > > > > > > > > > > > > > > > > > >_______________________________________________ > >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
