Ecoplast EOOD makes a local connectivity bill depend on upstream routes and field repair

Summary

• Ecoplast EOOD should be read first as a real but thinly documented network operator. RIPEstat's AS overview for AS25147 names the holder as SOFIANET Ecoplast EOOD and shows the AS announced at the July 10, 2026 query point, while the RIPE aut-num record gives the as-name SOFIANET, organization ORG-EA820-RIPE, assigned status and 2002 creation date.
• The public routing footprint is narrower and more precise than a simple "85.11.144.0/20" shorthand. RIPEstat's announced-prefixes view lists twelve visible /24s, and RIPEstat's routing status counts 3,072 IPv4 addresses, zero IPv6 /48s and two observed neighbours.
• The operating thesis needs an explicit downgrade. The public evidence supports an active Bulgarian AS with Sofianet-branded address space, valid route-origin checks, and transit visibility through Telehouse EAD and IPACCT CABLE Ltd, but it does not prove current retail service coverage, fixed-wireless assets, fibre route maps, backup power, local spares, repair crew depth or customer support performance.
• The risk for a subscriber or small-business buyer is therefore not that the network is invisible. The risk is that visibility is concentrated at the routing edge: if local access plant, customer-premises equipment, building power, a Sofia facility handoff or a field repair queue fails, public BGP may still look healthy while the paid connection is unusable.

Ecoplast EOOD is a case where the responsible article starts with restraint. The company name suggests nothing obvious about telecommunications, and the most discoverable public records do not resemble the polished service surfaces of a large regional broadband operator. The clearest trail is the routing trail. RIPEstat identifies AS25147 as SOFIANET Ecoplast EOOD, and the RIPE organization record for ORG-EA820-RIPE identifies Ecoplast EOOD in Bulgaria with registration number 831734815 and a Sofia address in Lagera. The public network brand in the route records is Sofianet. That is enough to treat the company as a network holder. It is not enough to treat every possible access-network feature as proven.

The current web front is the first warning. The domain sofianet.net answered during review, but it presented the default "Apache2 Ubuntu Default Page" rather than a service page with tariffs, coverage, contact channels, installation terms or support hours. Host.io's domain view independently shows the same title, the HTTP URL, IP address 85.11.144.35, AS25147 Ecoplast EOOD, an Apache/2.4.18 server, NS record ns1.sofianet.net and two co-hosted domains on that IP. That is useful evidence of a live domain tied to the ASN. It is weak evidence for a current customer operation. A functioning ISP can have a neglected website, but a neglected public web front means readers should not infer coverage, repair process or service quality from the domain alone.

That distinction matters because this article is about infrastructure, not brand nostalgia. A local ISP's public footprint can be smaller than its actual operating footprint. In some markets, the important work happens through phone calls, installers, building managers and upstream contracts rather than through a modern website. But public infrastructure analysis cannot fill those gaps with guesswork. If Ecoplast EOOD is providing access under the Sofianet name, the relevant questions are local and physical: which buildings or districts can be served, which access technology reaches them, which powered sites aggregate traffic, which upstream handoffs carry customer packets, how repair dispatch works, and how quickly customer-premises equipment can be replaced. The public record found here answers the upstream and address questions far better than the customer-facing ones.

The routing identity is strong. RIPE's aut-num record for AS25147 gives the as-name SOFIANET, status ASSIGNED, organization ORG-EA820-RIPE, and a creation timestamp of August 8, 2002. It lists import policy from AS31287, AS8717 and AS57344, and export policy to the same three ASNs. The record is maintained by RIPE-NCC-END-MNT, Ecoplast-MNT and IPACCT-MNT, and it names ORG-ICL63-RIPE, IPACCT CABLE Ltd, as sponsoring organization. Those are not marketing claims. They are routing-registry facts. They show a long-lived AS, an Ecoplast organization link, and declared relationships to Bulgarian and regional transit or interconnection networks.

