Networking Basics

0. nslookup
Great question — it's common to confuse ping and nslookup since both involve hostnames
and IPs. Here's a simple comparison:

✅ nslookup

 📌 Purpose: Checks DNS resolution only.

 🔍 What it does: Queries DNS to find the IP address of a hostname.

 ✅ Example:

 nslookup [Link]

 → Returns: [Link]

 ❌ No check if the target is reachable or online.

✅ ping

 📌 Purpose: Tests network reachability of a host.

 🔍 What it does:

1. Resolves the hostname to IP (like DNS),

2. Sends ICMP echo requests (like a "hello, are you there?")

3. Measures response time.

 ✅ Example:

 ping [Link]

 → Replies from [Link] with time values

 ❌ Might fail even if DNS is fine, if ICMP is blocked or host is down.

🧠 Summary Table:

Feature nslookup ping

Resolves DNS ✅ Yes ✅ Yes

Feature nslookup ping

Checks Reachability ❌ No ✅ Yes

Uses ICMP ❌ No ✅ Yes

Useful For DNS troubleshooting Connectivity testing

1. Niping
is  Test network connectivity between SAP components (e.g., SAP application server ↔
SAProuter or SAP GUI ↔ app server)

 Check latency, bandwidth, and data integrity

 Diagnose network issues like timeouts or dropped connections.

niping -c -H <target_host> -S <port>

niping output examples and how to interpret them — whether the network is fast or latent.

✅ Client-Side Command Example:

niping -c -H [Link] -S 3299

🟢 Sample Output – Good Network (Fast & Stable):

pgsql

CopyEdit

NiPing: info: Successful connection to [Link]

NiPing: info: Round trip time 1: 6.34 ms

NiPing: info: Round trip time 2: 6.25 ms

NiPing: info: Round trip time 3: 6.48 ms

NiPing: info: Round trip time 4: 6.29 ms

NiPing: info: Round trip time 5: 6.35 ms

NiPing: info: Mean round trip time: 6.34 ms

NiPing: info: No errors detected.

🟢 Interpretation:

 RTT ~6 ms: Very fast local/nearby connection

 Stable results = healthy connection

 ✅ No packet loss or errors → network is good for SAP traffic.

🟡 Sample Output – Latent Network (Slow/Remote):

pgsql

CopyEdit

NiPing: info: Successful connection to [Link]

NiPing: info: Round trip time 1: 182.47 ms

NiPing: info: Round trip time 2: 179.89 ms

NiPing: info: Round trip time 3: 183.01 ms

NiPing: info: Round trip time 4: 180.56 ms

NiPing: info: Round trip time 5: 181.76 ms

NiPing: info: Mean round trip time: 181.54 ms

NiPing: info: No errors detected.

🟡 Interpretation:

 RTT ~180 ms: Possibly cross-region or poor WAN link

 Stable but high latency → may cause slow response in SAP GUI

 Still no errors = acceptable but not ideal for high-speed operations

🔴 Sample Output – Problematic Network:

vbnet

CopyEdit

NiPing: error: Connection to [Link] failed (NiRawConnect failed)

NiPing: error: rc = -6

🔴 Interpretation:
  Connection failed: Server unreachable or port blocked

 Possible firewall/SAProuter issue

2. Iperf:
iPerf Supports Parallel Streams(is a single TCP or UDP connection between the client and
server used to send and receive data.)

 iPerf can simulate multiple simultaneous connections (like real-world usage: web, file
transfers, apps).

iperf3 -c [Link] -P 10

-c = client mode

-P 10 = 10 parallel streams

iPerf will report aggregate bandwidth of all 10 streams

Output:

[SUM] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec sender

[SUM] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec receiver

🔹 iPerf uses all available bandwidth across connections.

iperf3 -c [Link] -P 5

It means:

iPerf will create 5 separate TCP connections (aka 5 "streams") from the client to the server.

These streams run in parallel to send data.

The total bandwidth reported will be the sum of all streams.

 nyping sends packets one at a time, like ping but with throughput data.
  Tests only one TCP connection, so it doesn’t simulate real-world load.

