No Response from vxlan flannel tunnel to pods requests
Hello All, I have a small setup of one LTM VE v14.0 (SDN and advanced routing license enabled). I am trying to integrate it with a kubernetes cluster version 1.10 . I followed the documentation for creating a vxlan tunnel to Flannel, and also have ran the big-ctrl on k8s. The problem I have is, from pods I can reach the big-ip vxlan tunnel interface and I can see the traffic by tcpdump on vxlan interface. However, no response is getting off big-ip !. Any support on how to debug this is really appreciated. I can provide any command output needed.
Which SDN protocol is right for you?
SDN's biggest threat is all us people talking about it!! In a recent article titled something along the lines of "Which SDN protocol should I use?", I found myself totally confused... Not the same kind of confused as entering a turnstile in the southern hemisphere (did you know they spin the other way down there). No, I found myself wondering if any of us can agree what SDN is. A common comparison that has me scratching my big, shiny head is OpenFlow versus VXLAN or NVGRE. This is like comparing a Transformer (the shapeshifting robot, not the power supply) and a family sedan. What do I mean? Well, if you squint your eye's really hard and look at them from a long way away, then yes, there a small realtionship (both have wheels), but they do such very different things. VXLAN and NVGRE are encapsulation protocols. They don't provide "programmable flow instantiation", which is what OpenFlow does, and that is SDN. If we are to label VXLAN and NVGRE as SDN, then we must also accept that older encapsulation protocols are SDN, too. For example, 802.1q VLAN tagging, GRE, etc. It pains me to even make this suggestion. Lets say I put the Oxford English Dictionary down for a moment, while I climb off my high horse, and we do loosen the SDN term to include non-OpenFlow programmable flow instantiation (I prefer to call this simply "Programmable Networking"), then this still doesn't include encapsulation protocols for there is no programmable element to them. May I humbly suggest that dynamic routing protocols are closer to SDN than encapsulation protocols? At least dynamic routing procotols do alter flow in packet forwarding devices! That said, I would then have to add Advanced ADC’s to the mix as they evaluate real-time state (performance/security/app experience) and use this to make constant, flow-altering decisions. This example is even closer to SDN than dynamic routing... its just not using OpenFlow. I'm all for abanoning the SDNacronym altogether. Its broad uses are far too ambigious, and with ambiguity comes confusion, followed shortly by fear and uncertainty. That's it. I'm taking a stand. SDN has been struck from my autocorrect!!F5 Synthesis: Virtual Network Fluency
#SDAS #SDN #Virtualization Like moving to IPv6, simply picking up your existing network architecture and moving it to a completely new one is not going to happen overnight. There will undoubtedly still be "traditional" networks hanging around even when SDN adoption is considered mainstream and fully mature. That's the nature of evolution; it doesn't happen in the blink of eye, it takes time. Right now organizations are faced with a variety of options in networking. From VXLAN to NVGRE, from traditional to software-defined, choices abound today. And chances are that most largish networks will actually take advantage of several of those choices, depending on what phase of adoption they're in. That means heterogeneous networks; or hybrid if you want something shorter and easier to type. What makes this a nearly untenable arrangement is that applications may be deployed atop two discrete (and not necessarily interoperable) networks and yet need to communicate, and applications still have to be delivered via the appropriate set of L4-7 services to assure available, performance and security. Which means interoperability challenges may impede adoption of specific SDN-related technologies. But if we apply the same principles as virtualization and cloud computing - namely that of abstraction - to the service layer we can achieve interoperability and advance the adoption of SDN-related technologies without nearly as much trouble. That's one of the benefits of F5 Synthesis, specifically its High Performance Service Fabric. All Networks are Created Equal The service layer of a data center architecture is able to abstract applications from the underlying network technology and ensure interoperability when it can act as a sort of network gateway. That is, it can translate between the different network architectures, effectively enabling applications on VXLAN virtual networks to communicate with applications residing on NVGRE virtual networks, or across traditional, VLAN-based networks. Synthesis v1.5 brought with it a lot of updates and changes, and one of those was around virtual networking. Synthesis 1.5 offers full NVGRE and unicast VXLAN support, and enables the High Performance Service Fabric to act as a virtual network gateway. This capability means Synthesis can insulate application architectures from the impact of a heterogeneous network - whether by way of a transitory step to a full SDN-enabled network or as the intentional end result. Applications can easily be deployed on one, then migrate to another and even another network, without disruption to the L4-7 services critical to their delivery. This capability enables an agnostic approach to the architecture of the L4-7 service infrastructure with respect to the network. F5 Synthesis is focused on delivering the Software Defined Application Services (SDAS) critical to the security, availability and performance of applications no matter what type of network may be in use. To that end, all networks are created equal and Synthesis' High Performance Services Fabric will continue to support them all, which means less disruption as organizations transition to or through a heterogeneous network environment.