The observed routing state is more selective than the registered policy. RIPEstat's AS routing consistency view shows AS31287 and AS57344 in both the RIPE policy and observed BGP, while AS8717 appears in policy but not in observed BGP at the July 10, 2026 query point. RIPEstat's ASN neighbours view counts two unique neighbours, AS31287 and AS57344. BGP.tools presents Ecoplast EOOD as a small network with two upstream carriers and lists Telehouse EAD and IPACCT CABLE Ltd. Hurricane Electric's BGP Toolkit also lists the two observed IPv4 peers as AS57344 Telehouse EAD and AS31287 IPACCT CABLE Ltd. The practical reading is clear: there are two visible upstream paths in public BGP, not a richly documented web of independent handoffs.

Two visible upstreams are better than one, but they are not the same as proven physical diversity. A routing table can show that AS25147 is reachable through Telehouse and IPACCT. It cannot show whether those services enter the same Sofia building, share a metro fibre route, depend on the same power feed, sit behind the same patch panel, or converge through the same upstream transport before reaching the wider internet. It also cannot show committed bandwidth, contract priority, change-control discipline or after-hours repair access. For a small access provider, the difference between two logical upstreams and two physically independent upstreams is the difference between graceful degradation and a shared outage.

The prefix evidence is exact enough to prevent another common overstatement. The assignment shorthand and some third-party summaries point to the 85.11.144.0/20 neighbourhood, but the currently visible BGP announcements are twelve separate /24s. RIPEstat's announced-prefixes endpoint lists 85.11.144.0/24, 85.11.145.0/24, 85.11.146.0/24, 85.11.147.0/24, 85.11.148.0/24, 85.11.149.0/24, 85.11.150.0/24, 85.11.151.0/24, 85.11.156.0/24, 85.11.157.0/24, 85.11.158.0/24 and 85.11.159.0/24. RIPEstat's routing status counts those as 3,072 IPv4 addresses, with no IPv6 /48s visible.

The older address records show why this nuance matters. RIPE's inetnum record covers 85.11.144.0 through 85.11.159.255, uses the netname BG-SOFIANET-1, describes a "Sofianet LTD assigment," marks the country as BG and records ASSIGNED PA status. RIPE's aggregate route object for 85.11.144.0/20 describes "Sofianet LTD" and "From Sofia Cable Company," with origin AS25147. But RIPEstat's consistency check says that aggregate /20 is in Whois and not in BGP, while the twelve /24s are in both. The correct conclusion is not that the whole /20 is currently being announced as a single operating block. The correct conclusion is that Ecoplast has Sofianet-linked address records across the /20 range, while the visible internet sees twelve more-specific /24 announcements.

Each of those /24 route objects points back to the same origin. RIPE route records for 85.11.144.0/24, 85.11.145.0/24, 85.11.146.0/24, 85.11.147.0/24, 85.11.148.0/24, 85.11.149.0/24, 85.11.150.0/24, 85.11.151.0/24, 85.11.156.0/24, 85.11.157.0/24, 85.11.158.0/24 and 85.11.159.0/24 describe Sofianet LTD and origin AS25147. Their 2021 creation timestamps show a deliberate more-specific route-object set, not just a stray legacy prefix. That makes the routed edge coherent.

Route-origin security is also better than the usual weak-footprint case. RIPEstat's RPKI checks for 85.11.144.0/24 and 85.11.156.0/24, along with the other visible /24s, returned valid status with ROAs for origin 25147 and max length 24 during review. Hurricane Electric likewise reports twelve RPKI originated valid IPv4 prefixes and zero invalid originated prefixes. That does not prove customer service quality or physical resilience, but it does show that the public origin-validation layer is not silent. For a small access network, valid ROAs reduce one category of route-leak and filtering risk.

The reverse-DNS record adds a different kind of clue. RIPEstat's reverse DNS view for 85.11.144.0/20 shows delegations from 144.11.85.in-addr.arpa through 159.11.85.in-addr.arpa, described as Sofianet.net from Sofia Cable Company and using ns1.sofianet.net and ns2.sofianet.net. That administrative footprint covers the four /24s from 85.11.152.0/24 through 85.11.155.0/24 that are not in the current RIPEstat announced-prefix list. Reverse DNS does not prove those four ranges are serving customers, and it does not prove the announced ranges are all retail broadband. It does show that the Sofianet naming and DNS administration cover the full older range, while public BGP visibility is narrower.

