So in our case we terminate peering and transit on different routers. Peering routers have well flow enabled (the one that starts with a J that’s inline). With NFSEN / NFDUMP we’re able to collect that flow data and look for anomalous flows or other issues. We pretty much detect and then deal with peering issues rather than prevent them with whitelists and so forth but then again we’ve been lucky and not experienced to many issues other than the occasional leakage of prefixes and such which maxprefix handles nicely.
Thanks Scott > On Aug 18, 2015, at 8:29 AM, Tim Durack <tdur...@gmail.com> wrote: > > Question: What is the preferred practice for separating peering and transit > circuits? > > 1. Terminate peering and transit on separate routers. > 2. Terminate peering and transit circuits in separate VRFs. > 3. QoS/QPPB ( > https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf > ) > 4. Don't worry about peers stealing transit. > 5. What is peering? > > Your comments are appreciated. > > -- > Tim:> > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
