{"id":111274,"date":"2026-07-01T12:00:00","date_gmt":"2026-07-01T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=111274"},"modified":"2026-06-25T11:15:59","modified_gmt":"2026-06-25T11:15:59","slug":"in-cloud-migrations-networking-fundamentals-matter-more-than-you-think-heres-why","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/cloud\/in-cloud-migrations-networking-fundamentals-matter-more-than-you-think-heres-why\/","title":{"rendered":"DMS migration failing? How to debug Oracle to Cloud SQL network errors, layer-by-layer (OSI model guide)"},"content":{"rendered":"\n

For database engineers stepping into cloud migrations for the first time, networking is the silent troublemaker. Most tutorials skip straight to configuring connection profiles, but if the network underneath isn’t right, DMS will fail in ways that feel cryptic and random. <\/strong><\/p>\n\n\n\n

This guide uses the OSI model as a practical debugging framework \u2014 not as abstract theory \u2014 to help you pinpoint exactly where an Oracle to Cloud SQL PostgreSQL migration is breaking down, layer by layer. <\/strong><\/p>\n\n\n\n

From VPC routing gaps at Layer 3 to SSL certificate mismatches at Layer 6, you’ll learn how to read DMS error messages like a map, and how a 15-minute pre-flight connectivity check can save you an entire day of confusion.<\/strong><\/p>\n\n\n\n

Before we begin – a quick introduction<\/h2>\n\n\n\n

I want to start with a confession: a few years back, I went deep on networking. I mean really<\/em> deep – TCP\/IP<\/a> internals, packet capture with Wireshark<\/a>, OSI layers<\/a> until I could recite them in my sleep. <\/strong><\/p>\n\n\n\n

For a while, it felt like a superpower. Network issue blocking a migration? Give me a day or two and I’d have it pinpointed. I could see<\/em> what was happening beneath the surface in a way that most database engineers around me couldn’t.<\/p>\n\n\n\n

Then life got busy, projects piled up, and I drifted back to focusing on the database layer: schemas, indexes, query plans. That networking muscle I’d been using so much of, began to fade.<\/p>\n\n\n\n

Fast forward to working with Google Database Migration Service (DMS)<\/a> on an Oracle to Cloud SQL PostgreSQL migration<\/a>, and guess what came back to bite me? It was the network – every single time.<\/p>\n\n\n\n

So I’m writing this series partly to share what I’ve learned, and partly to rebuild because I think the journey of why<\/em> networking fundamentals matter is just as useful as the technical details themselves. Especially if you’re a database engineer stepping into cloud migrations for the first time.<\/p>\n\n\n\n

The three-point connectivity problem<\/h2>\n\n\n\n

When you set up DMS for an Oracle to Cloud SQL<\/a> migration, you’re not dealing with a simple two-node<\/a> connection. You have three distinct players:<\/p>\n\n\n

\n
    \n
  1. Your source<\/strong> – the Oracle database<\/a> (often on-premises)

    <\/li>\n\n\n\n
  2. DMS<\/strong> – Google’s migration service, running inside a VPC (virtual private cloud)<\/a>

    <\/li>\n\n\n\n
  3. Your target<\/strong> – Cloud SQL for PostgreSQL (also inside Google Cloud)<\/li>\n<\/ol>\n<\/div>\n\n\n

    Each of those relationships – DMS to Oracle, and DMS to Cloud SQL – have their own networking requirements, failure modes, and error messages that can send you down the wrong rabbit hole if you don’t understand what’s happening at a lower level.<\/p>\n\n\n\n

    Most tutorials jump straight to “configure your connection profile” but, if the network isn’t right underneath, DMS will fail in ways that feel cryptic and random. The error messages bubble up from deep in the stack and don’t always tell you where the real problem is.<\/p>\n\n\n\n

    That’s where the OSI model comes in – and it’s what we’ll examine next.<\/p>\n\n\n\n

    What is the OSI model (and why should database engineers care)?<\/h2>\n\n\n\n

    If you studied networking at any point, you’ve seen this before. It’s much more than just ‘theory for theory’s sake’.<\/p>\n\n\n\n

    The OSI (Open Systems Interconnection) model describes how data travels from one system to another in seven distinct layers:<\/strong><\/p>\n\n\n\n

    Layer<\/strong><\/th>Name<\/strong><\/th>What it does<\/strong><\/th><\/tr><\/thead>
    7<\/td>Application<\/td>The protocol your app speaks (e.g. Oracle Net, PostgreSQL wire protocol)<\/td><\/tr>
    6<\/td>Presentation<\/td>Encoding, encryption (e.g. TLS\/SSL), data format translation<\/td><\/tr>
    5<\/td>Session<\/td>Managing connections and sessions (e.g. TNS negotiation in Oracle)<\/td><\/tr>
    4<\/td>Transport<\/td>TCP\/UDP – reliable delivery, ports, retransmission<\/td><\/tr>
    3<\/td>Network<\/td>IP addressing, routing between networks<\/td><\/tr>
    2<\/td>Data Link<\/td>MAC addresses, switches, local network framing<\/td><\/tr>
    1<\/td>Physical<\/td>Cables, fiber, signals (the actual hardware)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    One important thing to know before we go further: the OSI model is a thinking tool, not a rigid rulebook. Real-world protocols don’t map to it perfectly. <\/p>\n\n\n\n

    And TCP\/IP<\/a> – which is what everything actually runs<\/em> on – doesn’t cleanly separate into seven layers. Practitioners often collapse layers together, which is why you’ll hear people talk about “Layer 3\/4” in the same breath. What matters is the mental model it gives you for debugging.<\/p>\n\n\n\n

    The key insight: layers are sequential<\/h2>\n\n\n\n

    The single most useful thing to understand about the OSI model for debugging purposes, is this: a failure at a lower layer prevents every layer above it from running.<\/strong><\/p>\n\n\n\n

    Think about what that means in practice. If Layer 3 (Network) fails – meaning DMS cannot route a packet to Oracle’s IP address – then Layers 4, 5, 6, and 7 never get a chance to do anything. Oracle never sees the connection attempt, the TNS (Transparent Network Substrate)<\/a> listener never responds, and SSL never negotiates. <\/p>\n\n\n\n

    The result? Authentication never happens.<\/strong><\/p>\n\n\n\n

    This gives you a powerful debugging process. Simply read the error message and ask yourself, how far did the connection actually get before it failed?<\/em> The answer tells you which layer to focus on.<\/p>\n\n\n\n

    \n
    \n
    \n
    \n

    Enjoying this article? Subscribe to the Simple Talk newsletter<\/h3>\n
    \n Get selected articles, event information, podcasts and other industry content delivered straight to your inbox. <\/div>\n <\/div>\n Subscribe now<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n

    How to read error messages through an OSI lens<\/h2>\n\n\n\n

    Let me walk through what a failure at each layer actually looks like in the context of a DMS to Oracle connection. This is the reference I wish I’d had when I started.<\/p>\n\n\n\n

    Layer 1 (physical) – almost invisible in cloud migrations<\/h3>\n\n\n\n

    Layer 1 failures are about raw physical signal transmission – bad cables, failed network interfaces, disconnected fiber. In a fully cloud-based migration, Layer 1 is Google’s problem, not yours. Their infrastructure handles it entirely.<\/strong><\/p>\n\n\n\n

    The one scenario where Layer 1 could affect you is if your Oracle source is on-premises and connected to Google Cloud via Dedicated Interconnect<\/a>. A bad transceiver<\/a> or damaged fiber on that cross-connect could cause a Layer 1 failure. But that is some\u00a0you’d be escalating to your physical network team at that point, not debugging it yourself.<\/p>\n\n\n\n

    If Layer 1 fails, you won’t see an application error at all. You’d see it in operating system logs:<\/p>\n\n\n\n

    eth0: Link is down<\/code><\/p>\n\n\n\n

    No carrier detected<\/code><\/p>\n\n\n\n

    NIC reported media disconnected<\/code><\/p>\n\n\n\n

    These show up in dmesg<\/code> or \/var\/log\/syslog<\/code>, not in DMS or Oracle logs. Most database engineers never look there –\u00a0 which is exactly why Layer 1 failures feel so mysterious when they do<\/em> occur.<\/p>\n\n\n\n