That difference between registered, administered, announced and usable capacity is central to this company. A /20 contains 4,096 IPv4 addresses. Twelve announced /24s contain 3,072. Neither number equals subscriber count. An access ISP can support more customers than public addresses through private addressing, carrier-grade NAT or dynamic pools. It can also support fewer visible customers if addresses are used for routers, management, business circuits, servers or idle inventory. The address math says Ecoplast's public footprint is small and Sofia-centered. It does not say how many customers pay a bill, what speeds they receive, or whether peak-hour demand is congested.

Third-party classification helps but has to stay in its lane. IPinfo's AS25147 page lists Ecoplast EOOD, Bulgaria, website sofianet.net, 3,072 IPv4 addresses, zero IPv6 addresses, ASN type ISP, RIPE registry, an August 8, 2002 allocation date and an October 6, 2020 update date. It also labels the network "Consumer ISP" in an activity section and reports a day-night rhythm, pingable IPs from Sofia and two peers, IPACCT CABLE and Telehouse EAD. These are valuable signals from a large IP intelligence provider. They cannot prove a current tariff book, customer contract base, support desk staffing or the location of every access node. They support the idea of an eyeball or access network, not a fully documented regional service platform.

PeeringDB creates a useful negative signal. A query for net records with ASN 25147 returned no entity during review. PeeringDB is voluntary; absence from it does not mean a network lacks peering, transit or professional contacts. But it does mean public readers cannot use PeeringDB to confirm a NOC email, interconnection facilities, traffic ratios, peering policy, internet exchange ports, or route-server participation. For a small local provider, that absence is common. For a buyer trying to evaluate resilience, it leaves more work to direct diligence.

The most important downgrade is physical. The article title tests a bill-to-network chain: a customer pays for connectivity, and that service depends on upstream routes and field repair. The upstream route evidence is visible. The field-repair evidence is not. No current public page found here describes Sofianet installation steps, supported neighbourhoods, service-level targets, outage notices, support hours, spare routers, field technicians, fibre repair contracts, tower sites, battery backup, customer-premises equipment policy or an emergency escalation path. That silence does not mean the company lacks those capabilities. It means a public reader cannot responsibly claim them.

For fixed-wireless, the downgrade is even sharper. The assigned asset class includes last-mile, fixed-wireless, fibre, broadband or regional connectivity networks, but the public evidence for AS25147 does not prove tower ownership, radio sectors, spectrum use or a wireless access plant. IPinfo's consumer-network signal and the Sofianet address space may fit a retail internet provider, but they do not identify the physical access technology. The article should therefore not describe tower failure as an Ecoplast-specific fact. A tower outage is a general local-ISP failure path only if wireless assets exist. On the evidence available here, the better-supported risks are upstream loss, facility concentration, power dependency, customer-premises equipment, address management and repair uncertainty.

The same discipline applies to fibre. The RIPE records include a Sofia Cable Company reference in the aggregate route object and reverse DNS delegations, and the company is tied to Sofia through the organization record and IP geolocation signals. That does not equal a public fibre map. It does not show ducts, poles, building entries, aerial drops, splice points, cabinets, optical transport, ring topology, protected paths or construction permits. A fibre-fed access network can be resilient if route diversity, power and spares are managed well. It can be fragile if many customers share one powered aggregation point or one duct. The public record tells us Ecoplast is routed. It does not tell us how the local plant is built.

This is why the failure path begins with the premise that BGP can stay up while local users stay down. If a building cable is cut, a customer router fails, a small switch loses power, or a fibre patch is damaged inside a local facility, the twelve /24s may still be visible from every RIPE RIS peer. RIPEstat's routing status can show 327 of 327 IPv4 RIS peers seeing the AS at the query time, and the affected customer can still have no usable service. Public routing visibility is a reachability measure for prefixes. It is not a service-level measurement for every apartment, office, shop or router behind those prefixes.

