On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering <gert@greenie.muc.de> wrote:

Hi,

On Tue, Aug 18, 2015 at 08:29:31AM -0400, Tim Durack wrote:

...

4. Don't worry about peers stealing transit. 5. What is peering?

I'm afraid that the majority of answers will be 4./5., mixed with "6. what? how can peers stell my transit?!"

We're somewhat into the "we'll notice if there is surprisingly high inbound traffic on peering, and then we'll find the peer, and apply appropriate measures" camp... (since we're a hosting shop, we have mostly outgoing traffic, so "significant" amounts of incomnig traffic stick out).

But yeah, something more strict might be in order.

Thanks for the response. This is what I was guessing. We currently do "2. Terminate peering and transit circuits in separate VRFs." which works well when everything is a VRF but comes at the cost of higher resource usage (RIB & FIB.) I was thinking a creative solution might be: "7. DSCP mark packets on peering ingress, police on transit egress." Not sure if I really want to get into using DSCP bits for basic IP service though.

(It would be cool if Cisco would understand that hardware forwarding platforms need useful netflow with MAC-addresses in there... ASR9k at least got working MAC-accounting, but more fine grained telemetry would certainly be appreciated. Software IOS can do it, Sup720 cannot do it due to hardware constraints, Sup2T exports MAC addresses taken from random caches in the system but not the inbound packets, XR doesn't do it at all, hrmph)

gert

-- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ Gert Doering - Munich, Germany gert@greenie.muc.de fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de

-- Tim:>