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

Reply via email to