The second failure path is upstream loss. RIPEstat and Hurricane Electric both show two observed BGP neighbours, with Telehouse EAD and IPACCT CABLE Ltd carrying the current public story. If one upstream fails and the other remains available with enough capacity, customers may see little more than route changes or mild degradation. If the remaining path is congested, misconfigured or physically co-located with the failed path, the event can become a partial or full outage. The public record does not show route preferences, bandwidth commitments, physical handoff locations or transport separation. It supports a question, not an assurance: are Telehouse and IPACCT delivered through independent powered paths into the AS25147 edge?

The third failure path is facility power. A small network with a Sofia-centered footprint may depend on one or a few powered rooms, cabinets or rooftop nodes. The public records do not name those locations. They do not list UPS runtime, generator arrangements, temperature controls or remote-hands access. Power risk therefore has to be stated conditionally. If the customer-serving edge is concentrated, a local power problem can take down many users unless backup power is sized, tested and monitored. If the network has separated powered sites and tested failover, the risk is lower. Nothing in the public record settles that question.

The fourth failure path is address and routing hygiene. Here Ecoplast looks better than the weakest small-AS cases because its visible /24 origins validate under RPKI, and the route objects are coherent. But there is still operational exposure in running twelve more-specific IPv4 announcements with no visible IPv6. More-specifics can be useful for traffic control and reachability, yet they require careful filters, ROA maintenance and monitoring. No visible IPv6 also means customer experience may depend heavily on IPv4 pools, NAT state, DNS behavior and legacy troubleshooting. That can be perfectly serviceable for a small ISP, but it makes the support process more important.

The fifth failure path is communication. The web domain tied to the ASN is not acting as a modern customer portal. It does not provide a live status page, support instructions, a coverage checker or a maintenance calendar. During an incident, that matters. A national operator may disappoint customers despite a sophisticated site, and a local operator may repair faster with a phone-first culture. Still, a public status page or current service page gives customers and counterparties a way to distinguish an individual fault from a wider outage. The default Apache page at sofianet.net leaves that channel unused.

For residential customers, the practical question is simple: who answers when the connection fails, and what can they physically do? A household may not care whether AS25147 has two upstreams if the home router fails, if the building cable is damaged, or if an access switch lacks power. A small business may care about card terminals, delivery apps, cloud accounting and video calls. If a local technician can replace equipment quickly, a thin public web footprint might not matter to that customer. If the technician queue is short-staffed, the same customer can be down for longer than BGP data suggests. The public record does not reveal which version is true.

For a business or public-sector buyer, the questions should be more formal. Which addresses can Ecoplast serve today, and by which medium? Does the service enter a building through one path or diverse paths? Which upstreams carry normal customer traffic now? Are the Telehouse and IPACCT links physically separate? What happens if AS57344 is unavailable? What happens if AS31287 is unavailable? Which devices and sites have backup power, and for how long? What spares are held locally? What is the repair target for failed customer equipment, failed access electronics, fibre damage and upstream loss? Which support channel works after normal business hours? Those answers would decide whether the company can support critical use.

The capacity question also deserves a more careful public reading. RIPEstat's 3,072-address count is a visible internet-routing fact, not a bandwidth number. It says nothing about whether the customer-facing side uses Ethernet to buildings, fibre to a basement switch, coaxial plant, point-to-point wireless, private addressing, static public IPs, or a mix of business and residential services. A small ISP can have a modest public IPv4 pool and still run a capable local access network. It can also have an orderly BGP edge and still run into evening congestion if the access layer or upstream commit is narrow. The available records let readers count addresses and upstream ASNs. They do not let readers count customers, ports, optical line terminals, radios, cabinets or spare uplink headroom.

That is why "installed capacity" and "usable capacity" need to be separated. Installed capacity is the equipment and address space the operator can point to: an AS number, route objects, a public IPv4 pool, upstream sessions, local access electronics and customer drops. Usable capacity is what subscribers experience when everyone wants the network at once, when a route changes, when a cabinet is hot, when a local cable is damaged, or when a technician has to swap equipment in a building. Public BGP measures only a narrow slice of installed capacity. It is useful because the internet cannot reach a customer network if the prefixes disappear. It is incomplete because a visible prefix can hide a badly congested or partially broken local segment.

