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