[c-nsp] Peering + Transit Circuits

[Tim Durack]

On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering <gert at 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 at greenie.muc.de
> fax: +49-89-35655025
> gert at net.informatik.tu-muenchen.de
>



-- 
Tim:>