IPv6 is part of that same capacity story. The current public views from RIPEstat, BGP.tools, Hurricane Electric and IPinfo all show zero visible IPv6 for AS25147. That does not make the network unusable. Many small access networks still run customer access primarily on IPv4, and customers may not notice if NAT and DNS are maintained well. But IPv4-only visibility makes address management more operationally important. If a provider relies on NAT pools, shared addresses or careful dynamic assignment, support staff must be able to map customer complaints to the correct session and device. If the mapping is slow, customers experience not just a technical fault but a support bottleneck.

The absence of visible IPv6 also affects resilience during change. IPv6 deployment can be messy, but once implemented well it gives operators more routing options, cleaner address assignment and fewer shared-address troubleshooting disputes. A network with only visible IPv4 can still be stable, especially at small scale. Yet the public record gives no sign of an alternate customer-addressing layer that could absorb pressure if IPv4 policy, NAT state, abuse handling or route filtering becomes painful. For an ordinary household, this is abstract. For a business with remote access, payment systems or cloud allowlists, it can become immediate.

The upstream economics are similarly local. Telehouse EAD and IPACCT CABLE Ltd are not just names in a table; they are the paths through which a small AS reaches the wider internet. For a small provider, buying and maintaining upstream service is a balance between cost, traffic growth, reliability and bargaining power. One upstream may be cheaper, one may have better local reach, one may provide better international transit, and one may be more practical for support. The public data cannot reveal those terms. It can only show that the visible routing edge is small and depends on two observed neighbours. That gives a buyer a practical question: is the second path sized and tested as a backup, or is it only enough to keep routes visible?

There is a procurement trap here. A customer can hear "two upstreams" and imagine a carrier-grade failover design. A small operator can truthfully have two upstream BGP sessions and still face a shared metro-fibre cut, a shared power problem, a shared rack, or a human change error that affects both. Conversely, a small operator can build a surprisingly robust design if it has separated handoffs, clear filters, local monitoring and staff who understand the failure modes. Public BGP cannot tell which version is true. It should trigger the question, not answer it.

The two observed upstreams also make AS8717, A1BG, a cautionary footnote rather than a current operating pillar. AS8717 appears in the AS25147 policy record, but RIPEstat's consistency view did not see it in BGP at the query point. That could mean an old policy line, a backup relationship not visible at that moment, a filtered or inactive session, or a relationship that has changed without the policy being fully pruned. The article should not count AS8717 as active diversity merely because the text remains in the registry. Old routing policy can be a useful historical clue, but observed reachability carries more weight for current resilience.

The local access side is where the article remains weakest by necessity. A broadband customer experiences a provider through installation, indoor equipment, cabling, billing, support and repair. None of those layers is visible in the same way AS25147 is visible. The default web page gives no tariff evidence, no online order flow, no support phone number, no office address and no outage page. The RIPE organization record gives a Sofia address, but that is a registry address, not a customer counter or depot. IPinfo's consumer-ISP label suggests an access role, but it is not a service contract. The result is an analysis with a firm routing floor and a low operating ceiling.

For a Sofia apartment building, the practical uncertainty is mundane. A customer may have a cable from a basement room, a switch in a common area, a rooftop wireless handoff, a fibre drop, or another local arrangement. The public record does not identify which. If the building switch loses power, if a landlord locks a room, if a cable is cut in renovation work, or if a customer router fails, the route objects remain correct but the service can fail. The customer needs a repair path. Public data does not reveal whether Ecoplast or a contractor can reach the site quickly, whether spares are available, or whether access to shared building infrastructure is already arranged.

For a small retailer, the same gap becomes financial. A payment terminal, delivery platform, reservation system or cloud point-of-sale tool can be more sensitive to outage duration than a home streaming session. The retailer may not care which upstream carries packets on a normal day, but it will care if failover is slow, if the support channel is unclear, or if a local equipment replacement takes days. The strongest public Ecoplast evidence says the AS is reachable. It does not say whether a cashier can keep taking payments after a cabinet power problem or customer-premises equipment failure.

