投稿者: 69578300

  • Personal Heuristics for WBS Optimization

    Personal Heuristics for WBS Optimization

    Personal Heuristics for WBS Optimization

    Disclaimer

    The following items are based on personal field experience. They are presented as practical heuristics rather than formal theory.

    Always Rehearse with a Planned Rollback

    When performing a rehearsal, we assume from the outset that a rollback will occur. The rehearsal is executed with a predefined rollback plan, and we verify in advance not only the rollback procedure itself but also the accuracy of the estimated rollback duration.

    This ensures that when a real rollback is required, both the method and the time required are already validated.

    Execute Risky Tasks Early in the Process

    High-risk tasks are intentionally placed in the early stages of the workflow.

    Because fewer changes have accumulated at that point, the rollback scope remains small. This allows rollback operations to be performed rapidly and accurately if needed.

    Allocate Generous Time Buffers in Early Steps

    We assign larger time buffers to preceding steps.

    As work progresses, unused buffer time accumulates. This creates increasing temporal and psychological margin, allowing the team to operate with greater stability and clarity as the project advances.

    Maintain a Sustainable Throttle Margin

    Our guiding principle is:

    Prepare for trouble in advance.
    Do not run at full throttle.
    Maintain the throttle setting that allows the longest possible range.

    Rather than pushing systems or teams at maximum capacity, we operate at a sustainable level that preserves maneuverability. This ensures that when unexpected issues occur, there is always room to respond, adjust, and recover without loss of control.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`

  • Proven Troubleshooting and Recovery Cases in Enterprise Networks

    Proven Troubleshooting and Recovery Cases in Enterprise Networks

    ※日本国内案件については、元請けITベンダー様経由での技術支援を基本としています。
    Proven Troubleshooting and Recovery Cases in Enterprise Networks

    Proven Network Troubleshooting Cases

    These network troubleshooting cases were resolved in enterprise production environments.

    Cisco SD-WAN

    We resolved operational limitations in Cisco SD-WAN environments by introducing automation.

    Tasks difficult to perform through the GUI were implemented using Python.
    Legacy TeraMacro procedures were translated into Python using generative AI, including automated configuration backup operations.

    To prevent operational mistakes, a safety mechanism was implemented:
    if the expected management IP address does not exist in the configuration, the script automatically stops.

    All intellectual property must remain with the client.
    Therefore, we use client-owned generative-AI environments when generating scripts.

    Any modern tool must be usable by anyone.
    If only specialists can operate it, it has limited value.
    TeraMacro training costs are extremely low.People simply buy used routers on Yahoo Auctions (typically only a few thousand yen).

    During pre-deployment validation, we discovered that the legacy BGP command “allow-as in” cannot be implemented in SD-WAN.
    We resolved this using redistribution and route filtering.

    IOS-XE 9200/9300 Switching

    We resolved an issue where the command
    “no spanning-tree vlan xx”
    could not be applied.

    The issue was solved using BPDU filter and BPDU guard.
    Other members had been unable to resolve it before our intervention.

    AWS

    When web filtering was enabled, uploads failed with a probability of roughly 19 out of 20 attempts.

    Root cause:

    • Global IP changed mid-session due to virtual server relocation
    • Non-DNS-based algorithm
    • Packet fragmentation preventing Layer-7 inspection

    This was confirmed through packet capture analysis.

    VPN / IPsec

    We identified incorrect hardware selection in a failed data-leak-prevention deployment.

    We resolved a billing-related issue in an on-demand VPN circuit where packets continued arriving after communication completion due to IPsec confirmation behavior.

    We also resolved:

    • QoS not functioning with IPsec
    • MTU issues caused by key-length changes
    • Customer concerns about unencrypted voice packets (disproved through waveform analysis)

    Layer 7-2 (Transparent IPS/WAF)

    In transparent IPS/WAF environments, HSRP hello frames and R-STP BPDU frames did not pass by default on certain platforms.

    Impact:

    • HSRP Active-Active state
      I “came up with” the idea on the spot to roll back using an RJ-45 J-J connector.
    • Up to 5 minutes of network outage
      This issue had remained unresolved for three years.

    We also discovered in advance that Auto-MDI becomes disabled when a transparent IPS loses power, which can cause link failure with fixed-speed devices.

    Layer 4-3 (Load Balancers / Firewalls)


    We discovered source-port exhaustion and TIME_WAIT reuse issues when SNAT was enabled on load balancers.

    We also resolved:

    • RedHat memory exhaustion caused by RST-terminated health checks
    • Embryonic timeout issues
    • TraceRoute being SNATed by default
    • Firewall uRPF alerts triggered by TraceRoute

    All confirmed via packet capture.

    Issue: Juniper SRX repeatedly rebooting

    On a Juniper SRX, after initiating a reboot via the serial console and command line, all activity stopped for more than ten minutes.
    I suspected it had frozen and pressed keys on the PC keyboard, but there was no response.
    During that period, the characters I typed (including Enter) accumulated in the PC’s keyboard buffer.
    After a while, the log shows that for a brief moment it displayed: “press any key to reboot.”

    Palo Alto (FW) — Failover Delay Analysis

    The cause of the unexpected time consumed during failover was identified from the physical topology diagram.
    The HA link between the primary and secondary units had been connected through a switch.
    MAC flapping was recorded in the switch logs, indicating that this switch-mediated HA connection was the root cause of the failover delay.

    Key Finding

    The HA link must be directly connected between the primary and secondary units.
    Introducing a switch in between can lead to MAC flapping and increased failover time.

    Layer 3 Routing

    Troubleshooting: QoS, NAT, Stateful NAT, PIM Multicast, and HSRP

    We discovered incorrect QoS + NAT implementation described in Cisco documentation.

    ACLs referencing IP addresses did not produce expected results.
    Using port-based ACLs resolved the issue.

    Wireshark graphs changed from a sawtooth pattern to a straight line, proving QoS effectiveness.

    We also:

    • Identified QoS misconfiguration with priority queue
    • Predicted CPU overload during NAT migration
    • Discovered stateful NAT left unconfigured for five years
    • Confirmed PIM multicast and HSRP interoperability

    Layer 2 Switching

    We proved that some switches configured for untagged VLANs forward all tagged frames regardless of VLAN ID.

    We also:

    • Prevented STP root-bridge takeover during switch addition
    • Resolved multicast MAC conflicts between IGMP and BPDU

    Layer 1 / Wi-Fi / Bluetooth

    We resolved Wi-Fi multicast performance degradation caused by lack of Layer-1 ACK.

    On Cisco WLC, converting multicast to unicast resolved the issue.

    Bluetooth Noise Investigation

    Using the Ukrainian-made spectrum analyzer IT24, we verified and demonstrated that no significant noise was present within the Bluetooth frequency band.

    Crosstalk Issue in AI-Based Noise Cancellation

    Using a phase-inversion analog noise canceller, we suppressed background voices located behind the telephone operator, addressing the crosstalk issue.

    Radio Environment Verification Using a Spectrum Analyzer

    By continuously recording the display and control screen of a Chinese-made spectrum analyzer (RF Explorer) over an extended period, we demonstrated that no interference caused by electromagnetic waves was present in the VIC, aeronautical radio, or weather satellite frequency bands.

    Electromagnetic Leakage Measurement Around Power Systems Using Fluke

    We were asked to assess the risk of potential TEMPEST-type attacks. By leveraging the credibility and measurement capability of Fluke instruments, we demonstrated that no meaningful electromagnetic leakage was occurring from the power systems.

    Gray-Zone Optimization

    By configuring the wireless access point to use right-hand circular polarization, we reduced Wi-Fi interference and channel congestion.

    Exoneration of Suspected Interference Points Using a Noise Generator

    Using a Noise Generator manufactured by Japan’s CosmoWave, we demonstrated that the cause of the VoIP communication issues was not electromagnetic interference.

    Verifying Server Power Supply Redundancy Using Power Line Communication (PLC)

    We measure and confirm whether primary and secondary power redundancy is properly established by using PLC (Power Line Communication) as a diagnostic tool.

    Work in Progress: 10 GHz Band & Future Wi-Fi Measurement Prototype

    • Early prototype for a 10 GHz-band measurement platform
      Development is underway for a measurement device targeting the 10 GHz range, with a roadmap toward future Wi-Fi analysis and verification tools. The goal is to establish a practical, field-deployable measurement environment rather than a purely laboratory-grade instrument.
    • Hardware status
      • LNB (Low-Noise Block converter) already procured and validated for integration.
      • Bias-T circuit currently under soldering optimization and impedance tuning for stable DC feed and RF isolation.
    • Purpose of this prototype
      This pre-production model is intended to support high-frequency evaluation, signal-path verification, and future expansion toward professional Wi-Fi measurement workflows. It is being built with a vendor-neutral design philosophy and a focus on real-world troubleshooting scenarios.
    • Next steps
      • Finalize Bias-T assembly and stability testing.
      • Integrate LNB with measurement chain.
      • Validate repeatability and noise characteristics.
      • Prepare for extension into Wi-Fi measurement use cases.

    Status: Ongoing engineering work. Detailed specifications will be published after verification.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`

  • Deploying Satellite Internet in Areas with Unstable Power

    Deploying Satellite Internet in Areas with Unstable Power

    Deploying Satellite Internet in Areas with Unstable Power

    Satellite Internet Deployment in Unstable Power Environments

    BGP convergence is slow. Therefore, an overlay is used. For validation, in-house CML (SD-WAN) assets are used. Since it was purchased as individual components, there is no receipt stating that a “server” was bought.

    Starlink as Experimental Infrastructure

    As shown on other pages (e.g., RTP jitter measured with Wireshark and the output of show ntp associations detail), the quality is simply poor. In theory, only payload-redundant UDP—namely QUIC—seems usable.

    This lab supports satellite connectivity deployment in regions with unstable power infrastructure.

    The SD-WAN validation lab is currently being built on Cisco CML.
    During preparation, a dual-boot Ubuntu/Windows environment was tested.
    After two weeks of operation, boot instability and unexpected behavior were observed.
    The current system state is documented below.
    This machine is not a production system and is used solely for architecture validation and field-failure simulation.

    After approximately two hours of continuous input (“y” key), the system stopped accepting further commands, including reboot. The current state of the Ubuntu dual-boot test environment is documented below.

    This machine is part of an SD-WAN validation lab using Cisco CML and is not a production system.

    Power Failure Scenarios and Router Design

    On CML, a large Layer 2 network is built using VXLAN.
    Frequent power outages cause the carrier’s backup power to be consumed frequently.
    Assume that the transportation infrastructure has also not kept pace.
    It is expected that the power supply for communications networks will be given lower priority than that of medical facilities.

    Why This Is Not a Primary Line

    Because the theoretical performance cannot be expected. Subjective impressions are unnecessary for validation.

    Field-Ready Configuration Strategy

    CML will be set up, but SD-WAN validation may be done first, because publishing concrete Python code has commercial value.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`

  • Security: Practical Notes

    Security: Practical Notes

    Security: Practical Notes

    Order Matters More Than Tools

    htmlspecialchars()

    echo htmlspecialchars($s, ENT_QUOTES, ‘UTF-8’);
    If user input is rendered into HTML, run this first.
    That alone removes most XSS risk.

    At output.
    Not during storage.

    Before Any WAF

    Years ago, I focused on selling WAF.

    I was not wrong.
    But I was out of order.

    If an application outputs raw user input,
    a WAF compensates for something that should have been fixed in one line.

    Today, I start here.

    Then we talk about WAF.

    What I Would Do Differently Now

    I once worked with an internal SE team at a client company.

    They were capable.
    They were practical.

    If I had shown them this one line first,
    we could have had an engineering discussion
    instead of a product discussion.

    Not the tools.
    The order.

    Start With One Line

    Expensive security can wait.
    The first line of defense is literally one line.

    htmlspecialchars()

    Everything else comes after.

    Why UI Matters for Security

    Local First, Then Network

    Order Matters More Than Tools

    Start With One Line

    The UI I Am Building Now

    A Security Tool Should Be Boring

    Early UI prototype.
    Security tools should be simple before they are powerful.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`


  • Tips & Tricks

    Tips & Tricks

    Tips & Tricks

    Introducing a Well-Known Freeware Tool

    Content:

    • WinSCP
      • liminates the need for vi.
      • Can be used together with any text editor you are comfortable with.
    • Tera Term
      • Font scaling allows you to enlarge text for better visibility during long CLI sessions.
      • Session logs can be replayed, making it easy to review and reproduce procedures.
      • Supports SCP for secure file transfer between devices and your workstation.

    – ipcalc

    • Calculates subnet ranges.
    • Prevents mistakes caused by manual calculation and brings objectivity to team-based cross-checks.

    – winshot

    • Captures screen snapshots at intervals of at least one second and saves them automatically.
    • Useful for continuously recording control screens from various applications.
    • We primarily use it for Wi-Fi measurement and monitoring.
    • Captured images are compiled into files using PowerPoint macros.
    • Playback can be controlled freely with cursor keys (“forward” / “back”), and the sequence can also be converted into MP4.

    – Python Example (Gray Area)

    • In some cases, information such as a “list of risky IP addresses” is only obtainable via a GUI.
    • Snapshots are taken while scrolling through the interface, then processed with OCR.
    • As this falls into a gray area, the source code is not disclosed.

    IPSENDWIN
    It was convenient for sending and receiving packets with arbitrary MAC addresses and for crafting Layer-7 payloads. However, it appears the API signature has become invalid, and it can no longer be installed at present. It may still work on older versions of Windows.

    Tacacs.net
    Port forwarding on the PC side is required. It took some time before it became usable.

    WinMerge (command-line operation)
    Using command-line options, it is possible to perform high-speed comparisons of large numbers of files and obtain results efficiently.

    Failure Cases Observed in the Field

    • On Cisco devices, the default configuration may sometimes appear as follows:
    line vty 0 4
     login
     transport input none
    
    • In this state, CLI access over the network is denied.
    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`

  • Architecture Design Methodology for Enterprise Networks

    Architecture Design Methodology for Enterprise Networks

    Our enterprise network architecture design is based on measurable performance, vendor-neutral principles, and reproducible engineering methodologies.

    Rather than relying on vendor documentation or conventional design patterns, we define network architecture through empirical measurement, risk analysis, and multi-vendor validation.

    This methodology ensures that architectural decisions are technically justified, transparent, and resilient against long-term operational risks.

    Overview of Our Methodology

    Enterprise network architecture should not be defined by products or vendors, but by measurable requirements and engineering constraints.

    Our methodology consists of four core phases:

    1. Measurement
    2. Architectural Design
    3. Validation and Simulation
    4. Documentation and Knowledge Transfer

    Each phase is designed to eliminate assumptions and replace them with observable data and reproducible results.

    Overview of Our Methodology

    Enterprise network architecture should not be defined by products or vendors, but by measurable requirements and engineering constraints.

    Our methodology consists of four core phases:

    1. Measurement
    2. Architectural Design
    3. Validation and Simulation
    4. Documentation and Knowledge Transfer

    Each phase is designed to eliminate assumptions and replace them with observable data and reproducible results.

    Phase 1 – Measurement

    Before defining any architecture, we measure actual network behavior in production or test environments.

    Key metrics include:

    • Latency
    • Jitter
    • Packet loss
    • Throughput
    • NTP synchronization accuracy
    • Traffic patterns and protocol behavior

    We use packet capture tools, monitoring systems, and controlled test environments to obtain objective data.

    This phase ensures that architecture is grounded in reality rather than theoretical assumptions.

    Phase 2 – Architectural Design

    Based on measured data, we design network architecture independent of specific vendors or products.

    Key design principles include:

    • Vendor-neutral topology
    • Transparent firewall integration
    • Multi-WAN and overlay architectures
    • Multi-vendor redundancy
    • Scalability and fault isolation

    Architecture is defined before hardware selection, ensuring that design decisions are not constrained by vendor ecosystems.

    Phase 3 – Validation and Simulation

    Architectural design must be validated through reproducible testing.

    We verify architecture using:

    • Simulation environments
    • Controlled failover tests
    • Performance benchmarking
    • Packet-level verification

    Validation ensures that architecture behaves as expected under real-world conditions, including failure scenarios and peak traffic loads.

    Phase 4 – Documentation and Knowledge Transfer

    Architecture without documentation is not engineering but intuition.

    We provide structured documentation including:

    • Logical and physical topology diagrams
    • Design rationale and decision criteria
    • Risk analysis and mitigation strategies
    • Operational guidelines

    This documentation enables enterprises to maintain architectural independence from specific vendors and integrators.

    Why Measurement-Based Design Matters

    Traditional network design often relies on vendor best practices and reference architectures.

    However, enterprise environments differ significantly in traffic patterns, operational constraints, and risk tolerance.

    Measurement-based design replaces generic assumptions with empirical evidence, enabling architectures tailored to actual operational conditions.

    Vendor-Neutral Decision Framework

    Vendor-neutral architecture requires a structured decision framework.

    We evaluate technologies based on:

    • Performance characteristics
    • Interoperability
    • Operational risk
    • Long-term scalability
    • Vendor dependency risks

    This framework ensures that architectural decisions are driven by engineering logic rather than commercial incentives.

    Relationship to Enterprise Security Architecture

    Network architecture and security architecture are inseparable.

    Our methodology integrates security considerations from the initial design phase, including:

    • Transparent firewall deployment
    • Segmentation strategies
    • Redundancy across security layers
    • Multi-vendor security architectures

    This approach enables enterprises to enhance security without compromising architectural stability.

    Typical Applications of This Methodology

    This methodology is applicable to:

    • Large-scale enterprise WAN environments
    • Multi-vendor security architectures
    • Mission-critical network infrastructures
    • Organizations transitioning from legacy architectures
    • Environments requiring incremental modernization without service disruption

    Architecture as Engineering, Not Products

    We consider network architecture an engineering discipline, not a collection of products.

    Products change, vendors change, and technologies evolve. Architecture, however, defines the structural logic that persists beyond individual technologies.

    By prioritizing architecture over products, enterprises gain long-term stability, flexibility, and strategic autonomy.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`

  • Vendor-Neutral Enterprise Network Architecture and Security Design

    Vendor-Neutral Enterprise Network Architecture and Security Design

    We design enterprise network architectures based on measurable performance, vendor-neutral principles, and transparent cost structures.

    Unlike traditional system integrators, we separate architectural design from hardware procurement. This approach reduces operational risk, avoids vendor lock-in, and enables technically justified network decisions.

    Our methodologies are grounded in real-world measurements, reproducible testing, and multi-vendor architectural design.

    Design-Only Business Model

    In conventional enterprise network projects, architectural design and hardware sales are tightly coupled. This coupling often leads to vendor-driven decisions and opaque cost structures.

    Our design-only business model intentionally separates architecture from procurement. We focus exclusively on enterprise network architecture design, validation, and documentation, while clients procure hardware independently through vendors, distributors, or online marketplaces.

    From a technical perspective, this separation enables objective architectural decisions based on performance requirements, risk analysis, and scalability considerations rather than commercial incentives.

    As a result, enterprises gain transparency in cost, flexibility in vendor selection, and long-term architectural sustainability.

    Why Vendor-Neutral Architecture Matters

    Enterprise networks are often designed under implicit constraints imposed by specific vendors. While vendor-centric architectures may simplify initial deployment, they introduce systemic risks and long-term rigidity.

    Vendor-neutral architecture allows enterprises to evaluate technologies based on measurable performance, interoperability, and operational risk rather than brand or contractual relationships.

    Technically, multi-vendor architectures reduce single points of failure at the vendor level and mitigate the impact of vendor-specific vulnerabilities or supply chain disruptions.

    By adopting a vendor-neutral approach, organizations achieve higher resilience, greater architectural flexibility, and improved negotiating power in procurement.

    Transparent Firewall Architecture

    Traditional firewall deployments often require Layer-3 routing changes, which increase operational risk and complexity in existing enterprise networks.

    Transparent firewall architecture enables security enforcement without altering IP addressing or routing design. This approach minimizes disruption to production environments while improving visibility and control.

    From an architectural standpoint, transparent mode is particularly effective in large-scale enterprise networks where stability and backward compatibility are critical. It allows incremental security enhancement without fundamental topology changes.

    Consequently, enterprises can strengthen their security posture while preserving operational continuity and architectural simplicity.

    Multi-WAN and Satellite Overlay Architecture

    Modern enterprises increasingly rely on multiple WAN technologies, including fiber, mobile networks, and satellite connectivity such as Starlink.

    We design multi-WAN architectures where satellite links are integrated as overlay or underlay components within enterprise networks. This enables seamless failover, traffic engineering, and performance optimization across heterogeneous transport layers.

    From a technical perspective, overlay-based WAN design decouples logical network architecture from physical transport infrastructure, improving resilience and geographic diversity.

    As a result, enterprises can achieve higher availability and performance stability even under unpredictable network conditions.

    Performance Validation and Measurement

    Architectural decisions without empirical validation often lead to unexpected performance bottlenecks and operational issues.

    We evaluate enterprise network architectures using measurable metrics such as latency, jitter, packet loss, and NTP accuracy. Our methodologies involve packet capture analysis and reproducible testing environments.

    Technically, evidence-based design ensures that architectural choices are grounded in observable network behavior rather than theoretical assumptions or vendor documentation.

    This approach enables enterprises to make technically justified decisions with quantifiable performance characteristics.

    Limitations of Traditional SIer Models

    Traditional system integrator models often prioritize hardware sales and vendor partnerships over architectural optimization.

    This structural bias can result in over-engineered, costly, and inflexible network infrastructures that do not align with actual operational requirements.

    By separating design from procurement, enterprises can avoid vendor-driven complexity and regain control over architectural strategy.

    This shift transforms enterprise network architecture from a vendor-dependent implementation into a strategic engineering discipline.

    Typical Use Cases

    Our architectural design approach is particularly suitable for enterprises and organizations that require robust, scalable, and vendor-neutral network infrastructures.

    Typical use cases include:

    • Large-scale multi-WAN environments integrating heterogeneous connectivity such as fiber, mobile networks, and satellite links
    • Vendor-neutral security architectures designed to avoid vendor lock-in and systemic risk
    • High-availability network infrastructures requiring multi-layer redundancy at device, vendor, and transport levels
    • Performance-critical environments such as call centers, financial systems, and real-time communication platforms
    • Incremental security enhancement in existing networks without fundamental topology changes

    Why We Do Not Sell Hardware

    In many enterprise IT projects, system integrators generate revenue primarily through hardware sales and vendor partnerships. This business structure inevitably influences architectural decisions.

    We deliberately do not sell hardware. Our role is limited to enterprise network architecture design, validation, and documentation.

    By separating design from procurement, we eliminate conflicts of interest between technical optimization and commercial incentives. This allows architectural decisions to be driven purely by performance requirements, risk analysis, and long-term scalability.

    From an engineering perspective, independent hardware procurement enables enterprises to compare vendors objectively, negotiate pricing transparently, and avoid vendor lock-in.

    Ultimately, this approach transforms network architecture from a vendor-driven implementation into an evidence-based engineering discipline.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`

  • Forti-IPS capture results

    Links to example equipment setups and proof of success with capture results

    Forti-IPS Capture Results

    This page summarizes IPS-related packet capture observations and log evidence collected from a FortiGate device in a production-style inspection path. The goal is to document what was detected, why it was detected, and how to interpret the results without overreacting to background internet noise.

    What This Capture Proves

    An IPS capture is most useful when it answers three questions clearly:

    • What triggered? (signature name, severity, action)
    • What was the traffic? (protocol, direction, session behavior)
    • Was it real risk? (exploit attempt vs. scan/noise vs. false positive)

    This capture demonstrates that IPS detection can reliably identify suspicious patterns, but also that the majority of alerts on internet-facing segments are often reconnaissance or malformed requests rather than successful exploitation.

    Capture Scope and Method

    Inspection Point

    The capture was performed on the FortiGate inspection path where the IPS engine evaluates traffic between internal enterprise segments and external networks. The objective was to capture packets correlated with IPS events, then validate whether triggered signatures match actual malicious payloads or expected background traffic.

    Capture Data Types

    This analysis is based on a combined evidence set:

    • IPS event logs (signature, severity, action, session metadata)
    • Packet capture (header behavior, TCP state, payload structure)
    • Session context (source reputation patterns, repeatability, target exposure)

    Environment Summary

    Deployment Pattern

    The FortiGate device operates as a security gateway in an enterprise design where IPS inspection is applied to traffic that matters operationally. This is commonly seen in either edge protection or internal segmentation.

    • Edge firewall performing UTM inspection on inbound/outbound traffic
    • Segmentation firewall between user VLANs and critical server zones
    • Internet-facing services protected by policy + inspection

    Inspection Mode

    The IPS engine was configured using flow-based inspection mode, balancing performance with deep inspection. In this mode, signatures may trigger based on stream behavior and partial payload patterns rather than full file reconstruction.

    IPS Event Summary

    Common Categories Observed

    Triggered signatures can often be grouped by intent. This helps operations teams decide whether to tune, block, or simply observe.

    • Reconnaissance / Scanning (probing for open ports, service fingerprinting)
    • Protocol Anomalies (malformed headers, invalid field lengths, odd framing)
    • Known Exploit Patterns (payload fragments matching published attack signatures)
    • Automated Noise (generic scripts touching exposed services at scale)

    Severity and Action Interpretation

    FortiGate IPS assigns severity to help prioritize response, but severity should not be treated as “confirmed compromise.” A practical mapping for operations:

    • Critical / High: verify immediately, correlate with server logs and authentication events
    • Medium: check repetition and target relevance, confirm if it matches exposed services
    • Low: often informational anomalies, tune only if it creates operational noise

    Packet Capture Observations

    Typical Patterns of Internet Reconnaissance

    The packet capture shows behaviors commonly associated with automated scanning rather than targeted exploitation:

    • Short-lived TCP sessions with minimal payload transfer
    • Repeated connection attempts across sequential destination ports
    • HTTP requests with unusual headers or outdated client fingerprints
    • Repeated probing patterns from many unrelated source addresses

    These patterns are normal on publicly reachable services. The operational objective is not to eliminate all noise, but to ensure true high-risk events stand out clearly.

    Payload-Level Findings

    Where payload data was available, most triggers were consistent with signature pattern matches rather than confirmed exploit delivery. This is a common outcome when scanning tools reuse public exploit strings for fingerprinting without executing full exploit chains.

    If a signature triggers repeatedly but payloads remain incomplete or inconsistent, the most likely explanations are:

    • Automated scanning infrastructure testing for vulnerability presence
    • Malformed requests generated by generic scripts
    • False positives caused by uncommon but legitimate application behavior

    False Positives and Tuning Guidance

    When You Should Tune IPS

    Tuning is justified when IPS noise reduces visibility of real threats, or when a known legitimate application repeatedly triggers signatures. Practical tuning triggers:

    • Same signature firing continuously on a trusted internal application
    • Alerts cluster on a specific protocol feature that your application uses intentionally
    • Operational teams start ignoring alerts due to excessive volume

    When You Should Not Tune IPS

    Avoid tuning simply to reduce alert volume if the traffic is genuinely suspicious or if the service is internet-facing. Instead, prefer visibility improvements:

    • Log correlation with firewall, authentication, and server application logs
    • Source reputation checks and rate-based controls
    • Segmentation and exposure reduction for services not meant to be public

    Operational Recommendations

    Minimum Monitoring Set

    To use IPS evidence effectively, maintain these baseline operational checks:

    • Keep IPS signatures up to date
    • Track repeated triggers by source IP and destination service
    • Correlate IPS events with server-side logs (web access logs, auth logs)
    • Validate whether the destination is expected to be exposed publicly

    Incident Response Decision Points

    Escalation is justified when any of the following are observed:

    • Repeated high-severity triggers against a single host or application
    • Successful authentication events immediately after IPS alerts
    • Unusual outbound connections from the targeted server
    • Evidence of file drop, command execution, or abnormal process behavior

    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT are available here:

    View Network Architecture Solutions

    These patterns are derived from real enterprise environments and long-term operational experience.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`

  • Our original external design document

    Our original external design document

    We focus on clear, narrowly scoped engagements and do not pursue long-term,
    open-ended projects. Most work is measured in days rather than months.

    We do not apply markups on hardware, licensing, or third-party services.
    Hardware procurement remains entirely with the client.

    Prior to any contractual engagement, we are happy to discuss scope, feasibility,
    and design considerations at no cost, in order to avoid critical misunderstandings
    or unnecessary expenses.

    Our goal is not to maximize billable hours, but to deliver practical, well-defined
    designs that can be implemented efficiently and maintained sustainably.

    The number of valid solutions is limited.
    Therefore, several correct designs are prepared here in advance.
    You only need to select one—just like pressing a button on a vending machine.

    Proposed Solution 1: Transparent Mode Deployment

    Transparent mode: a Layer 2 switch that operates as a firewall.
    In practice, this means it can be deployed by simply inserting it into the existing path,
    without requiring any network redesign.
    In practice, this means it can be deployed by simply inserting it
    outside the existing edge router,
    without requiring any network redesign.

    This solution 1 assumes that customers procure hardware independently (e.g., via Amazon), rather than through our company.

    Because we charge only for design and engineering, the overall cost becomes more economical as the scale of deployment increases.
    Our design fees do not scale with the number of deployed devices.
    This makes large-scale deployments significantly more cost-efficient.
    This solution is particularly suitable for environments such as call centers,
    where a large number of WAN circuits must be deployed and managed.

    ***Observed behavior where probes generated by nmap are blocked
    (this does not constitute an official penetration test).***


    In a transparent mode deployment,
    our solution can be integrated by simply connecting it outside your existing router,
    especially in Wide Area Ethernet environments.

    We focus exclusively on design and configuration.
    Hardware procurement remains with the client;
    however, prior to any contractual engagement,
    we are happy to discuss suitable hardware options and deployment considerations,
    including different WAN technologies, redundancy designs, and single-device failure handling,
    at no cost.
    Proposed Solution 2: Benefits of Building a Redundant Firewall Architecture Using VRRP Across Different Vendors
    Disadvantages:
    When firewalls from different vendors are configured in a VRRP-based redundant setup, user traffic cannot be preserved when a failure causes the active firewall to switch to the standby device. Existing sessions are terminated and must be re-established after failover.

    Advantages:
    However, in situations where a firewall vulnerability is disclosed and immediate action is required, this approach allows traffic to be switched—within 100 milliseconds after issuing a failover command—to a firewall from another vendor that is not affected by the vulnerability. This represents a design approach that has not existed in past firewall architectures.

    Proposed Solution 3: Overlay-Based Satellite Internet

    Why L2VPN Is Required in This Design
    In environments where power-line stability cannot be guaranteed, relying solely on BGP convergence is not sufficient.
    L2VPN is therefore introduced to compensate for BGP’s slow convergence behavior.

    In this context, “overlay-based” refers to a logical network layer built on top of existing terrestrial or wired infrastructure, with satellite connectivity used as one of the underlying transports.
    In this model, satellite connectivity is treated as an underlay component of a large-scale L2 network, enabling higher-layer overlays to operate independently of the underlying transport.

    Due to licensing considerations, detailed implementation specifics are not included in this document. Additional technical insights will be published separately in a personal blog at a later stage.

    Web conferencing applications suitable for Starlink connections
    The system architecture is shown below.
    The diagram also includes the equipment used for performance validation.

    Jitter(Voice)

    NTP
    Why NTP?
    Throughput and latency alone cannot describe the true nature of a network.
    Satellite networks are not only fast or slow,but temporally unstable.
    NTP reveals this hidden instability.

    In conclusion, based on these test results, the only recommended web conferencing application is Google Meet.
    Even when reach remains stable,offset values fluctuate significantly.
    This indicates that Starlink connectivity is not unreliable, but temporally unstable.

    This evaluation is not intended to promote Starlink itself, but to clarify its characteristics as an underlay in overlay-based network design.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`



  • 100 IT Ideas, Unfiltered

    100 IT Ideas, Unfiltered

    **“Preventive measures for failures I haven’t actually experienced” also count as ideas, so I’m including them here.
    I’ve only written about forty so far, but I’ve decided to publish them anyway.
    —–
    050.How to open a file in Command Prompt when the entered string matches part of the file name
    for %f in (test) do start “” “%f”

    049.A command that launches WinMerge from the command line and visualizes the differences across a large number of files all at once
     WinMergeU.exe Filename01.txt Filename02.txt /ub /or HTML_Filename01.html

    048.VBA: Generate Excel Sheets from Common Filename Substrings

    047.Clear the contents of all sheets in a multi-sheet Excel workbook, including formatting

    046.Generate a VBA script in Excel that lists all sheet names

    045.Use a Large File Download from a Web Server for Network Failure Testing!
    After running failure tests on firewalls and load balancers,
    it sometimes turns out after the fact that TCP sessions were not actually being handed over correctly.
    This seems to be an issue limited to certain less popular models, such as “xx” and “yy.”

    If, during failure testing, you use file downloads from a Web server instead of (Ex-)Ping,
    you can detect issues before handing the system over to the server/application team.

    * If you set the top page of the test Web server to a large file (which you can generate instantly from the command prompt),
    accessing it will automatically start the download.

    * Record the recovery-time evidence with Wireshark.

    * You can do the same thing with httping, but since the SYN is sent only on the first request (meaning it’s treated as the same session), and the send interval cannot be set below 1000 ms, it may not be suitable for tight-interval testing.


    044.During failures, the fastest to recover is a static route (because you only need to care about the HSRP timers).
    However, after the system goes into operation, it requires someone who has all the IP addresses memorized—including their history and context.
    This increases operational dependency on specific individuals and raises the risk of personnel bottlenecks.

    If you delegate IP address management to a local generative AI system that sends no data externally, the disadvantages can be greatly mitigated.
    To put it bluntly, the greatest benefit is that all information is presented in clear, readable natural language.

    * When documenting recovery behavior, the Layer-1 keepalive should also be included among the timing parameters in the design documents.


    043.Is that power cable on the A feed or the B feed?
    All you need to do is connect the PLC to the A feed only and run a Ping.
    If you attach a DHCP server, you can simply check whether the client receives an IP address or not to determine the result.


    042.When checking for defective physical ports on a newly purchased switching hub,
    are you testing by plugging and unplugging a single LAN cable?
    There is a faster and far more accurate method.
    The answer is: write the code in TeraMacro.


    041.Do you really need those expensive Wi-Fi quality tests performed by external vendors?
    If all you need to confirm is the network-side quality, then verifying that the TCP/IP layer is performing adequately should be enough.
    In most cases, you can simply run a Ping test.
    * That said, our company does own several spectrum analyzers, so we can bring them on-site if needed.


    040.Automating network vulnerability testing—using an official .org tool (not some suspicious freeware)—
    wouldn’t it be great if all the data collection were finished overnight while you sleep?
    * It also reduces labor costs.
    (Although the analysis itself won’t be done overnight, the report can be generated automatically.)


    039.Wouldn’t it be convenient if you could bulk-replace contents in Excel
    (with up to 500 different patterns in a single run)?
    It’s possible with VBA—just one line of code per word.


    038.Wouldn’t it be convenient if you could extract only what you need from a large number of configuration files,and then open the file containing that string just by double-clicking?
    * This is done using the Japanese freeware “Sakura Editor.”

    If you’ve prepared the VBA code in advance,
    then all you need is: Alt+F11, F7, Ctrl+V, F5
    and if the code operates on all sheets, it’s even faster.
    It’s a shame there isn’t enough space here to explain it in detail.

    For everyday use, you can rely on things like:
    Ctrl+Page Up / Ctrl+Page Down,
    Ctrl+Arrow keys,
    Ctrl+Shift+Arrow keys,
    or Shift+Arrow keys ⇒ F2 ⇒ Ctrl+Enter
    the point is simply to reduce how often you touch the mouse.

    If you can shave just 1 second per task, then after 1,000 repetitions that’s 1,000 seconds saved.
    If you have 1,000 employees, that’s 1,000,000 seconds in labor costs reduced.
    And that’s before you even factor in the overtime pay premium.


    036.What exactly is “efficiency”?
    I personally call it “acceleration.”

    You can only estimate it in advance by intuition or experience,
    but I make a point of expressing and proposing it using concrete numerical gains
    such as “We can accelerate this by 100× to 1,000×”
    or “A 2–3× speed-up is achievable.”


    035.Since we all know it’s going to fail anyway—
    because obviously we’re about to fall straight into a trap—
    I sometimes say, “Why don’t we just have lunch first?”

    And of course, the one time that suggestion gets rejected is exactly when my bad feeling turns out to be 100% correct.
    It’s like the universe saying, “I tried to warn you, buddy.”


    034.Since it’s obviously going to fail—
    because we know we’re about to get stuck—
    let’s avoid any “one-shot, no-retry” attempts.

    You have to at least try everything you reasonably can and still fail;
    otherwise, people won’t feel any sincerity when you apologize.
    No “tragic backstory,” no credibility.


    033.Let’s prepare a standard template for failure-point diagrams ahead of time.

    Create a set of icons with numbered failure points,
    making sure there are no missing or duplicate numbers.
    Once that’s ready, you can simply cut & paste, and numbering mistakes won’t happen anymore.

    * And… if this very thread ends up having missing or duplicate numbers, my apologies in advance.


    032.The wages for the customer-facing team
    are probably higher than those of the technical team.

    Just one mistake on-site can cost an enormous amount of time and money.
    (And the people who end up apologizing are always the upper tier.)

    Have you ever calculated the impact of mistakes
    beyond your own team’s boundaries?


    031.Even a small team needs a profit plan.

    The profit plan you create right now is what will elevate your position in the future.
    Because building a profit plan for your current project
    is essentially the same as building a profit plan for your life.


    030.When your schedule slips,
    are you also calculating the labor costs of the teams behind you?
    Even if they’re just waiting around,
    their wages are still being paid.


    029.If possible, I’d rather avoid “instant kills” using knowledge and experience.
    When we don’t even know whether something is possible—
    when we’re on the edge and the client is on the edge—
    isn’t that what real collaboration with a customer looks like?


    028.Saying “Let’s start with what we can do” is a mistake.

    There are plenty of things that we can do but are meaningless.

    Instead, look for actions that actually matter
    and when you can’t do them, start thinking about how to make them possible.

    I believe that this kind of repeated effort is what creates overwhelming value.


    027.How do you make something possible?
    The first step is simply to decide that you’re going to do it.


    026.When you’re worrying that you “might not be able to do it,”
    just decide that you’ll pull it off anyway.


    025.Parameter sheets tend to get scattered across multiple Excel sheets.
    Why not generate them with VBA instead?

    The biggest advantage is that every parameter ends up aligned in a single column on a single sheet.


    024.When traveling for on-site work as an infrastructure engineer,
    book a hotel the night before—preferably near an electronics store.

    Most of them will at least carry USB–serial converters.
    They probably won’t have rollover cables, but you can usually find JJ adapters.
    They also tend to stock generic power adapters.


    023.When traveling for work, avoid taking flights late in the day.

    There was actually a case where a fire broke out near the airport,
    and the delay caused the flight to miss the destination airport’s operating hours,
    forcing the plane to turn back halfway.


    022.Why not at least submit the access request one extra day in advance?

    When your work runs late, when exactly will you file the access request for the next day?
    And even if you submit it first thing in the morning, what time will you actually be allowed in?
    Are you really going to wake up your manager or the prime contractor to rush the approval?

    Finishing ahead of schedule will always earn you a higher evaluation.

    021.Rather than clinging to field work, aim for a promotion sooner.

    In meetings, you can see and hear all kinds of incidents from the field—
    because trouble, of course, always happens out there.


    020.For active–active circuit redundancy,
    if your existing routers are Cisco,
    wouldn’t implementing GLBP basically solve the problem?


    019.Before saying “the circuit is slow,”
    there are a few things you should check.

    • Are you accidentally double-encrypting the traffic?
    • When you switched to a longer encryption key, do you know how much the MTU increased?
    • And are you thinking, “Well, the encryption got stronger, so of course the communication got slower”?

    —Are you sure that’s the right assumption?


    018.Besides bandwidth guarantees,
    do you know of any circuits that also provide an RTT guarantee?

    For remote-work environments, capacity alone isn’t enough.
    And to go a step further, OCSP is going to become increasingly important in the coming years.


    017.You—start using Wireshark.
    …Just saying it in my best Mas Oyama voice.(NOBUTATU-OHYAMA)
    A joke that works only in Japan.


    016.You—go back to your childhood and start playing walkie-talkie.
    (Not the metal-to-fiber media converters.)
    Here’s why:

    015.Getting used to one-way communication will improve your listening skills.


    014.During failure testing, I said “I’m not angry!” in the old KORIKI comedy style—
    and that’s when I felt a huge generation gap.
    It turns out younger engineers don’t know him at all.
    (A joke that works only in Japan.)


    013.I referenced the old “KIRETENĀI” razor commercial,
    and it completely fell flat in a field full of younger engineers.
    (It’s a joke that doesn’t land even with young people in Japan.)


    012.Sliding windows—and various keepalive-related source flows—often fall into the gap between the server team and the network team.
    Why don’t we, on the network side, just take ownership of them?

    Things will get resolved much faster that way.


    011.For your IPS or WAF,
    what destination are you allowing for signature-update DNS queries?

    If you’re permitting them using fixed destination IP addresses,
    you’re at risk of being left behind by the times.


    010.Whitelist-based web filtering can sometimes be a poor match for cloud services.

    As for the reasons and the solutions—
    I’m not going to write those here for free.
    (And yes, the Japanese phrasing forms a 5-7-5 haiku.)


    009.About the part where I said I wouldn’t write it for free—
    I felt a bit guilty, so I tried generating a “shōbai da mono” line using a Mitsuo-style generator.
    But I ended up losing the image.

    Do you know AIDA MITSUO? AIDA is not “Ada,” you know.


    008.With the growing adoption of HTTP/3 and QUIC,
    web filtering may eventually lose much of its effectiveness.

    When that happens, C&C (command-and-control) control will likely become the mainstream approach.
    Although, attacks that route through intermediate stepping stones will still be difficult to prevent.


    007.And that would mean routing methods that rely on DNS would also end up being restricted.

    As a result, we may start seeing more cases where
    Windows Update simply stops working
    all because the necessary traffic can’t get through.


    006.Translation in progress… Coming soon.

    005.Block attachments in Outlook that are not on an approved whitelist.
    The linked page is in Japanese.
    You should be able to read it by using your browser’s translation feature.

    004.Use show proc cpu and apply a binary-search approach to determine which process is consuming CPU.

    You simply change the ACL used for L3 processing:
    first set the first half of the ACL entries to deny and see if anything changes.
    If nothing changes, switch to denying only the second half,
    and repeat the process.

    003.Using Analog Noise Cancellers in Call Centers
    AI-based noise cancellation sometimes fails to remove the voices of people standing behind the operator.
    In such cases, an analog noise canceller that inverts the phase of the unwanted sound can be effective.

    002.Wi-Fi Troubleshooting
    I’ll include some notes about the time I measured weather-satellite signals.
    Yes, yes… that’ll be posted later, of course.

    001.Reflection:
    I used to think Ethernet signals were square waves.
    The reason for the misunderstanding?
    Because I actually tested it with my own hands.

    “`html

    Technical Inquiry

    If this article relates to your network architecture, security design, or infrastructure modernization, feel free to contact us.

    Email:
    contact@g-i-t.jp


    Related Architecture Solutions

    Typical network architecture solutions designed and implemented by GIT. These patterns are derived from real enterprise environments and long-term operational experience.

    View Network Architecture Solutions
    Back to Home

    “`