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.
We have been asking about this as well, it might be worth revisiting.
- Jared
Hi,
> 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.
At the risk of introducing religion, I will mention sFlow...
I ask Cisco for sFlow support on a regular basis. Cisco typically respond
with some variation of NIH syndrome. Anyway, back to my question 
Yup, valid option. I am trying to avoid anything that involves maintaining
lists.
Can I ask why you terminate peering and transit on different routers? (Not
suggesting that is bad, just trying to understand the reason.)
Tim:>
If you have a small number of peers, a separate router carrying a
partial table works really well.
To expand on this, and answer Tim’s question one post up in the thread:
Putting all peer routes on a dedicated router with a partial table avoids the “steal transit” question. The Peering router can only speak to peers and your own network. Anyone dumping traffic on it will get !N (unless they are going to a peer, which is a pretty minimal risk).
It has lots of other useful features such as network management and monitoring. It lets you do maintenance much easier. Etc., etc.
But mostly, it lets you avoid joining an IX and having people use you as a backup transit provider.
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 nightmare.
If you're concerned about transit / peering theft on a shared l2 ixp style
fabric, you're far better to use bilateral-only peering with ingress l2
filters at the ixp interface to include or exclude other participants as
required. This will stop the problem dead in the water with no side effects.
Nick
it doesn't: you detect it and depeer them. If they force the situation
with static routes, the traffic will be dropped.
Nick
Hi Nick,
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 can't route it.
URPF is the opposite of that. I'll only accept packets from you with a
_source_ address which is included in the routes you sent to me.
Regards,
Bill Herrin
Why do I read this thread as “Peering + Transit Circus”
manning
bmanning@karoshi.com
PO Box 6151
Playa del Rey, CA 90296
310.322.8102
Let me start backwards...
To me 'peering' is sharing internal routes and downstream customer routes,and not external ones.
IP transit is all of the external routes including internal routes & downstream customer routes
Having said that..... if one is control of what IP Prefixes get advertised to whom... how exactly someone (peers) 'steal' transit ?
(If one is not managing the filters well then yes it is possible, but that would be a configuration error ?)
Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships)
Based on above belief...
Then Item # 3, becomes the choice of the OP.... where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like.
Items # 1 & 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed 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
It's actually quite easy.
Provider1 is present at Exchange1 and Exchange2, so is Provider2. Provider2
doesn't want to pay for the traffic between Exchange1 and Exchange2, so it
points a static route for all prefixes it has in Exchange2 via Provider1's
IP address in Exchange1 and does the same in Exchange2. Provider1's router
receives traffic, checks where it should go (Exchange2) and it forwards the
traffic. So the traffic flows like this:
Provider2 (Exchange1) -> Provider1 -> (Exchange2) Provider2, all due to
static routes.
kind regards
Pshem
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 transit is not practical
giving the limitation that you need to use a source address from our ranges.
I use ACLs on our end too just to be sure. ACL on the transit to prevent
wrong source from leaving our network and ACL on the peering to prevent
wrong destination to enter the network. Actually both ACLs are used in both
places.
The prefix lists used for the ACL need to be maintained in any case. It is
the list of routes that we advertise.
Regards,
Baldur
Assume you and I are at an IX and peer. Suppose I send you traffic for Comcast. I can do this, even if you do not send me prefixes for Comcast. It requires me to manually configure things, but I can do it.
Put another way, you said "We will trust everything coming in”. I am saying that perhaps you should not.
As Comcast is not one of your customers, you will have to send the packets out your transit provider. You do not get paid when I give you the packets, and you probably pay your transit provider to get to Comcast. So I have gotten something for free, and you are paying for it - i.e. stealing.
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, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc.
There are evil ways around this if you do not configure your router properly (e.g. send you a prefix for Comcast with next-hop set to inside your network). But standard network hygiene will stop those.
And as has been stated, this doesn’t have anything to do with URPF either. (Not sure why Nick brought that up, he’s smart enough to know what URPF is and runs an exchange himself, so I think he just brain-farted. Happens to us all.)
Hope that made it more clear.
Thank you for the explanation..
However wouldn't a few other other attributes of the traffic show up .
e.g. you would have asymmetric traffic.. going out via us, but coming back via a totally another path ?
BTW, my comment "We will trust everything coming in" was in ref. to QOS tags.
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,
your peering router will drop it and send an ICMP Network Unreachable.
In this scenario, the peering router is feeding routes to a Route Reflector ?
and not taking in full routes from the route reflector ?
But standard network hygiene will stop those.
If there are any resources you could point to 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: Support@Snappytelecom.net
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).
Regards
Faisal Imtiaz
Snappy Internet & Telecom