On 19/Aug/15 01:12, Patrick W. Gilmore wrote:
>
> Normally a router gets a packet and sends it on its way without looking at
> the source. However, if you have a router at the IX which has _only_ peer
> routes and your routes, that solves the problem. If I send you a packet for
> Comcast, you
On 25/Aug/15 14:23, Brian Turnbow wrote:
> Or use uRPF with an acl.
> You can specify what to block and what not to block and use S/RTBH as well.
Even though we're not receiving the full feed on dedicated peering
routers, you're talking at least 35% of it. Sometimes more...
Mark.
On 25/Aug/15 13:58, Scott Granados wrote:
> If you’re not enabling URPF at the peering routers and edges how do you
> handle things like RTBH?
D/RTBH still works fine.
S/RTBH would be an issue, but one could enable uRPF temporarily for that.
Mark.
On 18/Aug/15 22:43, Nick Hilliard wrote:
> i'd advise being careful with this approach: urpf at ixps is a nightmare.
We don't generally do uRPF at exchange points, for the simple reason
that the router is dedicated (meaning it does not carry a full table),
and peers leaking your routes to the I
On 18/Aug/15 18:02, Tim Durack wrote:
> Can I ask why you terminate peering and transit on different routers? (Not
> suggesting that is bad, just trying to understand the reason.)
Easier policy enforcement for us.
Lowers the chance of you dealing with traffic in ways you don't intend
(although
On 18/Aug/15 15:31, Tim Durack wrote:
>
> Not sure if I really want to get into using DSCP bits for basic IP service
> though.
There are use-cases, but they would mostly be internal.
Mark.
On 18/Aug/15 14:29, Tim Durack wrote:
> Question: What is the preferred practice for separating peering and transit
> circuits?
>
> 1. Terminate peering and transit on separate routers.
We do this.
Makes policy enforcement easier.
Mark.
Hi, Max --
On 19/08/2015 17:36, Max Tulyev wrote:
>My solution is:
>
>1. Don't care.
>2. If some peer steal your transit, and it is noticeable amount of
>traffic causing some problems for you - investigate and terminate that peer.
Unless this bandwidth fraud is taking place over a public p
On Wed, 19 Aug 2015, Max Tulyev wrote:
My solution is:
1. Don't care.
2. If some peer steal your transit, and it is noticeable amount of
traffic causing some problems for you - investigate and terminate that peer.
You forgot 3. Publicly shame on NANOG so that others will think twice
before p
My solution is:
1. Don't care.
2. If some peer steal your transit, and it is noticeable amount of
traffic causing some problems for you - investigate and terminate that peer.
On 18.08.15 15:29, Tim Durack wrote:
> Question: What is the preferred practice for separating peering and transit
> circu
On 18/08/2015 22:10, William Herrin wrote:
> This technique described isn't URPF, it's simple destination routing.
> The routes I offer you via BGP are the only routes in my table, hence
> the only routes I'm capable of routing. If you send me a packet for a
> _destination_ I didn't offer to you, I
sage -
> From: "John Osmon"
> To: "nanog list"
> Sent: Tuesday, August 18, 2015 8:30:45 PM
> Subject: Re: Peering + Transit Circuits
> On Tue, Aug 18, 2015 at 11:27:53PM +, Faisal Imtiaz wrote:
>> Thanks for the explanation,
>> I am still try
On Tue, Aug 18, 2015 at 11:27:53PM +, Faisal Imtiaz wrote:
> Thanks for the explanation,
> I am still trying to figure out the realistic business case where
> doing something like this would make sense to any party.
> (unless purely malicious or in error).
I'm sure others will reply as well
t;
> To: "Faisal Imtiaz"
> Cc: "Patrick W. Gilmore" , "nanog list"
> Sent: Tuesday, August 18, 2015 7:36:00 PM
> Subject: Re: Peering + Transit Circuits
> Thank You
> Bob Evans
> CTO
>
>> Thank you for the explanation..
>>
>
are lots, but don’t have my references with me. There’s 10K+ people on
this list, I’m sure someone else has a list they like. :)
--
TTFN,
patrick
> - Original Message -
>> From: "Patrick W. Gilmore"
>> To: "nanog list"
>> Sent: Tuesday, August 18
o for these, I would be much
> obliged..
>
>
> Thanks
>
> Faisal Imtiaz
> Snappy Internet & Telecom
> 7266 SW 48 Street
> Miami, FL 33155
> Tel: 305 663 5518 x 232
>
> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>
> - Ori
; To: "Faisal Imtiaz" , "Tim Durack"
>
> Cc: "nanog list" , cisco-...@puck.nether.net
> Sent: Tuesday, August 18, 2015 7:00:35 PM
> Subject: Re: Peering + Transit Circuits
> It's actually quite easy.
> Provider1 is present at Exchange1 and Ex
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232
Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
- Original Message -
> From: "Patrick W. Gilmore"
> To: "nanog list"
> Sent: Tuesday, August 18, 2015
istributed edge vs all
> in one when one has to bring anything down for any reason..
>
> I am open to learning and being corrected if any of the above is wrong !
>
>
> Faisal Imtiaz
> Snappy Internet & Telecom
>
> - Original Message -
>> From: "Tim
On 18 August 2015 at 14:29, Tim Durack wrote:
> 4. Don't worry about peers stealing transit.
>
Because both of our transit providers implement source filters. Any packets
received with a source IP not in the list of IP ranges registered by us
will be dropped by the transit provider. Stealing tra
all in one when one has to bring anything down for any
> reason..
>
> I am open to learning and being corrected if any of the above is wrong !
>
>
> Faisal Imtiaz
> Snappy Internet & Telecom
>
> - Original Message -
> > From: "Tim Durack"
> >
Imtiaz
Snappy Internet & Telecom
- Original Message -
> From: "Tim Durack"
> To: cisco-...@puck.nether.net, "nanog list"
> Sent: Tuesday, August 18, 2015 8:29:31 AM
> Subject: Peering + Transit Circuits
> Question: What is the preferred practice for separati
Why do I read this thread as “Peering + Transit Circus”
manning
bmann...@karoshi.com
PO Box 6151
Playa del Rey, CA 90296
310.322.8102
On 18August2015Tuesday, at 6:01, Jared Mauch wrote:
>
>> On Aug 18, 2015, at 8:47 AM, Gert Doering wrote:
>>
>> XR doesn't do it at all,
>> hrmph)
>>
On Tue, Aug 18, 2015 at 4:43 PM, Nick Hilliard wrote:
> On 18/08/2015 20:22, Tim Durack wrote:
>> This has always been my understanding - thanks for confirming. I'm weighing
>> cost-benefit, and looking to see if there are any other smart ideas. As
>> usual, it looks like simplest is best.
>
> i'd
On 18/08/2015 21:56, Gert Doering wrote:
> So how's that stopping one of your bilateral peers from sending you
> traffic destined elsewhere?
it doesn't: you detect it and depeer them. If they force the situation
with static routes, the traffic will be dropped.
Nick
On 18/08/2015 20:22, Tim Durack wrote:
> This has always been my understanding - thanks for confirming. I'm weighing
> cost-benefit, and looking to see if there are any other smart ideas. As
> usual, it looks like simplest is best.
i'd advise being careful with this approach: urpf at ixps is a nig
On Tue, Aug 18, 2015 at 1:29 PM, Patrick W. Gilmore
wrote:
> On Aug 18, 2015, at 1:24 PM, William Herrin wrote:
> > On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack wrote:
>
> >> Question: What is the preferred practice for separating peering and
> transit
> >> circuits?
> >>
> >> 1. Terminate peeri
On Aug 18, 2015, at 1:24 PM, William Herrin wrote:
> On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack 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 cir
On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack 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.o
On Tue, Aug 18, 2015 at 11:25 AM, Scott Granados
wrote:
> 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 anomalo
-- Forwarded message --
From: Tim Durack
Date: Tue, Aug 18, 2015 at 9:53 AM
Subject: Re: [c-nsp] Peering + Transit Circuits
To: Rolf Hanßen
Cc: "cisco-...@puck.nether.net"
On Tue, Aug 18, 2015 at 9:45 AM, "Rolf Hanßen" wrote:
> Hi,
>
> you forgot
On Tue, Aug 18, 2015 at 9:38 AM, Gert Doering wrote:
> Hi,
>
> On Tue, Aug 18, 2015 at 09:32:53AM -0400, Tim Durack wrote:
> > > (It would be cool if Cisco would understand that hardware forwarding
> > > platforms need useful netflow with MAC-addresses in there... ASR9k at
> [..]
> > At the risk
On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering wrote:
> Hi,
>
> (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 app
On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering 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
> On Aug 18, 2015, at 8:47 AM, Gert Doering wrote:
>
> XR doesn't do it at all,
> hrmph)
>
We have been asking about this as well, it might be worth revisiting.
- Jared
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-PeeringPolicyEnforce
36 matches
Mail list logo
