Today I am reloading some switches with a new TCAM partitioning.
It turned out that some new (to us) equipment had zero space allocated for
IPv6 multicast groups, which was really causing us a lot of mysterious stuff
where ND just wouldn't work.
("show sdm prefer" if someone is finding this email later on...)For one switch, we had an out-of-band access to get to the console/craft so I could do this remotely. For a second switch, it turned out that I had no way to get to the console server that didn't go through that switch. (There was a goal of having a separate mgmt network, but it was hard to convince STP that loops weren't involved. My STP-fu is low) So of course, I look forward to using ACP/RFC8994 for this. While RPL ought to be able to route around a failing/restarting switch, and in theory, if the switch knows it is going down, it can do appropriate DAO messages to remove itself from the DODAG. But, I'd want to make sure that I wasn't going through the switch before starting the maintenance. Some kind of "protect" marking. It occured to me that p2p-rpl could perhaps do this if it could express the right metric being "does not traverse device X". Or now we think we can replace this with aodv-rpl. I'm wondering if anyone has any thoughts on about to express this metric? Is a metric the right thing to do? I doubt that this has utility in sensor LLNs, but I think that RFC8994 ACPs would definitely like to have this. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
