Mailing List Archive

Maybe you should be looking at DHCPv6 if you want those kinds of logs.

On Fri, Mar 22, 2019 at 2:19 PM Jason Healy <jhealy@logn.net> wrote:
>
> We're starting to play around more with IPv6, and one thing we're missing is a log of who has which address. In IPv4 we have DHCP and can check the logs, but we're using SLAAC for v6 so that's not an option.
>
> I set up a quick trunk interface with all our VLANs as members and started sniffing. While I'm seeing plenty of neighbor discoveries, I'm not seeing any(?) neighbor advertisements. I'm guessing that because the sniffing box doesn't have an address on each VLAN, it's not participating in ND and registering for multicast, so we're getting pruned. IGMP snooping is on by default on all VLANs.
>
> I'd prefer not to have to add an interface on each VLAN just to grab all this traffic (more to keep in sync, security concerns, etc). Is there a way to tell the switch to force IPv6 multicast traffic for ff02::1 to go to a specific port? Our core is a QFX5100; the other switches in the network are a mix of EX3200/4200/3400.
>
> For the moment I've got it to work by setting up firewall filters on each VLAN in our core and port-mirroring just the ICMPv6 (type 136) traffic to a monitoring port. That works, but it's also a lot of configuration overhead. If there's a better way, I'd love suggestions!
>
> Thanks,
>
> Jason
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Mar 22, 2019, at 9:25 PM, Crist Clark <cjc+j-nsp@pumpky.net> wrote:
>
> Maybe you should be looking at DHCPv6 if you want those kinds of logs.

We did. ;-) However, Google seems quite set on not supporting it on Android:

https://issuetracker.google.com/issues/36949085

https://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-poses-security-and-ipv6-deployment-issues/


Thus, we need some kind of measure to deal with SLAAC, as it seems that no Android device will do DHCPv6 (we're a school that allows BYOD, so I can't ban Android devices).

On another note, since my last post I've found that Junos 17 has a feature for MLD snooping, including static subscriptions to a listening group. I'm going to need to update our QFX and see if that might get me more of what I need.

Thanks,

Jason
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Can you log DHCPv6 PD (Prefix Delegation) also ?

-Aaron


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Thanks Jason, that question was for Crist Clark since he mentioned logging.

-Aaron


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Somewhat late to the party, but I'm thinking about similar things at the
moment. We've not really had too many issues with this in the (many) years
we've been doing production IPv6, but now we're in the process of
considering rolling PI IPv6 out, and more extensively (into student VLANs
[where the naughty lives]), we're thinking about it fairly seriously.

Of course, if you mandated only EUI64 - and no cheating, in some way - that
solves part of the problem, but is entirely unrealistic, overly simplistic
(and possibly undesirable) in practice.

So, we're left with figuring out what the routers know.

If you're running SNMP on your (Juniper) subnet router/gateway device(s),
you can use SNMP to query a mapping between IP addresses and physical (MAC)
addresses - in essence, you're getting some version of the ND table in a
way that you can query remotely without needing to put another random
interface into each subnet or do some kind of port mirroring; this is, to
some extent, reasonably scalable (i.e. if you have shedloads of routers,
you may have multiple hosts polling and processing SNMP).

This is the most relevant SNMP OID I've found:
https://apps.juniper.net/mib-explorer/navigate.jsp#object=ipNetToPhysicalTable&product=Junos%20OS&release=17.3R3

It seems to do things like ignore leading zeroes in MAC addresses, so
you'll probably need to handle that.

Now what one needs to do is create a data structure to contain the parsed
information, together with:
1) Time this was the case (because when IP address X was in use by client Y
is often important; hello, Cease & Desist...)
2) Multiple IP to MAC mappings (because there can be many IPv6 addresses
per MAC over time, and at any point in time)
3) Tie in user identity (probably leveraging 802.1X either on wired ports
or through your wireless network) - you ought to then have both username
and MAC.

You can probably extend this in various ways (like perhaps what
physical/logical interface(s) they're learnt on, if that's not obvious from
the IPv6 subnet), if desired.

The joy of this is you also end up with a single source of truth, because
you can, at the same time, build up the same info for IPv4.

Obviously, you'll need to query ALL of your routers.

That all needs to be regularly slurped into a database of some kind, and
then you need some tools for your support agents / sysadmins to query it...

I've not yet gone much beyond thinking up the above, but it's going to need
to be built at some stage!

https://forums.juniper.net/t5/Security/L2-security-on-IPv6/ta-p/322231 has
some interesting thoughts to tackle at more or less the same time, if
you've not (yet) gotten to thinking about that.

<https://www.ru.ac.za>

James Stapley
Network Architect: I&TS Division
t: +27 (0) 46 603 8849
Struben Building, Artillery Road, Grahamstown, 6139
PO Box 94, Grahamstown, 6140, South Africa
www.ru.ac.za


On Fri, 22 Mar 2019 at 23:21, Jason Healy <jhealy@logn.net> wrote:

> We're starting to play around more with IPv6, and one thing we're missing
> is a log of who has which address. In IPv4 we have DHCP and can check the
> logs, but we're using SLAAC for v6 so that's not an option.
>
> I set up a quick trunk interface with all our VLANs as members and started
> sniffing. While I'm seeing plenty of neighbor discoveries, I'm not seeing
> any(?) neighbor advertisements. I'm guessing that because the sniffing box
> doesn't have an address on each VLAN, it's not participating in ND and
> registering for multicast, so we're getting pruned. IGMP snooping is on by
> default on all VLANs.
>
> I'd prefer not to have to add an interface on each VLAN just to grab all
> this traffic (more to keep in sync, security concerns, etc). Is there a
> way to tell the switch to force IPv6 multicast traffic for ff02::1 to go to
> a specific port? Our core is a QFX5100; the other switches in the network
> are a mix of EX3200/4200/3400.
>
> For the moment I've got it to work by setting up firewall filters on each
> VLAN in our core and port-mirroring just the ICMPv6 (type 136) traffic to a
> monitoring port. That works, but it's also a lot of configuration
> overhead. If there's a better way, I'd love suggestions!
>
> Thanks,
>
> Jason
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Apr 16, 2019, at 12:46 PM, James Stapley <j.stapley@ru.ac.za> wrote:
>
> This is the most relevant SNMP OID I've found:
> https://apps.juniper.net/mib-explorer/navigate.jsp#object=ipNetToPhysicalTable&product=Junos%20OS&release=17.3R3
>
> That all needs to be regularly slurped into a database of some kind, and
> then you need some tools for your support agents / sysadmins to query it...
>
> I've not yet gone much beyond thinking up the above, but it's going to need
> to be built at some stage!

James,

Thanks for your email. After messing around a big longer, we finally settled on polling, as you mentioned above.

We started out with SNMP, but walking the tables took a fair amount of clock/cpu time. We ran some tests and found that netconf over SSH had less overhead in our setup, even when accounting for the SSH setup and teardown. We now have a script that happily sucks up the ND table once or twice a minute and parses all the entries. The netconf output had some additional items (like ageout) that help us track adds, refreshes, and deletes (much like DHCP discover, renew, and release), which works better for our linear logging. Again, you could probably do just as much with SNMP, but this was easier to script and had better performance.

We haven't started on the "database" part just yet, but there are some things out there that have tried to do this:

http://netdisco.org

No idea if it handles IPv6 yet (been a few years since we've tried it), but on v4 it did most of the "accounting" type stuff you mentioned.

Thanks,

Jason
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp