Cato Sockets integration with Nile

this document describes the steps to integrate cato networks socket x1600 sd wan applianc es in a redundant configuration with the nile service block (nsb) using bgp as the routing protocol the goal is a seamless integration between the nile access service and the customer’s extended network and internet, with ecmp style redundancy across four independent l3 transit links, similar to the velocloud design that uses four unique /30 subnets between nile and the sd‑wan edge prerequisites nile two nile gateways ( nsb gw1 and nsb gw2 ) are deployed in an active–active configuration ability to configure l3 interfaces and bgp on both gateways cato networks a cato site with x1600 sockets and administrative access to the cato management portal (network > sites > site configuration) cato site as number 65001 (cato asn) customer/nsb as number 65002 (peer asn on cato side) ip addressing four unique /30 point‑to‑point subnets for nsb–cato transit (example values used in this guide) 192 168 10 0/30 – nsb gw1 ↔ cato socket (native on gw1 port) 192 168 10 4/30 – nsb gw1 ↔ cato socket (sub‑interface) 192 168 10 8/30 – nsb gw2 ↔ cato socket (native on gw2 port) 192 168 10 12/30 – nsb gw2 ↔ cato socket (sub‑interface) routing design bgp is used between each nsb gateway and the cato socket over two parallel /30 links, resulting in 4 total bgp sessions and up to 4 equal‑cost paths for nile–cato traffic cato advertises a default route (0 0 0 0/0) to nsb; nsb advertises all nsb and downstream user subnets to cato topology two nile gateways connect to a single cato socket x1600 over dedicated lan ports each physical nsb–cato connection is split into two logical /30 networks (native + direct “sub‑interface”), giving four independent l3 transit segments h igh‑level topology traffic between nile gateways and cato uses all available /30 transit links if any link or gateway fails, the remaining bgp sessions continue to carry traffic ip and bgp design transit ip plan link id nile gateway cato network object subnet nsb ip (peer) cato ip (local) l1 nsb gw1 nsb gw1 (native) 192 168 10 0/30 192 168 10 2 192 168 10 1 l2 nsb gw1 nsb gw1 2 (direct) 192 168 10 4/30 192 168 10 6 192 168 10 5 l3 nsb gw2 nsb gw2 (native) 192 168 10 8/30 192 168 10 10 192 168 10 9 l4 nsb gw2 nsb gw2 2 (direct) 192 168 10 12/30 192 168 10 14 192 168 10 13 the cato side configuration reflects these as native and direct ip ranges for the nsb gw1/gw2 network bgp sessions on the cato side, configure four neighbors (one per /30) neighbor name nsb gw nsb asn (peer) cato asn peer ip (nsb) cato ip (auto from network) advertise accept nsb gw1 gw1 65002 65001 192 168 10 2 192 168 10 1 default route accept all nsb gw1 2 gw1 65002 65001 192 168 10 6 192 168 10 5 default route accept all nsb gw2 gw2 65002 65001 192 168 10 10 192 168 10 9 default route accept all nsb gw2 2 gw2 65002 65001 192 168 10 14 192 168 10 13 default route accept all additional bgp settings use metric 100 hold time 10 seconds keepalive interval 5 seconds md5 auth disabled cato socket configuration 1\ configure socket interfaces for nsb transit on the cato portal navigate to network > sites > your site > site configuration > socket edit the ports connected to nile gateways (e g , port 4 = nsb gw1 , port 5 = nsb gw2 ) for each port destination lan interface subnet (native range) nsb gw1 port subnet 192 168 10 0/30, local ip 192 168 10 1 nsb gw2 port subnet 192 168 10 8/30, local ip 192 168 10 9 dhcp disabled in the ui, this appears as editing the socket interface with a native /30 range and local ip on the cato side the socket interface for nsb gw1 is shown in the following images the socket interface for nsb gw2 is shown below 2\ define nsb transit networks and sub‑interfaces next, define the logical networks associated with these interfaces go to network > sites > networks under nsb gw1 , create/verify native range 192 168 10 0/30, local ip 192 168 10 1 (already created by the socket interface) direct range nsb gw1 2 type direct subnet 192 168 10 4/30 local ip 192 168 10 5 under nsb gw2 , create/verify native range 192 168 10 8/30, local ip 192 168 10 9 direct range nsb gw2 2 type direct subnet 192 168 10 12/30 local ip 192 168 10 13 3\ configure bgp neighbors toward nsb navigate to network > sites > bgp click new to add a bgp neighbor (figure 6) under general name nsb gw1, nsb gw1 2, nsb gw2, nsb gw2 2 (one neighbor per /30) asn settings peer 65002 (nsb asn) cato 65001 ip > peer set to the nsb ip on that /30 (192 168 10 2, 192 168 10 6, 192 168 10 10, 192 168 10 14, respectively) under policy advertise select the default route accept accept all leave perform hide snat unchecked (routing is handled via the transit /30s and nat policy separately) under additional settings metric 100 hold time 10 keepalive interval 5 md5 auth disabled (leave unchecked unless you configure matching md5 on nsb) repeat for all four neighbors so that the bgp summary table resembles the image below 4\ configure nat for lan to wan traffic if nsb traffic should reach the internet via cato’s breakout, configure a nat rule go to network > sites > nat create a rule similar to “nat to wan” match any source/destination/protocol (or constrain as needed) translated source ip the public or internal egress ip allocated by cato (example 10 1 250 177) 5\ configure bypass rules for nsb and nile sensor traffic to ensure nsb transit and nile sensor traffic is forwarded as pure l3 routed traffic (not subject to additional inspection or optimization within cato cloud pop), configure bypass rules go to network > sites > bypass under source , define objects such as nsb transit – covering the 192 168 10 0/27 or equivalent aggregate for all four /30s nsb subnet – the nsb internal subnet(s) nile sensor subnet – sensor ip ranges leave destination empty or default, so these sources are bypassed regardless of destination configuring bgp on nsb gateways nsb gateways will mirror the four neighbor bgp design, and this configuration is currently performed by nile support please reach out to our technical support team to configure ebgp peering with the cato sockets self service configuration through the nile portal will be available soon verification on cato in network > sites > bgp , verify all four neighbors are in the established state and learning prefixes from nsb (user/nsb subnets) confirm that the cato routing table shows nsb prefixes reachable via all four transit networks on nile gateways check bgp neighbor status for all four cato peers (192 168 10 1, 5, 9, 13) verify that the nile routing table has four ecmp default routes via the nsb–cato transit interfaces no unintended routes from cato (if you filter to default only) end to end tests from a client behind nsb, ping a resource reachable via cato (e g , an internet host or cato‑connected site) shut down individual nsb–cato links (e g , disable one socket port or nsb sub‑interface) and confirm traffic continues via remaining bgp sessions if using the nat to wan rule on cato, verify that egress traffic from nsb appears sourced from the configured translated ip