SoftLayer’s Founder Aims to Build a Security-as-a-Service Powerhouse
Another startup, but this one claims 30,000 customers.
snaproute Go BGP Code Dive (5): Starting a Peer
Last time we looked at the snaproute BGP code, we discovered the peer bringup process is a finite state machine. With this in mind, let’s try to unravel the state machine into a set of calls, beginning from our original starting point, a debug message that prints on the screen when a new peering relationship is established. The key word in the debug message was ConnEstablished, which led to:
func (fsm *FSM) ConnEstablished() {
fsm.logger.Info(fmt.Sprintln("Neighbor:", fsm.pConf.NeighborAddress, "FSM", fsm.id, "ConnEstablished - start"))
fsm.Manager.fsmEstablished(fsm.id, fsm.peerConn.conn)
fsm.logger.Info(fmt.Sprintln("Neighbor:", fsm.pConf.NeighborAddress, "FSM", fsm.id, "ConnEstablished - end"))
}
From here, we searched for calls to ConnEstablished, and found—
func (fsm *FSM) ChangeState(newState BaseStateIface) {
...
if oldState == BGPFSMEstablished && fsm.State.state() != BGPFSMEstablished {
fsm.ConnBroken()
} else if oldState != BGPFSMEstablished && fsm.State.state() == BGPFSMEstablished {
fsm.ConnEstablished()
}
}
Looking for ChangeState leads us to a lot of different calls, but only one that seems to relate to establishing a new peer, as evidenced by a state that relates to established in some way. This, in turn, leads to—
func (st *OpenConfirmState) processEvent(event BGPFSMEvent, data Continue reading
Featured Interview: Sonus’ Kevin Riley Discusses Cloud-Based Communications
Kevin Riley, senior vice president of engineering and CTO of Sonus Networks, shares his insights on cloud-based communications.
Vestberg is Ousted as Ericsson CEO
Caught between 4G and 5G.
Unregenerate – The Week Gone By or To Come – 20160725
Looking backward at last week or forward into next week.
The post Unregenerate – The Week Gone By or To Come – 20160725 appeared first on EtherealMind.
Brocade & Ericsson Support the White House’s 5G Group
Fund will help supplement private R&D budgets.
ONF Completes Second Wireless Transport SDN Proof of Concept
ONF promotes commercial adoption of SDN.
Inside NFV Performance Techniques
The combination of new network hardware acceleration techniques and SDN is driving a new era of networking.
Operationalizing Micro-segmentation – NSX Securing “Anywhere” – Part III
Welcome to part 3 of the Micro-Segmentation Defined – NSX Securing “Anywhere” blog series. This installment covers how to operationalize NSX Micro-Segmentation. Be sure to check out Part 1 on the definition of micro-segmentation and Part 2 on securing physical workloads with NSX.
This blog covers the following topics:
- Micro-segmentation design patterns
- Determining appropriate security groups and policies
- Deploying micro-segmentation
- Application lifecycle management with vRealize Automation and NSX
- Day 2 operations for micro-segmentation
Micro-segmentation design patterns
Micro-segmentation can be implemented based on various design patterns reflecting specific requirements. The NSX Distributed Firewall (DFW) can be used to provide controlled communication between workloads independent of their network connectivity. These workloads can, for example, all connect to a single VLAN. Distributed logical switches and routers can be leveraged to provide isolation or segmentation between different environments or application tiers, regardless of the underlying physical network, as well as many other benefits. Furthermore, the NSX Edge Service Gateway (ESG) can provide additional functionality such as NAT or load balancing and the NSX Service Insertion framework enables partner services such as L7 firewalling, agent-less anti-virus or IPS/IDS applied to workloads that need additional security controls.
Figure 1: Leveraging the DFW to provide Continue reading