I much prefer using WDM transport as opposed to Ethernet\VPLS transport due to it being significantly harder (I try not to say impossible) to oversubscribe. That said, it isn't always available at a decent rate at a given location.
Cogent has a reputation (right or wrong) for running things a little hot.
Have any of you used Cogent Ethernet\VPLS services? What are you experiences? Offlist is fine if you don't want it public.
Never use them without a backup alternative. I've seen more outages, that one would want to ever see from a provider, that would like to be categorised as Tier1.
Especially, when some of these are longer than expected, because there were no cold-spares in the country and the cold-spare needed missed the flight.
/M
Tier 1 just means they don't pay for ip transit themselves, only Peering.
Doesn't mean that it's good transit.
Best provider i've ever used is hurricane electric, actually a tier 2
provider, but bigger/better than many tier 1s.
Tier 1 just means they don't pay for ip transit themselves, only Peering.
Doesn't mean that it's good transit.
Best provider i've ever used is hurricane electric, actually a tier 2
provider, but bigger/better than many tier 1s.
I'd still categorise Hurricane a lot better than Cogent.
Both quality and customer service wise.
/M
If only they had decent BGP community support.
While we're on the topic of BGP community support, I'd be interested in the greater group's favorites, pros, and cons of what you want to see in a BGP community support table/system from a provider. Taking notes for a customer..
James W. Breeden
Managing Partner
[logo_transparent_background]
Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media
PO Box 1063 | Smithville, TX 78957
Email: james@arenalgroup.co<mailto:james@arenalgroup.co> | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co<http://www.arenalgroup.co/>
you could also probably get some good examples cribbed from the collection:
https://onestep.net/communities/
I've seen the onestep list but the presentation is helpful. I guess my question was moreso to the people side of communities vs the technicalities of communities - what ones do people find themselves using most often and what do they wish was available from providers that really isn't otherwise out there?
James W. Breeden
Managing Partner
[logo_transparent_background]
Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media
PO Box 1063 | Smithville, TX 78957
Email: james@arenalgroup.co<mailto:james@arenalgroup.co> | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co<http://www.arenalgroup.co/>
BGP communities I use the most:
- Influence the transit provider BGP local-preference: customer preferred, customer backup, peer, and transit LP values
- Only advertise routes to the transit provider customers and not their peers
- Don't advertise routes to transit providers' peer ASx.
- AS-prepend X times to transit providers' peer ASx.
I've had a couple of situations where a CDN provider is sending all their traffic via one transit provider. A BGP community to not advertise or as-prepend our routes to that CDN provider would have been handy. Most transit providers only allow you to not advertise or as-prepend to their peers and not other customers.
The most useful to me:
Blackhole this prefix
Only advertise this prefix to your customers
Prepend my/your ASN to this prefix X number of times
Do not readvertise this prefix to any content caches you host
and I'd like to see more transits offer BFD.
+1 on BFD ...
Knowing the relationship between my provider and whomever they are learning the route from is handy. It allows me to do things such as filter on those communities for passing prefixes down into less capable hardware. I may elect to pass customer or customer and peering routes from a given provider down into routers throughout my network with limited FIB capability. They can decide which way to send traffic that should be immediately apparent where the best path is, while leaving the provider edge routers to decide for prefixes beyond that. Say a CCR or a switch with some layer 3 capabilities.
Then obviously things like blackhole and (local_pref, prepend, no export, etc. per AS).
The above I'd say is rather important. The next step would be location-aware stuff in the presentation that would be nice to have. If your provider is having an issue with an upstream or peer in a given city\region, being able to avoid that would be nice. Of course that assumes you figure out their problem and the work-around before they're able to fix it themselves. Well, assuming it's a short-term issue, anyway. If it's a constant issue, your provider isn't likely to fix it faster than you because they're not fixing it at all.
Hi,
We have a case when someone decided to create an AS\-SET of the same name as ours\.
It kinda messed up with our peering \(hopefully he got it worst\)\.
Management feedback was mostly "who do we sue?" and we know it isn't that simple\.
So,
Any feedback on best practices and "other avenue" about IRR naming?
PS: I have to understand that we're not in the 90's anymore and younglings just don't give a damn :\(Alain Hebert wrote:
Any feedback on best practices and "other avenue" about IRR naming?
Known problem - you're asking for trouble unless you filter IRRDB
queries by source:
There isn't a global namespace for as-set names, unless you use source:
as a database key element.
Nick
In addition to the above, one could use "hierarchical" AS-SET names, in
some databases (from the top of my head: APNIC, AfriNIC, RIPE) only the
owner of the ASN can create AS-SETs under that ASN's namespace. But more
importantly: using the ASN in the AS-SET name chances of collision are
reduced. Example: I defined "AS15562:AS-SNIJDERS" in the RIPE database,
instead of "AS-SNIJDERS". Same for "AS2914:AS-GLOBAL" in NTTCOM.
--- thread hijack ---
Coincidentally, I'm working to define something like "AS-SETs in RPKI".
There are a number of downsides to "AS-SETs in IRR": collisions between
databases can exist, it is hard to figure out what AS-SET to use for
what ASN (we rely on service order forms, peeringdb or guessing for
that), and the way the recursion was done can too easily result in
gigantic sets.
I'd be interested to know what others think about improving feature
parity between IRR and RPKI, and while doing that make the bad aspects
of AS-SETs go away and keep the good parts. Thoughts?
Kind regards,
Job
ps. raised the question here too https://mail.lacnic.net/pipermail/lacnog/2018-January/005845.html
I've found best practice to be use AS23456 to identify the owner.
(assuming you are 23456). Using something else like AS-CLOUD is likely
to cause conflicts as there are many clouds out there.
Much of the problem here is the limited namespace/concept space
and people get stuck saying IRR sucks when IRR/whois is often a method
to access a database. We have advanced quite far in the past 20 years
in how to build databases, realtime query methods, etc.. but it's not
made it to the routing ecosystem.
- Jared
--- thread hijack ---
Coincidentally, I'm working to define something like "AS-SETs in RPKI".
There are a number of downsides to "AS-SETs in IRR": collisions between
databases can exist, it is hard to figure out what AS-SET to use for
what ASN (we rely on service order forms, peeringdb or guessing for
that), and the way the recursion was done can too easily result in
gigantic sets.
Obviously you have to prune once you hit a loop, but this is
how you can traverse a edge-node graph to find the leaves given a starting
point.
I'd be interested to know what others think about improving feature
parity between IRR and RPKI, and while doing that make the bad aspects
of AS-SETs go away and keep the good parts. Thoughts?
I've found that saying RR, IRR and RPKI overloads one technology
with another. One needs a standards based method to access a database
about routing information. We can federate databases together or come
up with methods to do this. RPKI is another database you can validate
against but it also has limits.
If I were a backbone, I would be asking myself: How can customers
effectively communicate with me their intent? RPKI and IRR have weknesses
and the networks with automation and tooling here are light years ahead of
those that have nothing. We as an industry must get better so the impact
is less when bad things happen. It's clear to me a decade later even
asking people to filter out so called tier-1 networks with as-paths is
still a major problem.
6453 & 5511 are still accepting their peering partner ASNs
from customers (for example) and it shows. 701 still accepts peer ASNs
from peers. (example AS_PATHs in postscript)..
There's no universal way to communicate these relationships yet
we have web based platforms where I can tell you what many list members
ate for dinner last night. There is a lack of will to take action here
and a lack of common toolchains that can be integrated to perform the tasks.
- Jared
ps. raised the question here too https://mail.lacnic.net/pipermail/lacnog/2018-January/005845.html
A few interesting AS_Paths:
2497 701 5511 59378 7473 2914 132602 38203 137038
3356 6453 21502 1299 6848 44216
701 6453 21502 1299 6848 44216
> --- thread hijack ---
>
> Coincidentally, I'm working to define something like "AS-SETs in
> RPKI". There are a number of downsides to "AS-SETs in IRR":
> collisions between databases can exist, it is hard to figure out
> what AS-SET to use for what ASN (we rely on service order forms,
> peeringdb or guessing for that), and the way the recursion was done
> can too easily result in gigantic sets.Obviously you have to prune once you hit a loop, but this is how you
can traverse a edge-node graph to find the leaves given a starting
point.> I'd be interested to know what others think about improving feature
> parity between IRR and RPKI, and while doing that make the bad
> aspects of AS-SETs go away and keep the good parts. Thoughts?I've found that saying RR, IRR and RPKI overloads one technology
with another. One needs a standards based method to access a
database about routing information. We can federate databases
together or come up with methods to do this. RPKI is another
database you can validate against but it also has limits.
Yes, I'm moving away from "let us all use this one thing", and rather
explore how to integrate all the available data sources (IRR, WHOIS,
RPKI, our internal DB, and $the_next_thing) and create more choice for
customers. Addressing the various threats that one can model may be
resolved through local policy ("data type X from source A overrides data
type Y from source B", or merge, or prune actions, etc).
If I were a backbone, I would be asking myself: How can customers
effectively communicate with me their intent? RPKI and IRR have
weknesses and the networks with automation and tooling here are
light years ahead of those that have nothing. [ snip ]
Yeah, a real problem for ISPs is that it isn't clear wat AS-SET to use
for what neighbor.
- The discovery mechanism that RPSL was to provide is broken beyond
repair: import/export lines are unparsable.
- I know of route server config generators that query PeeringDB to fetch
the "IRR Record" as a starting point to generate filters, but that is
sometimes problematic because (a) we may be using the wrong IRR DB in
case of duplicate AS-SET names and (b) there is a lack of granularity
(you may not want to announce the same as-set to all route-servers).
- NTT simply asks customers/peers what as-set to use during the turn-up
process, but that as-set name may be deprecated by the peer over time,
and the mechanism to inform us is a bit archaic "email us".
What I think could be done with RPKI:
A mechanism that addresses the autodiscovery, and allows a degree of
granularity by allowing you to specify on a per-ASN basis what should be
used as the starting point to create a filter will make things better.
Toolchains (COTS, closed, and open source) would increase their chances
of finding the right starting point if they first try to query the RPKI
for information, and if that fails, fall back to either a database
record from a service order form or a query to PeeringDB. With "right" I
mean the most up to date and most likely intended one.
An 'AS-SET in RPKI' statement could also be published in IRR format (by
RIRs publishing it under a new "source:" name) to provide some backwards
compatibility. This helps address challenges in geographical regions
where the whole concept of "IRR" never took off, but RPKI is popular
(LATAM comes to mind).
There's no universal way to communicate these relationships yet we
have web based platforms where I can tell you what many list members
ate for dinner last night. There is a lack of will to take action
here and a lack of common toolchains that can be integrated to
perform the tasks.
Any platform under end-to-end control of a single entity will be able to
innovate and deliver at a much faster pace than something that'll need
to facilitate coordination across administrative domains 
A few interesting AS_Paths:
2497 701 5511 59378 7473 2914 132602 38203 137038
3356 6453 21502 1299 6848 44216
701 6453 21502 1299 6848 44216
I'll make some phone calls Monday.
Kind regards,
Job
The hierarchical as-set strategy has the problem that many fails to parse
it correctly. We use it at NL-IX with the result that their portal believe
we have no peers.
Alain Hebert wrote:
> Any feedback on best practices and "other avenue" about IRR naming?Known problem - you're asking for trouble unless you filter IRRDB
queries by source:There isn't a global namespace for as-set names, unless you use
source: as a database key element.
In addition to the above, one could use "hierarchical" AS-SET names, in
some databases (from the top of my head: APNIC, AfriNIC, RIPE) only the
owner of the ASN can create AS-SETs under that ASN's namespace. But more
importantly: using the ASN in the AS-SET name chances of collision are
reduced. Example: I defined "AS15562:AS-SNIJDERS" in the RIPE database,
instead of "AS-SNIJDERS". Same for "AS2914:AS-GLOBAL" in NTTCOM.
--- thread hijack ---
Coincidentally, I'm working to define something like "AS-SETs in RPKI".
There are a number of downsides to "AS-SETs in IRR": collisions between
databases can exist, it is hard to figure out what AS-SET to use for
what ASN (we rely on service order forms, peeringdb or guessing for
that), and the way the recursion was done can too easily result in
gigantic sets.
I'd be interested to know what others think about improving feature
parity between IRR and RPKI, and while doing that make the bad aspects
of AS-SETs go away and keep the good parts. Thoughts?
Kind regards,
Job
ps. raised the question here too https://mail.lacnic.net/
pipermail/lacnog/2018-January/005845.html