For a school, clinic or municipal office, the gap is larger again. Such users should not rely on a single local connection unless they understand repair escalation and have a secondary path. A mobile backup, a second wired carrier or another independent access method can be cheaper than discovering during an outage that the primary provider's two upstreams do not help with a local access cut. Ecoplast may be adequate for ordinary connectivity. The public evidence is not enough to justify it as the sole critical path for institutions that cannot tolerate prolonged downtime.

There is also a reputational dimension to the public web front. A default Apache page does not automatically indicate neglect of the network. Engineers sometimes prioritize routers and customers over websites. But a service provider's public web front is part of its resilience posture because it tells customers where to look when something is wrong. Even a simple static page with support hours, status notices and coverage disclaimers would reduce uncertainty. In the current public presentation, the best-maintained facts are in routing systems run by others. That leaves the company's own public communications weaker than the network records around it.

The old Sofianet and Sofia Cable Company wording in RIPE records should be treated as heritage, not as fresh marketing. The aggregate route object and reverse-DNS records preserve a long-running identity: Sofianet LTD, Sofia Cable Company, ns1.sofianet.net and ns2.sofianet.net. That supports the idea that this address space has been part of a Sofia internet service environment for many years. But old descriptions can survive long after business forms, assets and customer bases change. They are useful for continuity. They are not enough to prove present-day staffing or coverage.

The most generous interpretation is that Ecoplast EOOD runs a small, older, locally known network whose operations have not been translated into a modern public website. Under that interpretation, the Apache page is embarrassing but not decisive, and customers may still know how to reach the provider through offline channels. The least generous interpretation is that the active routing footprint outlived a robust public retail operation, leaving a network that is visible but poorly documented. The public evidence cannot choose between those interpretations. That is exactly why the evidence grade stays weak rather than medium.

The route-security posture slightly improves the risk picture. Valid RPKI does not repair a cut cable or answer a customer phone, but it shows that someone has maintained origin authorization for the visible /24s. For small networks, that work is often neglected. Here, the visible routes are not only registered but cryptographically aligned with AS25147 in the checks reviewed. That lowers the risk of accidental invalid filtering if route-origin validation is enforced by upstreams or peers. It is one of the stronger positive signals in the file.

Even that positive signal has a limit. A valid ROA says that AS25147 is authorized to originate a prefix up to a given max length. It does not say that the prefix has clean reverse DNS, low abuse rates, enough upstream capacity, or reachable customer support. Route-origin security is a governance layer. It belongs in a resilience assessment because routing mistakes can take a network off the internet. But it cannot substitute for the physical and human systems that keep access service usable.

The absence of a PeeringDB profile matters in the same limited way. PeeringDB would not prove local access quality, but it could expose public NOC contacts, facility presence, peering policy and interconnection preferences. Many small operators never maintain a profile, and there is nothing inherently wrong with that. But when the company website is not informative, the missing PeeringDB record removes another possible public window. A buyer or partner has fewer independent ways to confirm who operates the network, where it connects, and how to escalate a network issue.

The right diligence bundle for Ecoplast is therefore compact. Ask for a current customer-support contact and escalation path. Ask whether service is still sold under the Sofianet name and where. Ask for address-level coverage and access technology. Ask for the physical locations or at least the physical independence of the two upstream handoffs. Ask whether AS31287 and AS57344 can each carry all essential traffic during a failure. Ask whether AS8717 is still a live backup, an old policy record, or something else. Ask for backup-power practice at customer-serving nodes. Ask for average and worst-case repair times for access faults and customer-premises equipment replacement. Those answers would transform the evidence picture.

There is no need to overdramatize the risk. Small ISPs often survive because they know their local area and can solve building-level problems faster than larger carriers. A small Sofia provider may know the ducts, landlords, rooftops and repeat faults better than a national call center. Local knowledge can be a genuine infrastructure advantage. But local knowledge only helps if it is backed by reachable people, spares, documented access to sites and enough upstream capacity. The public records confirm the network edge; they do not confirm the local operating discipline.