🔍 Example:

nyping -c [Link]

 Returns speed of one TCP stream, which may be limited by:

o Latency

o Congestion control

o OS socket buffer sizes

➡ You may get:

makefile

CopyEdit

Bandwidth: 130 Mbps

Even if your network supports 1 Gbps, the single connection might not saturate it due to TCP
limitations.

📈 Example:

If you have a 1 Gbps LAN:

bash
CopyEdit
iperf3 -c [Link] -P 10

This might report something like:

[SUM] 0.00-10.00 sec 1.15 GBytes 987 Mbits/sec sender

🔸 That's nearly saturating your full 1 Gbps link — which means you're testing the
network's true capacity.

🔍 Test Setup (Example Scenario)

 Network: 1 Gbps LAN

 Tool: iPerf3
 Server IP: [Link]
 Client issues test for 10 seconds

📊 Results Comparison
Streams (-P) Command Observed Throughput (Mbit/sec)
1 iperf3 -c [Link] -P 1 ~310 Mbit/sec
2 iperf3 -c [Link] -P 2 ~590 Mbit/sec
5 iperf3 -c [Link] -P 5 ~920 Mbit/sec
10 iperf3 -c [Link] -P 10 ~940 Mbit/sec

📈 Why This Happens

 Single stream is limited by:

o TCP window size
o Latency (even on LAN)
o OS network stack tuning
 Multiple streams bypass these by using multiple sockets and threads → more
efficient pipe usage

✅ Conclusion:

 Even on fast networks, using multiple parallel streams is key to reaching full
bandwidth.
 With a single stream, you'll rarely reach full throughput.
 So, when testing or benchmarking, always use -P 5 or higher for accurate
measurements.:

3. Test-NetConnection:
The Test-NetConnection command is a PowerShell cmdlet used to
test network connectivity, including checking if a remote host is
reachable and whether specific ports are open. Output Includes:
 Ping status
 TCP port status
 IP address resolution
 Interface used
 Network latency (if applicable)
✅ Common Uses of Test-NetConnection:
 Use Case Command Example What It Does
Checks if the host [Link]
Ping a host Test-NetConnection [Link]
is reachable via ping
Test-NetConnection [Link] Checks if port 443 (HTTPS) is
Test specific port -Port 443 open on [Link]
Test-NetConnection [Link] Shows route hops to reach the
Trace route -TraceRoute destination
Test with a remote Test-NetConnection - Tests connectivity to an IP
computer name ComputerName [Link] address
Test with port and Test-NetConnection - Checks if port 80 is open and
detailed output ComputerName server01 -Port 80 gives detailed info

Good Alternative to:

 ping
 telnet
 tracert
🔍 Example:
Test-NetConnection [Link] -Port 443
Checks if Microsoft’s HTTPS port is reachable.
Let me know if you'd like to compare this with ping or telnet or want
to troubleshoot a specific scenario using this command.
If Test-NetConnection fails, it usually means one of the following
issues is preventing a successful connection between your machine
and the target host/port. Here's a quick breakdown:

🟥 Common Failure Reasons:

Possible Cause What It Means
No route to the target server — network is
🔌 Network unreachable
down.
🔒 Port blocked by Port is closed on the destination or blocked
Possible Cause What It Means
firewall in transit.
Server is offline or the service is not
❌ Server not responding
running.
🔁 DNS issue Hostname not resolving to an IP address.

🧪 Example Failure Output:

powershell
CopyEdit
Test-NetConnection -ComputerName [Link] -Port 3299
plaintext
CopyEdit
ComputerName : [Link]
RemoteAddress : [Link]
PingSucceeded : True
PingReplyDetails (RTT) : 2 ms
TcpTestSucceeded : False
🔍 Interpretation:
 PingSucceeded: True → Host is reachable.
 TcpTestSucceeded: False → Port 3299 (SAP Dispatcher) is not
open or service not running.

✅ Next Steps to Troubleshoot:

1. Check port is open on target (firewall/Netstat/SAP running?)
 2. Try telnet or niping to cross-verify.
3. Check SAProuter if applicable.
4. Ensure the SAP service is running and listening on that port.
------------------------------------------------------------------------------------

4. Tracert/Traceroute:
traceroute (or tracert on Windows):
Shows the path a packet takes from your system to a destination
IP/hostname, including all hops (routers) in between.
 Use:
cmd
CopyEdit
tracert [Link]
 📌 Helps find where delay or failure is happening in the network
path.
Here's a simple example to help you understand good vs. bad hops in
a tracert command output.

✅ Successful tracert Output (Good Hops)

tracert [Link]
Tracing route to [Link] [[Link]]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms [Link] <-- Local Router

 2 5 ms 6 ms 4 ms [Link]
3 9 ms 8 ms 7 ms [Link]
4 15 ms 16 ms 14 ms [Link]
5 20 ms 19 ms 21 ms [Link] [[Link]]

Trace complete.
 Each hop responds with latency values (ms).
 The path is clear and ends at the destination.

⚠️Bad tracert Output (Problematic Hops or Failures)

cmd
CopyEdit
tracert [Link]
csharp
CopyEdit
Tracing route to [Link] [[Link]]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms [Link]

2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
 ...
30 * * * Request timed out.

Trace complete.
 * * * Request timed out. = no response from intermediate
routers.
 Could indicate:
o Firewalls blocking ICMP
o Network issues
o Host unreachable

5. nslookup:
nslookup (short for "Name Server Lookup") is a command-line tool
used to query DNS (Domain Name System) servers to obtain
information about domain names and IP addresses. It helps in
checking if a domain name resolves to an IP address or
troubleshooting DNS issues.
examples of successful and failed nslookup commands:

✅ Successful nslookup Output

nslookup [Link]
Server: [Link]
Address: [Link]

Name: [Link]
Address: [Link]
✔️Meaning:
 DNS server successfully resolved the hostname
[Link] to its IP address [Link].

❌ Failed nslookup Output

nslookup [Link]
Server: [Link]
Address: [Link]

*** [Link] can't find [Link]: Non-existent

domain
❌ Meaning:
 DNS couldn’t resolve the hostname.
 Possible reasons:
o Typo in hostname
o DNS entry missing
o Wrong DNS server

6. Ping
Definition: ping is a command-line utility used to test the reachability
of a host on a network. It also measures the round-trip time it takes
for a packet to travel from the source to the destination and back.
Example Use Case:
 1. Check Network Connectivity: You can use ping to check if a
computer or server is reachable over the network.
Command Example:
ping [Link]
This command sends packets to [Link] and waits for a response,
indicating whether the website is reachable.
Output:
PING [Link] ([Link]) 56(84) bytes of data.
64 bytes from [Link]: icmp_seq=1 ttl=54 time=12.4 ms
64 bytes from [Link]: icmp_seq=2 ttl=54 time=11.9 ms

7. Telnet
Definition: telnet is a command-line tool used to connect to remote
devices (usually servers) over a network, typically on a specific port.
It's commonly used for testing connections to services like HTTP, FTP,
or SMTP.
Example Use Case:
1. Test Port Accessibility: You can use telnet to check if a specific
port is open and accessible on a remote server.
Command Example:
telnet [Link] 80
This command attempts to connect to port 80 (HTTP) on
[Link].
Output:
Trying [Link]...
Connected to [Link].
If the connection is successful, it means port 80 is open on the
remote server. If unsuccessful, it may indicate a firewall or network
issue.
Key Difference:
 ping is used to check network reachability.
 telnet is used to check if a specific port is open and listening.

