Cisco UCS: Crossing the Streams
Apparently you can cable the A-side Fabric Interconnect to the right IOM in a chassis, and it works just fine. You can even look at the DCE interfaces on a VIC in this chassis and see that the paths have been flipped: This is not true for the “correctly” cabled chassis, where the A-side traces occupy the first two slots: The first two interfaces will always go to the left IOM because the backplane traces are cabled that way.IPv6 with A10 Load Balancers
So I got to do some honest IPv6 related work at the job the last 2 weeks. One task was to verify we had IPv6 working on the load balancers to hosts behind it. I was a bit wary of the state of IPv6 security on these A10 LBs, so I opted to keep the globally routed IPv6 space on the LB’s uplink interface, and the VIPs. And behind the scenes, use ULA.
Step 1: I generated a /48 of ULA for the location, and assigned a /64 for use on the VLAN that the inside interface of the LB sits on with the servers themselves.
Step 2: Configure ::1/64 on the LB inside vlan interface, and ::2/64 on a server, and verified that they could reach each other.
Step 3: I installed lighttpd on the server and configured it to listen on the ULA address.
Step 4: From my ARIN allocation, I have a /64 reserved for configuring /126s on device links to the router, so I configured it on the LB’s dedicated interface on the router. Using ::1/126 on the router; ::2/126 on the LB’s interface; ::3/126 as the VIP.
Step 5: Create on the LB an “IPv6 Continue reading
Hot,Cold, Mash Potato Routing and BGP Route Reflector Design Considerations.
If someone tosses you a hot potato, do you want to hold it a long time? If you like pain maybe the answer is yes – but how many of us like pain? In the same way, hot potatoes are very applicable to the Service Provider environment. When a service provider receives a packet, if […]
Author information
The post Hot,Cold, Mash Potato Routing and BGP Route Reflector Design Considerations. appeared first on Packet Pushers Podcast and was written by Orhan Ergun.
MPLS VPNs and Junos config groups: a match made in router heaven
Introduction If you manage MPLS VPNs on Juniper Networks devices running Junos (or are learning about doing so), this tip should make your life easier. I can’t imagine operating MPLS VPNs on a scale of more than a handful of VPNs without it. Below I’ll describe how it works, and then to make sure it’s […]
Author information
The post MPLS VPNs and Junos config groups: a match made in router heaven appeared first on Packet Pushers Podcast and was written by Nik Weidenbacher.
IPSec Bandwidth Overhead Using AES
Someone asked so lets walk through the overhead introduced when using IPSec with AES; it’s higher than you might think and I haven’t even factored in ISAKMP. Encryption really isn’t ‘my bag’ so if anything is wrong, do let me know; hopefully public scrutiny will mean I can truly rely on these figures. Take a […]
Author information
The post IPSec Bandwidth Overhead Using AES appeared first on Packet Pushers Podcast and was written by Steven Iveson.
Not-Via? Not-What?
In our last episode (it’s been two weeks!), we talked about P’s and Q’s. Now we’ll get down into a few details, and think through what is probably the simplest mechanism ever designed for finding alternate loop free paths through a two connected network: not-via. Let’s use the embedded network as an example. In this […]
Author information
Show 164 – Cool or Hot? Lapukhov + Nkposong’s BGP SDN
On this Packet Pushers podcast, hosts Ethan Banks and Greg Ferro are joined by Petr Lapukhov for a discussion about his IETF draft on BGP SDN, co-authored with Edet Nkposong. Guests Russ White and Ivan Pepelnjak also join in the discussion, quizzing Petr about the details of the draft and how implementation has worked out thus far […]
Author information
The post Show 164 – Cool or Hot? Lapukhov + Nkposong’s BGP SDN appeared first on Packet Pushers Podcast and was written by Ethan Banks.
IPv6 multicast over IPv6 IPSec VTI
IPv4 IPSec doesn’t support multicast, we need to use GRE (unicast) to encapsulate multicast traffic and encrypt it. As a consequence, more complication and an additional level of routing, so less performance. One of the advantages of IPv6 is the support of IPSec authentication and encryption (AH, ESP) right in the extension headers, which makes […]
Introduction to Open vSwitch
In the early days of my quest to cut through the jungle of hype regarding SDN, it was difficult to go a single day without hearing about Open vSwitch, or OVS. I’ve been tinkering with Open vSwitch in my lab for a few months now, and realized that I haven’t yet written an introductory post about it for those that haven’t tried it out. If you’re involved with data center like I am, you’re probably familiar with the concept of a vSwitch.Introduction to Open vSwitch
In the early days of my quest to cut through the jungle of hype regarding SDN, it was difficult to go a single day without hearing about Open vSwitch, or OVS. I’ve been tinkering with Open vSwitch in my lab for a few months now, and realized that I haven’t yet written an introductory post about it for those that haven’t tried it out. If you’re involved with data center like I am, you’re probably familiar with the concept of a vSwitch.OSPF Adjacency Building Process
Ever curious regarding how two routers configured for OSPF become fully adjacent? The following diagram of the process was modeled directly from RFC 2328, and the steps described gleaned from the Routing TCP/IP Vol I book. Since we can see mention of a DR, this example must be based on a multi-access network.
- RT1 becomes active and sends a Hello. At this point, RT1 hasn’t seen any neighbors, so it reports such and sets its DR and BDR fields to 0.0.0.0.
- Upon receipt by RT2, RT2 will build a data structure for RT1 and set RT1’s state to Init. RT2 will then send a Hello packet reporting that it has seen RT1, and will report itself as the DR.
- RT1 now sees its own RID in the received Hello packet from RT2, so RT1 will now create a data structure for RT2 and set its state to ExStart. RT1 then begins Master/Slave negotiation with a DD packet with a sequence number of “x”, the Init bit set to indicate that it is the start of an exchange, the More bit set to indicate that it is not the last DD packet to Continue reading
Quiz #19 – Short Network Cuts with MSTP
As a senior network administrator, you receive complaints from server team that yesterday there were multiple short network cuts that impacted some very sensitive applications running in the data center. You investigate and find out that one of the level 1 network engineers performed some network changes. What went wrong?
Product & Routing Webinar: Multicast
Packet Design will be hosting a Product & Routing Webinar focused on Multicast on Wednesday, October 23 at 3pm CST. The event will feature Matt Sherrod, VP of Product Management, as its key speaker and will leave time after the live demonstration for Q&A.
OVSDB Echo in Python
I don’t mind coding in Java (i.e. OpenDaylight) but I wanted something quick and easy, so I’m writing a utility-esque script that sacrifices extensibility for speed. And since Python is something I’ve been meaning to stretch my muscles in, I decided to throw this together. Keep in mind that this can all be done by ovsdb-client natively via Linux command line, but I wanted to write it in Python to learn it, as well as provide it for a cool (technically) cross-platform language.OVSDB Echo in Python
I don’t mind coding in Java (i.e. OpenDaylight) but I wanted something quick and easy, so I’m writing a utility-esque script that sacrifices extensibility for speed. And since Python is something I’ve been meaning to stretch my muscles in, I decided to throw this together. Keep in mind that this can all be done by ovsdb-client natively via Linux command line, but I wanted to write it in Python to learn it, as well as provide it for a cool (technically) cross-platform language.OSPF Link State Advertisements (LSAs) and Areas – Part II
For a table describing the different LSA types, check out the first post of this series.
In the first part of the series, we looked at LSA Types 1, 2, and 3 – Router, Network, and Network Summary, respectively. To move on to the next two LSA types, we need to bring in another Autonomous System (AS). In the diagram below, we’ve added R5 which has an interface in EIGRP AS 1, and is redistributing that into OSPF Area 4. The fact that R5 has an interface inside of the OSPF AS, as well as the EIGRP AS, makes R5 an Autonomous System Boundary Router (ASBR).
The EIGRP-oriented subnet that is being redistributed is considered an external route to the OSPF domain, so a Type 5 LSA, or ASBR External, is flooded into OSPF Area 4 containing a LSID and netmask of the subnet, plus the External Type. This important because it tells other routers whether or not to add the internal link costs within the OSPF domain to the metric to reach that subnet. A type 2 external route specifies that only the external cost is taken into consideration.
When R2 catches wind of Continue reading