| name | sapcc-networking |
| description | Neutron networking operations: network topology, port inspection, security group debugging, connectivity troubleshooting. Triggers: network, subnet, port, security group, firewall, connectivity, "can't reach", interface, IP address, CIDR.
|
| version | 1.0.0 |
| metadata | {"service":["neutron"]} |
SAP CC Networking (Neutron)
Investigate and debug network topology, port state, and security group rules in SAP Converged Cloud.
MCP Tools
Read Tools
| Tool | Purpose | Key Parameters |
|---|
neutron_list_networks | List networks | name, status |
neutron_list_subnets | List subnets (CIDR, gateway, DHCP) | network_id |
neutron_list_ports | List ports (MAC, fixed IPs, device_owner) | network_id, device_id, status |
neutron_list_security_groups | List security groups with rules | — |
neutron_list_routers | List routers and their external gateway info | — |
neutron_list_floating_ips | List floating IPs and their port associations | status, floating_ip_address |
neutron_list_trunks | List trunk ports and their subports | — |
neutron_list_network_ip_availabilities | IP usage statistics per network/subnet | network_id |
neutron_list_bgpvpn_interconnections | List BGPVPN interconnections | — |
Write Tools (requires MCP_READ_ONLY=false)
| Tool | Purpose | Key Parameters |
|---|
neutron_create_security_group_rule | Add an ingress/egress rule to a security group | security_group_id, direction, protocol, port_range_min, port_range_max |
neutron_delete_security_group_rule | Remove a security group rule | rule_id |
neutron_create_floating_ip | Allocate a floating IP from an external network | floating_network_id, port_id (optional) |
neutron_delete_floating_ip | Release a floating IP | floating_ip_id |
Admin Tools (requires MCP_ADMIN_TOOLS=true)
| Tool | Purpose | Key Parameters |
|---|
neutron_list_agents | List Neutron agents (DHCP, L3, OVS) and their state | — |
Gotchas
These are the most common mistakes. Follow them exactly.
-
Default security group blocks ALL inbound traffic. Users assume "default" means permissive. It is not. The default group allows all egress but zero ingress. Always check security group rules when debugging connectivity.
-
device_owner tells you what owns a port. Key values:
compute:nova — VM network interface
network:dhcp — DHCP agent port
network:router_interface — Router attachment
network:floatingip — Floating IP anchor
- Empty string — Unattached/orphaned port
-
To find a server's ports, use neutron_list_ports with device_id=<server_uuid>. Do not look for port information in Nova responses. Neutron is the source of truth for network interfaces.
-
Security group rules are additive (whitelist-only). There is no explicit deny. If traffic is not allowed by any rule, it is denied. You cannot "block port 22" — you can only not allow it.
-
Ports in DOWN status may be detached OR the VM is shut off. A DOWN port does not mean a problem — cross-reference with nova_get_server to check server power state. ACTIVE port + SHUTOFF server = normal (port state lags).
-
network_id is required to correlate subnets to networks. Subnets do not carry the network name. To map the full topology: list networks first, then list subnets filtered by each network_id.
-
Fixed IPs in port response contain both subnet_id and ip_address. To determine the CIDR range for a port's IP, use the subnet_id from the port's fixed_ips array to look up the subnet.
-
SAP CC networks are provider networks (not self-service). Users cannot create or delete networks. Network infrastructure is managed by platform operators. Users can only create ports, security groups, and floating IP associations.
-
Security group is applied per-port, not per-server. A server with multiple interfaces can have different security groups on each port. Always check the security_groups field on the specific port, not at the server level.
-
Remote group rules create circular dependencies. A security group rule referencing another group (remote_group_id) means "allow traffic from any port that has that group applied." This is how you allow intra-project communication without specifying IPs.
Common Workflows
"Why can't I reach my server?"
This is the most common networking question. Follow this sequence:
Step 1: Find the server's ports
→ neutron_list_ports(device_id=<server_uuid>)
→ Note the port status, fixed_ips, and security_groups
Step 2: Check security groups on those ports
→ neutron_list_security_groups()
→ Find the groups listed on the port
→ Verify inbound rules allow the protocol/port/source you need
Step 3: Verify subnet configuration
→ Use subnet_id from port's fixed_ips
→ neutron_list_subnets(network_id=<network_id>)
→ Check gateway_ip is set, DHCP is enabled if expected
Step 4: Verify network status
→ neutron_list_networks(name=<network_name>)
→ Confirm status is ACTIVE, admin_state_up is true
Common findings:
- Missing ingress rule (most common — see Gotcha #1)
- Wrong security group attached to port
- Port is DOWN because VM is SHUTOFF
- Subnet has no gateway (isolated network)
Find All Network Interfaces for a Server
neutron_list_ports(device_id=<server_uuid>)
Each result is one NIC. For each port, extract:
mac_address — correlates to OS-visible interface
fixed_ips[].ip_address — assigned IPs
fixed_ips[].subnet_id — which subnet it belongs to
network_id — which network it connects to
security_groups — applied firewall rules
status — ACTIVE, DOWN, BUILD
Audit Security Group Rules for a Project
Step 1: List all security groups
→ neutron_list_security_groups()
Step 2: For each group, examine rules
→ Look at security_group_rules array in response
→ Flag overly permissive rules (see Security Considerations)
Step 3: Cross-reference with ports
→ neutron_list_ports() to see which groups are actually in use
→ Groups not referenced by any port may be stale
Map Network Topology
Build the full picture: network → subnets → ports → servers.
Step 1: List all networks
→ neutron_list_networks()
Step 2: For each network, list subnets
→ neutron_list_subnets(network_id=<id>)
→ Record CIDR, gateway, allocation_pools
Step 3: For each network, list ports
→ neutron_list_ports(network_id=<id>)
→ Group by device_owner to separate VMs from infrastructure
Step 4: Correlate ports to servers
→ Ports with device_owner="compute:nova" have device_id=server_uuid
→ Use nova_get_server(<device_id>) to get server name/status
Troubleshooting
Port ACTIVE but No Connectivity
- Security group missing required ingress rule (check Gotcha #1)
- Source IP not in allowed CIDR of the security group rule
- Subnet has no gateway — network is intentionally isolated
- MTU mismatch (rare, but check subnet MTU if large packets fail)
- Anti-spoofing: traffic from IP not in port's
allowed_address_pairs or fixed_ips is dropped
Security Group Not Taking Effect
- Wrong group attached — compare port's
security_groups list to the group you edited
- Rule direction wrong —
ingress is traffic TO the port, egress is FROM the port
- Ethertype mismatch — IPv4 rule won't match IPv6 traffic and vice versa
- Protocol/port mismatch — rule says TCP but traffic is UDP, or port range excludes your port
- Remote IP prefix too restrictive — source CIDR doesn't include the connecting client
IP Conflict / Duplicate Address
- Check if multiple ports have the same
fixed_ips[].ip_address on the same subnet
- Look for ports with
device_owner="" (orphaned) holding the IP
- Check
allowed_address_pairs — another port may legitimately share the IP (VRRP/HA)
Security Considerations
Overly Permissive Rules (Flag These)
| Pattern | Risk | Recommendation |
|---|
remote_ip_prefix: 0.0.0.0/0 on SSH (22) | Internet-exposed SSH | Restrict to bastion/VPN CIDR |
remote_ip_prefix: 0.0.0.0/0 on all ports | Fully open | Almost never correct — audit immediately |
protocol: null (all protocols allowed) | No protocol restriction | Specify TCP/UDP/ICMP explicitly |
Egress 0.0.0.0/0 to all ports | Unrestricted outbound | Acceptable for most workloads, flag for PCI |
Before Modifying Security Groups
- Identify all ports using the group:
neutron_list_ports() and filter by security_groups containing the group ID
- Understand the blast radius — one group change affects all attached ports
- Check if it's the "default" group — almost every port uses it
- Prefer adding a new group over modifying a shared one
Cross-Service References
| Need | Service | Tool |
|---|
| Server name/status for a port's device_id | Nova | nova_get_server |
| Who modified a security group? | Hermes | hermes_list_events(target_type=security_group) |
| Network quota remaining | Limes | limes_get_project_quota (service: networking) |
| DNS records for an IP | Designate | Not yet in MCP server |
Reference Files
references/security-group-patterns.md — Common SAP CC security group configurations and templates
Routing