| IP Netzwerk - AS8315 |
| Adressbereich: |
AS8315 |
| Netzwerkname: |
ACNBB |
| Veranstaltungen: |
Anmeldungzuletzt geändert |
| Klassenname: |
autnum |
| Bemerkungen: |
| Nicht definiert: |
Accenture Backbone
https://www.accenture.com
==============================================================
Please find our peering details at
http://as8315.peeringdb.com/
We have an open peering policy and would like to peer with
you. Please send requests to noc@cie.ac.
NOC: noc@cie.ac
Abuse: dnsadmin@accenture.com
We share the view that for many networks ( including ours:-) )
only some abstraction of the actual routing policy should/can
be published in the IRR.
Right now we are abstracting to a very essential minimum.
the most important and helpful use of the IRR is
to publish what a network will announce to peers and upstream
we are providing that by means of the AS-set AS8315:AS-SENTIA
which we have been keeping up to date all the time
we encourage all our neighbors to define and maintain an
AS-set to describe their announcements, and to register
all the routes (and have their customers do so as well)
we maintain a list of what our neighbors have told us
about their announcements towards AS8315 - in terms of
AS-set (preferred), AS number, route-set
(and the IRR database used to publish)
in fact we apply route filters based on this
for all neighbors - as far as feasible
for data published through the RIPE routing registry
we generate filters automatically
we consider the integration of RIR and routing registry data
and the application of RPSS authorization a great feature
of the RIPE routing registry
unfortunately this benefit is not available with any
other IRR database that we know of...
and some of the IRR databases allow essentially any garbage
to be registered without any control - making those databases
quite useless...
customers are strongly encouraged to define and maintain
an AS-set that we will include in the definition
of AS8315:AS-ACNBB (if we are told the name)
this will be sufficient to have our peers accept the routes
in any case peers - and any network in the Internet -
is free to apply some selective policy (e.g. prefix
length based)
but we do not think that any such selective policy
will be based on details of our routing policy omitted
from this aut-num: object
unfortunately some customers do not provide usable IRR data;
we will NOT add to the uncontrolled garbage in the IRR by
proxy registering in some database that requires no
authorization
we advise customers that routes without IRR registration
and not covered by AS8315:AS-ACNBB may receive less than
full support by some of our peer networks and other
parts of the Internet
IPv6 we do/publish essentially the same like for IPv4
|
|
| Hinweise: |
| Gefiltert: |
This output has been filtered.
|
| Whois-Ungenauigkeitsberichte: |
This output has been filtered.
If you see inaccuracies in the results, please visit:
https://www.ripe.net/contact-form?topic=ripe_dbm&show_form=true ( Ungenauigkeits-Bericht ) |
| Quelle: |
This output has been filtered.
If you see inaccuracies in the results, please visit:
Objects returned came from source
RIPE
|
| Geschäftsbedingungen: |
This output has been filtered.
If you see inaccuracies in the results, please visit:
Objects returned came from source
RIPE
This is the RIPE Database query service. The objects are in RDAP format.
http://www.ripe.net/db/support/db-terms-conditions.pdf ( Nutzungsbedingungen ) |
|
| Status: |
Aktiv |
| Links: |
https://rdap.db.ripe.net/autnum/8315 ( Selbst )
http://www.ripe.net/data-tools/support/documentation/terms ( Copyright )
|
| Whois-Server: |
whois.ripe.net |
| Konformität: | nro_rdap_profile_asn_flat_0, cidr0, rdap_level_0, nro_rdap_profile_0, redacted |
IP
