UE Route Management

Related Documentation:

• API Documentation - Complete API reference including route management endpoints
• Operations Guide - Web UI operations and monitoring

Overview

The UPF (User Plane Function) integrates with FRR (Free Range Routing) to dynamically manage User Equipment (UE) IP routes. This integration ensures that as UE sessions are established or terminated, the routing infrastructure automatically adapts to reflect the current network topology.

What is FRR?

FRR (Free Range Routing) is a robust, open-source routing protocol suite for Linux and Unix platforms. It implements various routing protocols including BGP, OSPF, RIP, and others. In our deployment, FRR acts as the routing daemon that maintains the kernel routing table and can redistribute routes to other network elements.

Architecture

How Route Synchronization Works

Route Lifecycle

Automatic Synchronization

The UPF maintains an internal registry of all active UE IP addresses. When enabled, the route synchronization system:

1. Monitors UE Sessions: Tracks all active PFCP sessions and their associated UE IP addresses
2. Maintains Route List: Keeps an up-to-date list of routes that need to be in the routing table
3. Syncs to FRR: Automatically pushes route updates to the FRR daemon via its API
4. Handles Failures: Tracks sync status (synced/failed) for each route and retries as needed

FRR Setup

Configuration

FRR is deployed and configured using Ansible templates to establish the base routing parameters. You define the FRR configuration once as a Jinja2 template in your Ansible playbook, and Ansible automatically propagates it to all your UPF instances during deployment.

A typical FRR Jinja2 configuration template includes:

frr version 7.2.1
frr defaults traditional
hostname pgw02
log syslog informational
service integrated-vtysh-config
!
ip route {{ hostvars[inventory_hostname]['ansible_default_ipv4']['gateway'] }}/32 {{ ansible_default_ipv4['interface'] }}
!
interface {{ ansible_default_ipv4['interface'] }}
 ip address ospf router-id {{hostvars[inventory_hostname]['ansible_host']}}
 ip ospf authentication null
!
router ospf
 ospf router-id {{hostvars[inventory_hostname]['ansible_host']}}
 redistribute static
 network {{ hostvars[inventory_hostname]['ansible_default_ipv4']['network'] }}/{{ mask_cidr }} area 0
 area 0 authentication message-digest
!
line vty
!
end

Deployment Model:

1. Define Once: Create the FRR Jinja2 template in your Ansible role (e.g., roles/frr/templates/frr.conf.j2)
2. Configure Parameters: Set variables in your Ansible inventory for each UPF host
3. Deploy Everywhere: Run the Ansible playbook to deploy FRR configuration to all UPF nodes
4. Automatic Customization: Ansible uses host-specific variables (IP addresses, router IDs, etc.) to customize each UPF's FRR configuration

Customizable Parameters in the Jinja2 template:

• OSPF parameters: Router ID, area configuration, authentication methods, network advertisements
• BGP configuration: ASN, neighbor relationships, route policies, communities
• Route redistribution: Which routes to redistribute (e.g., redistribute static for UE routes)
• Route filtering: Route maps, prefix lists, access lists
• Interface settings: OSPF/BGP interface parameters

UPF Integration: Once the base FRR configuration is deployed to each UPF instance, the UPF dynamically adds UE IP addresses as host routes (/32 for IPv4, /128 for IPv6) via the FRR vtysh interface based on active PFCP sessions. These routes are then:

1. Added as FRR static routes by the UPF route sync engine (via vtysh)
2. Picked up by FRR via the redistribute static directive
3. Advertised to routing protocols (OSPF, BGP) according to your FRR configuration
4. Propagated to the network so that UE traffic can be routed to this UPF instance

Important: The UPF adds routes through FRR's vtysh interface, making them FRR static routes (not kernel routes). You must use redistribute static in your OSPF/BGP configuration, not redistribute kernel.

Key Points:

• Set Once, Deploy Everywhere: Define the FRR Jinja2 template once in Ansible, and it's automatically deployed to all UPF instances
• Ansible handles static config: The Jinja2 template sets up all routing protocol parameters (OSPF areas, BGP neighbors, authentication, route policies, etc.)
• UPF handles dynamic routes: Each UPF instance dynamically manages only the UE IP /32 routes based on its active PFCP sessions
• Automatic route advertisement: FRR on each UPF automatically redistributes the local UE routes according to your configured policies
• Centralized management: Update the Ansible template and re-run the playbook to change routing configuration across all UPFs simultaneously

Route Advertisement

Monitoring and Management

Web UI Integration

The UPF Control Panel provides a Routes page that displays:

• Route Status: Whether route synchronization is enabled or disabled
• Total Routes: Number of UE IP addresses being tracked
• Sync Statistics: Count of successfully synced routes and any failures
• Active Routes: Real-time list of all UE IP addresses currently in the routing table
• OSPF Neighbors: Live status of OSPF adjacencies with neighbor details
• BGP Peers: BGP session status and prefix statistics (when configured)
• OSPF Redistributed Routes: Complete view of external LSAs showing how UE routes are advertised

The Routes page provides comprehensive visibility into UE route synchronization, routing protocol neighbors, and redistributed route advertisements.

Manual Sync Operation

Administrators can trigger a manual route synchronization through the web UI using the Sync Routes button. This operation:

1. Re-reads the current list of active UE sessions from the UPF
2. Compares with FRR's routing table
3. Adds any missing routes
4. Removes any stale routes
5. Returns updated sync statistics

Route Flow

Benefits

• Zero Touch Provisioning: Routes are automatically managed without manual intervention
• Dynamic Adaptation: Network routing adapts in real-time to UE mobility and session changes
• Scalability: Supports thousands of concurrent UE routes
• Resilience: Failed sync operations are tracked and can be retried
• Visibility: Full visibility into route status through the web UI

Technical Details

API Endpoints

The UPF exposes the following route management endpoints:

• GET /api/v1/routes - List all tracked UE routes without syncing
• POST /api/v1/routes/sync - Sync routes to FRR and return updated list
• GET /api/v1/route_stats - Get detailed routing statistics
• GET /api/v1/routing/sessions - Get routing protocol sessions (OSPF neighbors, BGP peers)
• GET /api/v1/ospf/database/external - Get OSPF AS-External LSA database (redistributed routes)

See Also: API Documentation - Route Management for complete endpoint details and examples

Route Format

Routes are stored and managed as simple IP addresses (e.g., 100.64.18.5). The routing daemon handles the full route entry details including:

• Destination prefix/mask
• Gateway/next-hop
• Interface binding
• Metric and administrative distance

IPv6 Support

The route manager supports both IPv4 and IPv6 UE addresses:

Address Type	Prefix Length	Example
IPv4	/32	100.64.18.5/32
IPv6	/128	2001:db8::1/128

For IPv6, ensure your FRR configuration includes the appropriate OSPFv3 or BGP IPv6 redistribution:

router ospf6
 redistribute static

or for BGP:

router bgp <asn>
 address-family ipv6 unicast
  redistribute static

FRR Verification

OSPF External LSA Database

You can verify that UE routes are being properly redistributed into OSPF by examining the FRR OSPF Link State Database. External LSAs (Type 5) show routes that have been injected into OSPF from external sources.

FRR OSPF database showing external LSAs including UE route 100.64.18.5/32 being advertised as an E2 (External Type 2) route.

In the example above, you can see:

• Network LSA (10.98.0.20): The UPF's own network advertisement
• Router LSA (192.168.1.1): OSPF router advertisement
• External LSAs: Including the UE route 100.64.18.5 redistributed into OSPF with metric type E2 (External Type 2)

This verification confirms that:

1. The UPF is successfully tracking the UE IP address
2. The route sync engine has pushed the route to FRR
3. FRR has redistributed the route into OSPF
4. OSPF neighbors are receiving the route advertisements