Hands-On Tail-F Experience on Software Gone Wild
Tail-F NCS implements one of the most realistic approaches to service abstraction (the cornerstone of SDN – at least in my humble opinion) – an orchestration system that automates service provisioning on existing infrastructure.
Is the product really as good as everyone claims? How hard is it to use? How steep is the learning curve? Boštjan Šuštar and Marko Tišler from NIL Data Communications have months of hands-on experience and were willing to share it in Episode 22 of Software Gone Wild.
HSRP AWARE PIM
In environments that require redundancy towards clients, HSRP will normally be running. HSRP is a proven protocol and it works but how do we handle when we have clients that need multicast? What triggers multicast to converge when the Active Router (AR) goes down? The following topology is used:
One thing to notice here is that R3 is the PIM DR even though R2 is the HSRP AR. The network has been setup with OSPF, PIM and R1 is the RP. Both R2 and R3 will receive IGMP reports but only R3 will send PIM Join, due to it being the PIM DR. R3 builds the (*,G) towards the RP:
R3#sh ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Continue reading
DMVPN Dynamic Multipoint VPN
DMVPN is dynamic, scalable and easy to configure Cisco specific VPN solution. DMVPN uses two major technologies for its operation : NHRP Next Hop Resolution Protocol mGRE Multipoint GRE In this post I will explain all the basics of DMVPN. For detailed routing protocol design over DMVPN will be covered in different post which will… Read More »
The post DMVPN Dynamic Multipoint VPN appeared first on Network Design and Architecture.
Musing: Who Cares About FCoE in 2015 ?
While I continue to scratch my head about who is foolish enough to actually deploy FCoE, perhaps a more important question is which vendors care about it ?
The post Musing: Who Cares About FCoE in 2015 ? appeared first on EtherealMind.
Birth of the virtual mainframe?
For this week’s blog, I wanted to share some perspective on technology transformation, over a time span of 20+ years – thisExperimenting with the CSR1000v REST API
This all started because we occasionally want to block traffic from an IP address or two for a short time. Our firewall is a pain to configure for this sort of thing: adding a drop for a single IP address literally takes 10 minutes. You have to open a fat client, create an object, add the object to a group, save the config, verify the config, push the config, etc.I thought that SRTBH (Source-based Real-Time Black Hole) implemented by BGP would be the ticket: fast, easy, and theoretically easy to automate with the REST API in the Cisco Cloud Services Router 1000v. SRTBH is a simple and elegant way of dropping selected traffic on BGP speaking routers. In a nutshell:
- You configure a "trigger router" that speaks iBGP with the rest of your BGP-speaking routers (usually your Internet edge or transit routers), but doesn't participate in traffic forwarding.
- On each edge/transit router you configure a static route to null0 for an unused /32, usually 192.0.2.1: ip route 192.0.2.1 255.255.255.255 null0
- On each edge/transit router you configure loose-mode unicast RPF filtering on your outside interfaces: ip verify source reachable-via any. Continue reading