SSG as a Border Router. ARP management

August 8, 2024

Stingray SG Functionality

By default, the SSG functions as an L2 Bridge, but since 2017 it has been developed as a full-fledged BRAS/BNG. Routing functionality is particularly important for a service gateway, as it is required to communicate with external networks, provide access to internal resources and improve resilience. The VAS Experts team provided the opportunity to embed proven solutions in the role of Soft-Router such as BIRD, FRRouting and QUAGGA into SSG.

Routing in SSG

Routing in SSG is performed by exchanging routes between SSG and Soft-Router using Linux kernel route table. You can learn more about it in our knowledge base.

The main features of SSG as a router include:

Support for BGP and OSPF routing protocols.
VRF Lite implementation where the SSG shares routing tables but does not create unique tunnels for each VRF’s traffic (e.g. MPLS, VXLAN). VRF Lite allows isolation of the services provided and optimisation of routing when using different links.
Equal Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) support.

With the release of version 13.1, the SSG can be used as a Border Router.

Routing optimization in SSG with ARP manager

Let’s consider a typical scheme of a telecom operator’s network construction, where SSG acts as a DPI/NAT/BRAS/Border Router. The SSG terminates the subscriber L2-segment for IPoE/PPPPoE connections on the input interfaces side. Out interfaces are included in the switch to which the Uplink and internal routers are connected.

Since the SSG does not internally switch between pairs of physical interfaces, connections to multiple routers must be made through the switch.

In this scheme, SSG receives the BGP Full View from the upstream operator (BGP Router) and is connected via OSPF to the router (OSPF Router), behind which the local services of the telecom operator are located.

It is worth noting that SSG stores the routing table in RAM, which can be easily expanded. If necessary, it can receive and process multiple BGP Full Views. This capability is actively used by providers since they were unable to implement it on other routers.

A feature of this scheme is that the BGP Router advertises not itself as the nexthop, but other routers such as Router 1 or Router 2. In this way, the upstream provider implements uplink channel redundancy and additionally centralizes route advertisement management for the downstream provider.

Before version 13.1, SSG could not independently send an ARP request to obtain the MAC addresses of Router 1 and Router 2, which prevented it from forming a packet towards the nexthop. Previously, SSG filled its ARP table by analyzing ARP requests from the network namespace and responses to these requests. However, in this scenario, the Linux network stack does not generate ARP requests to Router 1 and Router 2, as there is no need. To solve this issue, an ARP manager was added to SSG. Now, SSG can generate ARP requests to the necessary IP addresses. When generating an ARP request, SSG uses the address specified in the parameter bras_arp_ip as the src IP.

You can read more about the ARP manager in our knowledge base.

Conclusion

We will continue working on improving the ARP manager. In the near future, we plan to add the ability to generate ARP requests with different source IP addresses, in addition to the address specified in the bras_arp_ip parameter. This will allow multiple BGP sessions with different providers to be established.

Vote:

5 out of 5

Average rating : 5

Rated by: 2