8. A DNS switch
during the migration of servers from on-premise to the cloud refers
to the process of updating the DNS records to point to the new
cloud-based infrastructure after migrating the servers. This is an
important step in the migration process, ensuring that users and
services can resolve and access the new cloud-hosted servers rather
than the old on-premise ones.
Key Steps in a DNS Switch:
1. Migrating the Servers: You move your applications, databases,
and services to the cloud, configuring them to run on the cloud
infrastructure (e.g., AWS, Azure, Google Cloud).
2. DNS Record Update: After the migration, the DNS records (such
as A-records, CNAME records, or MX records) for the domain
need to be updated to reflect the new IP addresses or
endpoints associated with the cloud servers.
o For example: If your website's domain [Link]
was pointing to an on-premise server IP address, after
 migration, you update the DNS to point to the new IP
address or URL of the cloud server.
3. Propagation: Once the DNS records are updated, the changes
will propagate across the DNS system, which can take anywhere
from a few minutes to 48 hours, depending on TTL (Time to
Live) settings. During this time, some users might still be
directed to the old on-premise servers, while others will be
directed to the new cloud servers.
4. Testing: It's important to test the DNS switch to ensure that
everything is functioning as expected, and all services are
reachable through the new cloud infrastructure.
Example:
Imagine you have a web application hosted on an on-premise server
with an IP address [Link], and you are migrating this
application to AWS with a new cloud server IP [Link].
 Before Migration: DNS record for [Link] points to
[Link] (on-premise).
 After Migration: You update the DNS record for
[Link] to point to [Link] (cloud).
Why It's Important:
 Seamless Transition: The DNS switch ensures a smooth
transition for end-users, so they can access the migrated
servers without manual reconfiguration on their part.
 Avoid Downtime: Proper DNS switching can minimize
downtime and ensure that services are continuously accessible
as you transition between the on-premise and cloud
environments.
  Final Step of Migration: Once the DNS switch is complete, the
migration is essentially finished, and all traffic will be routed to
the cloud environment.
--------------------------------------------------------------------------------------------

9. CNAME & A-Records

Sure! Let’s go over the difference between CNAME (Canonical Name)
records and A (Address) records in DNS, along with examples and
their use cases.
A Record (Address Record)
 Definition: An A record maps a domain name directly to an IP
address (IPv4 address).
 Use Case: It’s typically used when you want to associate a
domain name with a specific server's IP address.
Example Use Case for A Record:
Let’s say you want [Link] to point directly to an IP
address of your server.
 Domain: [Link]
 IP Address: [Link]
A Record Example:
[Link]. IN A [Link]
This means whenever someone visits [Link], the DNS
server will resolve it to [Link] and direct the user’s traffic to
the corresponding server.

CNAME Record (Canonical Name Record)

  Definition: A CNAME record maps a domain name to another
domain name, not directly to an IP address.
 Use Case: It’s used when you want to alias one domain name to
another. This is especially useful for subdomains or when you
want to point multiple domains to the same resource but
manage only one "canonical" domain.
Example Use Case for CNAME Record:
Let’s say you have a main website hosted at [Link], and you
want [Link] to point to the same location without using
the same IP address.
 Domain: [Link]
 Canonical Domain: [Link]
CNAME Record Example:
[Link]. IN CNAME [Link].
This means when someone visits [Link], the DNS server
will resolve it to [Link] (which could have an A record
pointing to the server’s IP address). Essentially, [Link] is
an alias for [Link].

Key Differences and When to Use Each:

1. A Record:
o Directly points a domain to an IP address.
o Use Case: When you have a fixed IP address and want a
domain name to point directly to it.
o Example: Pointing [Link] to [Link].
2. CNAME Record:
 o Points one domain name to another domain name (an
alias).
o Use Case: When you want to create aliases for the same
resource or when you need to point a subdomain (like
[Link]) to the main domain
([Link]).
o Example: Pointing [Link] to
[Link].

Scenario with Both A and CNAME Records:

Let's say you have:
 Your main website at [Link] with an IP of [Link].
 A subdomain [Link] that you want to alias to
[Link] (so it shares the same content).
1. A Record for Main Domain:
2. [Link]. IN A [Link]
3. CNAME Record for Subdomain:
4. [Link]. IN CNAME [Link].
5. A Record for Alias ([Link]):
6. [Link]. IN A [Link]
So, when someone types in [Link], it’s internally resolved
to [Link], and [Link] then resolves to the IP
address [Link].

Summary:
  A Records: Use when you want to directly point a domain to an
IP address.
 CNAME Records: Use when you want to point one domain
name to another (useful for aliases and subdomains).
Does this help clarify the difference and how each is used?

10. Cnames & A-Names in Migration

scenarios
In migration scenarios (especially when moving servers from on-
premise to cloud), CNAME records are generally more beneficial.
Here’s why:
Why CNAME Records Are Beneficial in Migration:
1. Simplified DNS Management:
o CNAME records allow you to point multiple domains or
subdomains to the same destination without needing to
update the IP address every time the destination changes.
o During migration, when you move to the cloud, you
typically don’t need to update all DNS records for
subdomains if you use CNAME records. Instead, you only
need to update the A record of the "canonical" domain
(e.g., [Link]), and the CNAME records will
automatically follow this change.
2. Minimal Downtime:
o In migration scenarios, DNS changes often require a
period of propagation. With CNAME records, you don't
have to update each subdomain's IP address manually—
 just update the main domain's A record and let the
CNAME aliases handle the rest.
o This reduces the chance of errors and minimizes
downtime because only one DNS change is needed for all
related subdomains (like [Link],
[Link], etc.).
3. Flexibility in Pointing to Cloud Resources:
o During migration, the IP addresses of cloud resources may
change or need to be reallocated. Using CNAME records
lets you point your subdomains (e.g., [Link])
to a common name (like [Link]) that
can be updated as necessary.
o For example, if you migrate from one cloud provider to
another, you can simply update the A record for the
canonical domain ([Link]) to point to
the new IP, and all the CNAME-based subdomains will
automatically resolve to the new cloud server.
A Record Use in Migration:
While A records are also necessary (because you need to have an IP
address for the main domain or a server), they require more frequent
updates during migration, especially if you need to re-point domains
to different IPs in the cloud. Each domain or subdomain that has an A
record pointing to an IP will need to be updated to reflect the new IP
address once you migrate.
Example:
 You move [Link] to the cloud with a new IP
address [Link]. You update the A record for
[Link] to point to [Link].
  If you have multiple subdomains (e.g., [Link],
[Link]), you would also need to update the A
records for each one (or the CNAME records if you’re pointing
them to [Link]).
Best Approach for Migration:
1. Update A Record for the Canonical Domain: For your main
domain (e.g., [Link]), update the A record to point
to the new IP address in the cloud.
2. Use CNAME for Subdomains: For all subdomains (e.g.,
[Link], [Link]), use CNAME records to
point to [Link]. This way, you only need to update
the A record for the main domain, and the subdomains will
automatically follow.

Example Scenario in Migration:

Before Migration:
 A record for [Link] points to the on-premise server
IP [Link].
 CNAME for [Link] points to [Link].
After Migration:
 You move [Link] to the cloud with a new IP, say
[Link].
 Update the A record for [Link] to point to
[Link].
  The CNAME for [Link] still points to
[Link], so it will resolve to the new IP [Link]
automatically.
This way, the change is minimal, and you only update the A record
once, while all subdomains (via CNAME) automatically follow the
main domain’s change.

Conclusion:
 CNAME records are ideal in migration scenarios for managing
subdomains and ensuring that DNS changes are minimal and
scalable.
 A records are necessary for the main domain but are more
cumbersome to update for each domain/subdomain
individually.
This approach ensures flexibility, ease of management, and minimal
disruption during server migration from on-premise to the cloud.
-------------------------------------------------------------------------------------------

[Link] of IP address or FQDN

change during migration:
Before Migration (On-Premise):
A Record for [Link](main server)
[Link] IN A [Link]

CNAME Records for subdomains pointing to [Link]:

[Link] IN CNAME [Link]
[Link] IN CNAME [Link]
[Link] IN CNAME [Link]

Scenario 1:
When only IP address changes ,then it is enough if we update the A-
records
After Migration (Cloud):
 Update the A record for [Link] to the new
cloud IP:
[Link] IN A [Link]
 All CNAME records (e.g., [Link], [Link],
[Link]) automatically resolve to the new IP address
([Link]) because they point to [Link].
No need to update each subdomain's DNS manually! You just update
the A record for [Link], and all subdomains will
automatically follow.
Scenario-2
When both IP address and FQDN changes
To ensure minimal downtime during a DNS switch when both FQDN
and IP address change after cloud migration, use the following
strategy:
Best Practice: Use Temporary CNAME Mapping + Low TTL
Step-by-step with Example
Before Migration (On-Prem)
 Current FQDN: [Link] → IP: [Link]
  Public DNS points to:
objectivec
CopyEdit
[Link] IN CNAME [Link]
☁️After Migration (Cloud)
 New FQDN: [Link] → IP: [Link]
 Update DNS CNAME:
[Link] IN CNAME
[Link]

⚙️Additional Tips to Minimize Downtime:

1. Lower TTL (e.g., 300 seconds or 5 min) 24–48 hours before
switch
This ensures faster DNS cache refresh.
2. Switch CNAME to new cloud FQDN during a planned cutover
This avoids IP dependency and minimizes change points.
3. Post-migration, test [Link] directly
before switching CNAME.

✅ Result:
Only one DNS change (CNAME) needed, and because TTL was low,
clients update quickly = minimal downtime.
------------------------------------------------------------------------------------------
12. TTL
What is TTL in DNS?
TTL (Time To Live) tells how long DNS records are cached by users'
systems or ISPs.

🕐 Why Lower TTL Before Migration?

If TTL is high (e.g., 86400 seconds = 24 hrs), users may continue using
the old IP/FQDN even after the DNS is updated — causing downtime
or misrouting.
So, before switching:
✅ Lower the TTL to something like 300 seconds (5 mins) — 24 to 48
hours before the planned change.
That way, when you update DNS:
🟢 Clients check for new DNS info every 5 minutes, not every 24
hours.
👉 This ensures faster propagation and minimal downtime.

🔄 After Migration:
You can increase TTL back to a higher value for stability.
4o
You said:
You can increase TTL back to a higher value for stability.?why?
ChatGPT said:
Yes, you can increase TTL back to a higher value after migration for
stability and performance. Here's why:
✅ Why Increase TTL After Migration?
1. Less DNS Traffic
Higher TTL (e.g., 1 hour or 24 hours) means client systems
cache DNS longer, reducing the number of DNS lookups → less
load on DNS servers.
2. Faster Response Time
If DNS is cached, applications resolve hostnames faster,
improving performance for users.
3. Network Efficiency
Fewer external DNS queries = less network chatter and better
overall efficiency.

🔁 Example:
After migration is stable:
[Link] TTL 86400 (24 hrs)
This means clients will reuse the resolved IP for 24 hours without re-
checking DNS.

⚠️Just Remember:
Only increase TTL after you’re sure the system is working fine in the
new environment.
-----------------------------------------------------------------------------------------
13. Impact of Migration on third party
systems:
1. Update the third-party system's configuration: to use the new hostname or FQDN of the
SAP system. This might involve updating URLs, API endpoints, or connection settings as
discussed above.

2. Use a Load Balancer or Reverse Proxy: If the third-party system communicates with the
SAP system through a load balancer or reverse proxy, you might need to update the load
balancer or reverse proxy configuration to point to the new SAP system.

3. Certificate Updates: If the SAP system uses SSL/TLS certificates, you might need to update
the certificates to reflect the new hostname or FQDN.

a. Certificate for the CNAME Record: If the third-party system connects to the SAP system
using the CNAME record ([Link]), the SAP system should have an SSL
certificate that matches the CNAME record ([Link]). If the SAP system has
a wildcard certificate or a certificate that matches the CNAME record (sap-
[Link]), no change might be required in the third-party system.

b. Certificate for the Actual Hostname: If the SAP system has an SSL certificate for its actual
hostname ([Link]), the third-party system might not trust the
certificate if it's not configured to trust the certificate authority (CA) that issued the
certificate. If the SAP system's certificate is not trusted by the third-party system, you might
need to update the certificate trust store in the third-party system to trust the CA that issued
the certificate. If the SAP system's certificate doesn't match the CNAME record, you might
need to obtain a new certificate that matches the CNAME record ([Link]).

Best Practices

1. Use a Certificate that Matches the CNAME Record: Ensure that the SAP system has an SSL
certificate that matches the CNAME record ([Link]) to avoid any
certificate trust issues.

2. Use a Wildcard Certificate: Consider using a wildcard certificate (*.[Link]) to cover

multiple hostnames and simplify certificate management.

4. Firewall Rules: Ensure that the firewall rules are updated to allow communication
between the third-party system and the new SAP system.

14. Virtual hostname:

 A virtual hostname is a name that the server itself recognizes locally as its
own identity (can be mapped to an IP via /etc/hosts or Windows hosts file).
  Commonly used in clustering (like SAP ASCS/ERS setups or HA environments).

 OS or application thinks it's running under this virtual name, even though the
physical server hostname is different.

✅ Example:

Suppose your physical server name is [Link].

You define a virtual hostname like:

[Link]

and in the /etc/hosts or DNS you map:

[Link] [Link]

So, SAP services can bind to [Link] and you can failover this IP/hostname to
another server.

 A CNAME is a DNS alias that points one hostname to another.

 Used purely at DNS level; the client is redirected to the real hostname via DNS.

 Server doesn't know it's being accessed via a CNAME.

If you're using a virtual hostname for an SAP server, then the CNAME should point to the
virtual hostname, not the physical hostname.

🔹 Why?
Clients and apps connect using the virtual hostname. In case of failover or changes, the
backend mapping (virtual → physical) changes without affecting the users or DNS.

🔹 Example:

[Link] CNAME [Link]

Then internally: [Link] resolves to the physical server.

✅ This ensures flexibility and high availability.

-------------------------------------------------------------------------------------------------------------------------

15. nmon:

16. Basics of Networking

As an SAP Basis consultant, it is handy and helpful to be familiar with basics of networking. It
helps us to get a better understanding of the customer’s overall landscape and aids in
analysis and troubleshooting. This post discusses basic terminologies involved in networking.
It is for anyone who is very new to networking.

Networks and subnets?

Two or more computers or devices connected form a network. This connection can be via a
cable or a wireless one.

Subnet is nothing but subset of a network or part of a network.

What is an IP address?

If a computer can be considered as a telephone, IP address is equivalent to the phone

number. As we all know a telephone number has two parts – area code (AAA) and local
number (LLL-LLLL) something like AAA-LLL-LLLL. Similarly, IP address also has two parts –
Network id (which is the area code) and Host id (which is the local number). All the
computers or devices on a network have an IP address. Network id is the same for all the
devices on a network. Host id which is also called node id is unique to each device. No two
computers on a network can have the same IP just like no two local phone numbers in an
area can be the same.

IPv4 and IPv6?

The two most common IP address versions available today are IPv4 and IPv6. IPv6 is a more
recent version and is a successor of IPv4.

IPv4 addresses are 32-bit addresses whereas IPv6 is a 128-bit address. We are looking at
IPv4 addresses in this post.

In an IPv4 address, each byte or the 8-bit segment of the address is called an octet. It is
generally represented in decimal format with each octet separated by a period (like
[Link]).

Classless Inter-domain routing is a method of representing a range of IP addresses.

Public network & Private network?

Public network is something that is publicly available over the internet.

Private network is the one that cannot be accessed directly over the internet. The hosts in a
private network have private IP addresses and hence help in conserving addresses in the
public IP address range. A private network is highly secured with firewalls and a number of
other rules that are established within the subnets. This makes it the most chosen choice for
all the systems that host confidential data. From an SAP perspective, most of the application
servers and all database servers are usually in subnets within a private network of the
organization. Federated portal or Fiori systems are exposed to the internet via web
dispatcher and/or external load balancers.

A number of rules can be defined at a subnet level and a private network level on how to
route a particular request and whether to allow or deny access to and from the hosts in
network.

Private IP address ranges –

Class A - [Link] to [Link] – First octet is the network id and the remaining three
octets are host id

Class B - [Link] to [Link] – First and second octet are network id, third and
fourth constitute host id

Class C - 192.168.0 0 to [Link] – first, second and third are network id while the
fourth one is for host id

In a network with smaller number of subnets and more devices, class A provides larger
address space range for hosts. In a network with large number of subnets with low number
of hosts on each subnet, Class C provides more CIDR blocks for subnets.

You may notice that the private ip addresses of different components in an environment (say
DEV or QAS or PROD) differ by only one or two octets. This is because of the fact that all the
components are part of the same subnet and have the same network id.

De militarized Zone (DMZ)?

DMZ is a subnet in your network that exposes the external-facing systems of your IT
landscape to the internet. It provides a layer of security to your network. Systems that
provide services to users on external network are placed in DMZ. SAP Web dispatcher lies in
the DMZ.

Firewall?

Firewall sits in the DMZ between internet and your local network. It prevents unauthorized
access to internet users to a private network. All the traffic to and from the local network
has to pass through firewall and is secured.
Network Address Translation (NAT)?

NAT device hides original host IP address from the outside world. It masks the IP address of
the hosts on its network and exposes its own IP address or that of a firewall to the internet.
In these cases, NAT devices are associated with a public IP address. All the requests to
internet originating from a network are exposed with a single IP address. This way, a number
of host computers or devices are able to talk to the internet with a single IP address and
hence NAT helps in slowing down the rate at which address space is assigned. NAT device
keeps track of all outgoing packets transferred and matches the incoming packets with the
correct hosts. While you are in office and open SAP support portal, the NAT device masks
your host ip and sends the request to SAP with firewall ip. The response from SAP is sent
back to firewall ip which is then checked internally as to which host is awaiting response and
then routed to your host.

Domain, Domain Name System (DNS) & Fully Qualified Domain Name (FQDN)?

Simply put, DNS lets us use names instead of IP addresses while connecting to a server. It is
because of the existence of DNS names, we are able to call
[Link] or [Link] instead of those servers ip addresses like
[Link] or [Link].

DNS uses a hierarchical naming system similar to SAP folder structure. The folders are called
domains and the hosts can be considered as files in the ultimate folder. Here is an example
DNS domain tree. Anchor point for all domains is root which lies at the top. Millions of
domains exist under root and these are called top-level domains. There can be multiple sub-
levels under each domain, the DNS tree can be upto 127 levels deep. Domain under a
domain is called a subdomain. The complete DNS name of the PROD fiori becomes
[Link] and that of DEV becomes [Link]. The complete DNS
name [Link] is called a Fully Qualified Domain Name (FQDN).

DNS Domain tree

Although most of the implementations have a separate Infrastructure team, it is extremely

important for an SAP Basis consultant to be aware of networking terminology to better
understand the holistic architecture.

This post is an attempt to explain the commonly used networking terms in a simple way
targeting beginners in this area. Thank you for reading and please leave your feedback in the
comments section.

Outbound traffic

SAP System (Private IP)

Proxy Server (Private IP)

↓
NAT Gateway (Public IP)

Internet

If your proxy server is in a public subnet with a public IP, then NAT is not needed.

But that’s rare in secure enterprise setups, where public IPs are avoided directly on proxy
hosts.

Inbound traffic

Internet (Public Client)

Public IP (NAT / Elastic IP)

Firewall (Allow only required ports, e.g., 443/HTTPs)

SAP Web Dispatcher (in DMZ or public subnet)

SAP Backend System (App server in private subnet)

Component Role

Public IP / NAT Accepts public traffic and maps it to internal resources.

Firewall Filters traffic based on IPs, ports (only allows valid SAP traffic).

Web Handles load balancing, SSL termination, and routing to correct SAP
Dispatcher backend system.

SAP Backend Actual processing happens here (e.g., ABAP/Fiori/etc.).

Mon-sat 8:30