Our Internet identity

Three hosts, many roles

The names lsn-core, segw and ims-edge describe three parts of the platform I have brought together.

lsn-core: the foundation

Our core host joins Internet routing, mobile control, gateway functions, subscriber services, provisioning and monitoring. BIRD handles external routing. Customer tunnel services run in a separate virtual machine, giving that service its own operating environment within the wider platform.

segw: the radio boundary

The security gateway accepts protected connections from radio sites. It terminates IPsec tunnels and passes permitted mobile traffic towards the core. This is the bridge between a site using ordinary backhaul and the private functions that manage a mobile connection.

ims-edge: calls and messages

Our IMS host runs call session control, a fixed SIP registrar, FreeSWITCH applications, RTPengine and messaging workers. These services manage registration, call routing, voicemail and media. SIP messages arrange a call; the audio takes its own packet path through the media system.

Joining the pieces

A private service network connects the hosts. Routes and access controls decide which functions can communicate. Some jobs share a machine, while a single customer service can depend on several hosts. Understanding those dependencies helps me plan the extra servers and cores that will support our next stage of growth.

Our ASN: AS218388

Our Autonomous System Number gives Lodestar an identity that other networks recognise when exchanging Internet routes.

Our place on the Internet

The Internet is made from independently operated networks. Each has its own routing policy. AS218388 is registered as LODESTAR in RIPE and identifies our routing domain. BGP, or Border Gateway Protocol, tells neighbouring networks which address ranges they can reach through us.

Our upstream connection

We use BIRD to exchange IPv4 and IPv6 routes with CILIX, AS215638. Each session receives a default route and announces the matching Lodestar aggregate. Other networks can then find our public addresses. For me, operating our own ASN is a major milestone: it brings responsibility for routing policy and creates a foundation for future interconnection.

Our public IP ranges

Our public prefixes give Lodestar a presence on the Internet and room to organise different services.

IPv4: 87.83.68.0/24

This range covers 87.83.68.0 through 87.83.68.255: 256 numerical addresses used across infrastructure and services. Each current tunnel subscription includes one static public IPv4. The plans are IPv4 only, without a routed subnet or customer BGP.

IPv6: 2a14:f705:c879::/48

Our IPv6 prefix is registered as LODESTAR. A /48 contains 65,536 possible /64 subnets, giving us space to organise the network as it grows. Our Internet edge supports IPv6, while the tunnel product concentrates on IPv4. Public addressing provides Internet reachability; private addressing organises internal links and service paths. Routing and translation connect those spaces where needed.

How routes reach the Internet

Routes tell packets where to go next. Our policy connects Lodestar services to the wider Internet.

Outward and return journeys

Our upstream supplies a default route for each address family, handling destinations without a more specific entry. In return, we announce our exact IPv4 /24 and IPv6 /48 aggregates. Those announcements tell other networks how to reach our public addresses.

Keeping the policy clear

Traffic sourced from Lodestar public space uses the transit table, while management traffic has its own default path. More specific routes deliver local services and tunnel addresses. Our route-origin authorisations identify AS218388 for these prefixes, with maximum lengths /24 and /48. We publish an open peering policy as a basis for future direct interconnection.