The customer should therefore separate three decisions. First, is Ecoplast EOOD reachable as an internet network? Yes, the public routing evidence supports that. Second, is it plausibly an ISP or eyeball network rather than a random dormant AS? Yes, IPinfo, BGP.tools, Hurricane Electric and the Sofianet records support that reading, though with caveats. Third, is it documented well enough to trust as a single critical broadband provider? No, not from public evidence alone. That third answer is the heart of the downgrade.

The "regional ISP" category is therefore acceptable only as a broad taxonomy label, not as a proved region-wide service claim. The evidence supports a Bulgarian, Sofia-linked, long-lived AS with Sofianet-branded address space and public transit visibility. It does not support a precise map of regional coverage. It does not even prove the current retail operating setup from the company's own website. If the phrase "regional ISP" is used, it should mean "small access or eyeball network visible in a regional market," not "documented regional infrastructure platform with proven coverage and resilience."

There is still a positive story here. AS25147 is not an abandoned shell with no announcements. RIPEstat sees it as announced. Hurricane Electric sees twelve IPv4 originated and announced prefixes, all valid by RPKI, with 3,072 originated IPv4 addresses. BGP.tools shows two upstream carriers. IPinfo shows active ISP signals, pingable Sofia addresses and a consumer-network activity pattern. The RIPE organization record links the network to Ecoplast EOOD in Sofia, while the inetnum and reverse-DNS records preserve the Sofianet identity. Taken together, those records support the existence of a real, routed Bulgarian network.

The negative story is also clear. The customer-facing evidence is thin, the public site is not functioning as a service surface, PeeringDB has no located net record, IPv6 is not visible, fixed-wireless is unproved, and no public record documents access topology, backup power, route separation or field repair. That is a weak operating evidence grade even though the routing evidence is solid. In other words, Ecoplast EOOD looks stronger as an AS than as a documented last-mile service provider.

This distinction changes how readers should treat unofficial market signals. IPinfo's consumer-ISP label, hosted-domain count, pingable IPs and activity rhythm suggest that the address space is not merely theoretical. They make the retail or eyeball interpretation plausible. They do not settle subscriber scale, customer mix, or service quality. Host.io's view of sofianet.net on 85.11.144.35 confirms a live domain on the ASN, but the title points back to the default server page rather than a maintained service site. BGP.tools and Hurricane Electric corroborate route and upstream shape, but neither sees local repair queues. The signals are useful because they narrow the question. They cannot replace direct operating evidence.

If Ecoplast wanted to raise its evidence grade, the disclosure burden would be modest. It would not need to publish sensitive maps or detailed router configuration. A basic service page could identify coverage by district or address-check method, current support contacts, installation process, access technologies used, business-service availability, maintenance notice practice and general backup-power posture. A simple network-resilience note could state whether upstream handoffs are physically diverse, whether route-origin authorization is maintained for all announced prefixes, and how customers should report access faults. That would turn today's routing-first profile into a more balanced operating profile.

Until that exists, the prudent conclusion is a downgrade, not a dismissal. Ecoplast EOOD, trading in public routing records as SOFIANET, has a visible AS25147 footprint, a Sofia/Bulgaria identity, twelve live IPv4 /24 announcements, valid RPKI for the visible routes and observed upstream reachability through Telehouse EAD and IPACCT CABLE Ltd. The public record does not prove a current service map, fixed-wireless network, fibre topology, ring design, field-force capacity, spare inventory or backup-power standard. A local connectivity bill may indeed depend on Ecoplast's upstream routes and field repair. The routes are visible; the repair system is not.

That is the operating meaning of this slot. Treat AS25147 as a real routed network with a weak public operating file. For ordinary low-risk use, a customer might accept that if the price, local availability and personal support are good. For critical use, the unanswered questions are too important to ignore. The first due-diligence task is not to ask whether Ecoplast EOOD exists on the internet. It does. The task is to ask what happens when the local piece between a paying customer and those upstream routes breaks.