Listen, Subscribe & Follow:
Our ongoing IPv6 Basics series continues with an episode on v6 routing essentials. We start with a comparison of various routing protocols: RIP, OSPF, IS-IS, EGP, and BGP. We look at pros and cons of each, and discuss challenges such as dual stack IPv4 and IPv6 network implementation, memory and resource use with IPv6, and link local addresses.
Episode Links:
Multiprotocol Extensions for BGP-4
Cisco’s Enhanced Interior Gateway Routing Protocol (EIGRP)
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
Episode Transcript:
This episode was transcribed by AI and lightly formatted. We make these transcripts available to help with content accessibility and searchability but we can’t guarantee accuracy. There are likely to be errors and inaccuracies in the transcription.
Automatically Transcribed With Podsqueeze
Ed Horley 00:00:06 Welcome to the IPv6 Buzz, where we dare to dive into the 128 bit address space wormhole. I’m Ed Horley.
Nick Buraglio 00:00:11 And I’m Nick Buraglio. We discuss everything IPv6 on the show from strategy, design, deployment, operations, and even internet standards.
Tom Coffeen 00:00:20 And I’m Tom Coffeen. We’ve spent 20 plus years working with the IPv6 protocol. We work on getting IPv6 working.
Ed Horley 00:00:26 And we’re here to share some lessons learned and how to avoid common mistakes. We’re glad you joined us. Today. We’re going to continue our IPv6 Basics series. And this time we’re going to be talking about routing, finally getting around to a topic that probably a lot of folks have been expecting. So let’s just jump into it. I guess the biggest thing would be talking about differences in what routing protocols are supported in v6. So maybe we start there just in terms of the basic strategy for folks there, probably, you know, many shops are probably running OSPF or they’re running maybe if they’re a legacy Cisco shop, they’re running EIGRP.
Ed Horley 00:00:55 Many folks are probably running BGP in some capacity. So let’s just break down routing protocols and talk about what’s supported in v6 and what isn’t. So. Who wants to take on the list?
Tom Coffeen 00:01:04 I mean, if you’re brand new to the whole domain, you may be relieved to hear that there aren’t any unique IPv6 routing protocols unless you’re running a low power lossy network and have to use ripple. But that’s a topic probably for another day. So yeah, if you’re already familiar with EIGRP, you’re already familiar with OSPF, BGP, of course, whatever routing protocol you’re familiar and comfortable with, there’s a version of it that supports IPv6 and pretty broadly across most platforms so that you’re not having to reinvent the wheel when it comes to routing IPv6.
Ed Horley 00:01:31 Yeah, I guess the old school, you know, back in the day when you’re learning your v4, probably the first routing protocol you learned was probably RIP.
Tom Coffeen 00:01:39 That’s right. And with any luck, RIPv2.
Ed Horley 00:01:41 And that is reflected in IPv6. There’s a RIPNG, as was back in the day when IPv6 was called Next Generation. So the RIP protocol took on that name space. So RIPNG is what’s utilized in IPv6.
Tom Coffeen 00:01:53 We shouldn’t neglect to say how cool that sounds. And then of course, how cool it kind of actually isn’t because it’s RIP but RIPNG, RIPNG. RIP Next Generation makes it sound pretty adventurous, but you know what? It still has applications, right? I mean, there’s still scenarios where you might imagine using RIPNGg.
Nick Buraglio 00:02:08 I have used RIPNG in production.
Tom Coffeen 00:02:11 There you go, I knew it.
Nick Buraglio 00:02:13 It’s the first real routing protocol that a lot of people that are of our vintage probably ever played with. You turn it on, it just does its thing right. Routing by rumor. It’s just there. It operates pretty much exactly the same. But I think one thing that, you know, sort of caught me when I was doing v6, you know, when I started learning v6, I was at a service provider. Right. And service providers typically routed IP, right. However, the places that I had come before that, now I’m dating myself.
Nick Buraglio 00:02:41 And this is a concept that, like I learned very early on that other engineers of later vintages probably never had to learn was that, you know, before I was routing only IP, I was at places that routed IP. IP was just one of the things that got routed right. There was Apple Talk and there was there was a lot of IPX SPX right. Because you know, large Novell Netware constellations in a lot of enterprises, that what it used. And then you may have other sort of fringy things like DECnet and some other SNA other things in there, but the concept of it being just another thing on the wire, I think changes the way that you think about routing. Right. Because those things are just ships in the night and they don’t know that the others exist. And that’s sort of the concept that you have to think about if you’re moving from single stack IPv4 to dual stack IPv4 IPv6 is that now you have these two things that they don’t necessarily know that each other exists, you know, from a routing domain.
Nick Buraglio 00:03:39 But you need to like as an engineer, you need to understand that, you know, they both exist on the wire. And because they don’t necessarily know that each other exists, they just coexist together. Their topologies might be different. I realized I went way into the deep end really fast there.
Tom Coffeen 00:03:56 Well, and then of course, you can get into the weeds and find yourself in a bad place in that regard, because there are ways in which you can configure some of the routing protocols so that there is fate-sharing between the address families in a way that it would be probably more optimal for a lot of network environments if they are truly ships in the night and they’re truly different SPF calculations and truly separate link state databases and that sort of thing. But it gets kind of muddy depending on what routing protocol you’re looking at and how it’s configured. You know, you can end up with single topology mode, where IPv4 and IPv6 are sort of stuck in the same boat together as opposed to being ships in the night.
Ed Horley 00:04:31 Yeah, ships in a lane.
Tom Coffeen 00:04:32 Yeah.
Nick Buraglio 00:04:33 Now we’re talking about ATM.
Ed Horley 00:04:37 Yeah. But besides RIP getting back to our original sort of breakdown on protocols, I mean, I guess the other next obvious one is OSPF, OSPFv2, OSPFv3 is what we utilize for v6. So I think for the audience version three is what you would use for IPv6. You would run both version 2 and version 3 more than likely in most scenarios. It is possible, as Tom just mentioned, to run sort of a combination. I don’t know if I would do that for OSPF, but you can get yourself in a bit of trouble. And not all vendors are supporting sort of that combined mode for OSPF, which means that you might even have additional problematic configuration and topology issues to work through because of the type of peering that you want to set up. And so for that sort of configuration, typically normally just recommend that OSPFv3 run on its own for IPv6 as a dedicated routing protocol.
Ed Horley 00:05:25 And more than likely, you’re probably going to set all your cost factors for your interfaces the same and do all the work so that the topology is actually match. Even though there might be running two instances of Dijkstra, you’re going to be having different sets of calculations based off of the fact that a link may or may not be going up or down at any given moment in time, but the two would be running in parallel to each other. And I guess this is a good time to sort of mention this. This is where the cost of running dual stack becomes more expensive, because you’re obviously running two instances. You’re using more memory for hosting, routing protocols, state tables, etc. everything down the road. You’re just using more resources to make that happen. That can be a negative. That could be a downside depending on what your resource requirements are within your given network. So there we click out to RIPNG, OSPFv3 I guess the next logical one down the list. Maybe we hit BGP next.
Nick Buraglio 00:06:13 Or do we want to stick with the IGPs and talk about IS-IS.
Ed Horley 00:06:17 We can talk about IS-IS and the EIGRP if you want. Yeah I mean IS-IS is interesting because it’s maybe a logical extension of where OSPF come from right. In terms of just routing protocols. And well, maybe enterprises are going to see more IS-IS over the intervening years here. It seems to be gaining a little bit in popularity in terms of use cases. And certainly, you know, behavior wise, there are some conveniences for IPv6 in regards to how IS-IS behaves. And back to Tom’s point about single topology mode versus multi topology mode configurations. IS-IS is, I guess, a primary example of one that gives you the ultimate flexibility to sort of set it up any way you want, or any way that might mess up your network, depending on what you’re up to. So I guess we could break it down a little bit, I don’t know. Does it make sense to talk about the difference between single topology modem multi topology in terms of what IS-IS thinks about stuff, because it really doesn’t care as much about the IP protocol portion.
Tom Coffeen 00:07:10 Right. Or layer three for that matter.
Nick Buraglio 00:07:12 Before we go into that, the reason I brought it up is because that’s what I work in most of the time. I’m much more familiar with that at this point than I am with OSPF. One of the bigger advantages is IS-IS has I consider to be an advantage or a difference. Let’s just call it a difference, right? Because it depends on your perspective. You know, one of the differences is that it doesn’t care. The routed protocol is essentially you know, it’s a TLV. It’s a plug in for the routing protocol. So it can carry whatever you want it to carry. It carries v4 as a TLV. And then you can add IPv6 into it. You run one instance of it essentially you know that and its scaling are sort of the two, I think big differences than from OSPF. You don’t necessarily historically see a lot of IS-IS in you know, in enterprises, they typically are more OSPF shops. IS-IS because of the scaling, tends to be more of the, you know, service provider based protocol.
Ed Horley 00:08:04 There’s a little bit more flexibility with IS-IS in terms of topology configuration right.
Nick Buraglio 00:08:08 Oh for sure.
Ed Horley 00:08:09 OSPF is limited to that area zero construct. Right. And so we have to do all sorts of weird things to break out of that. And I’m not going to cover any of that in the show because it’s not specific to v4 or v6. Right. That’s a OSPF property.
Nick Buraglio 00:08:22 Yeah. And also I think there’s a N Is For Networking podcast that goes into some detail about that.
Tom Coffeen 00:08:27 I do think it’s worth backing up from that, you know, avoidance of getting into the detail in the weeds related to IS-IS versus OSPF, but just asking the question from an architectural standpoint, what are you trying to accomplish regardless of whether it’s v4 or v6? You know, so like from a design perspective, there’s nothing really compelling about any of the differences that would necessitate picking one over the other because you’re using v6. Rather, if you’re in an enterprise environment where you’re considering going to OSPF or you’re considering going to IS-IS from OSPF, you probably have very specific reasons related to your architecture and how you’re managing your topology, and that should be sort of decoupled from the address family question of, you know, is it IPv4 IPv6 because how it’s configured and how it’s actually going to operate under the hood, there’s really just not enough of a difference to really talk about.
Tom Coffeen 00:09:11 So yeah, I think we deal with a lot of enterprise shops, and I think there’s always that sort of question that they’re aware that they’ve gotten over the first hump of like, you know, there’s nothing unique about the routing protocols where IPv6 is concerned, but they’re not really over the second hump where it’s like, well, do we use IPv6 as an excuse to make architectural or topology changes that, you know, we’ve been putting off in v4, you know, for any number of reasons, complexity, of course, the first of them, probably the risk of renumbering and the pain associated with that. But I think that’s something that as a sort of abstracted meta question, is the bigger and more important point, why are you choosing the routing protocol that you’re choosing? What problem is it solving for you or not solving for you? And, you know, is there an advantage to moving to a different routing protocol, regardless of whether it’s a v4 or v6 topology?
Ed Horley 00:09:52 Right. I think a lot of people use v6 as that opportunity to make that change, because of the fact that you’re having to go through a pretty major transformation network change anyway.
Ed Horley 00:10:00 So they’re using that pivot to go ahead and do that. But I agree it should match what your design requirement needs are from a routing protocol basis, and not necessarily about what address family if you have anything to do with.
Nick Buraglio 00:10:10 Yeah, I agree with that. I’ve seen that happen. You know, where that’s been used to change over from OSPF to IS-IS. Implementing v6 is sort of the catalyst for that. But I think that, you know, at the end of the day, what you should use is sort of what solves your problem that you can support and afford.
Ed Horley 00:10:26 I I’ve seen something similar from EIGRP to OSPF, just from moving from a, you know, single vendor supported routing protocol to something more universal standards based, simply just to be able to get away from sort of vendor lock in. Related to that, I understand, you know, EIGRP has changed in terms of that and there’s open standard support for it. But that doesn’t mean that everyone’s developed it or has support within their product family to do anything with it.
Tom Coffeen 00:10:47 So but it’s still surprising to me that we do go into enterprise shops, big enterprise environments where EIGRP is the hill they’re going to die on, and not without good reason based on their experience with it and how they operate it and use it. So.
Ed Horley 00:10:58 Yeah, it’s still the best for DMVPN. I’ll consider that one. It’s better than BGP. It’s better than OSPF for those particular design considerations, at least in my humble opinion. For someone who has deployed a lot of it.
Nick Buraglio 00:11:11 I’ll use this as a fess box here and confess that I’ve literally never used EIGRP outside of like when I was studying some of the Cisco exams 20 plus years ago. Never used it, couldn’t even tell you how to configure it.
Ed Horley 00:11:25 It’s a pretty, very straightforward. One of the things that people really love is it’s a two command line option to turn it on and get it working.
Tom Coffeen 00:11:32 The summarization on the interface is really powerful too.
Ed Horley 00:11:34 Yes, yes, that is the thing that everyone really loves about EIGRP.
Nick Buraglio 00:11:39 That is cool.
Ed Horley 00:11:40 So it definitely has its advantages in terms of how that works. So but we can leave the diatribes around the advantages for EIGRP to Russ White and company. To chat back and forth and figure that out. But I guess this is a good time as any to just mention that EIGRP does support IPv6, just as EIGRP was always designed as a multi routing protocol positioning tool for Cisco to be able to get into the market for routing everything right. SNA, IPX, SVX, IP. It supported pretty much everything across the board, which I think was one of the advantages of it very early on in its development. And so I think that’s one of the things that’s sort of unique about it. Out of all the routing protocols that we sort of chatting through. But yeah, you can totally do v6 with theEIGRP. I don’t even think they do a version number for differentiation. I think it’s just EIGRP and that’s it.
Tom Coffeen 00:12:28 Your v6 routes can be stuck in active just like your v4 ones can.
Ed Horley 00:12:32 I guess that leaves us on the workhorse of the internet, right. Which we trickle down to BGP and.
Tom Coffeen 00:12:37 Which many have argued is not even a routing protocol anymore. It’s just an application. Right?
Ed Horley 00:12:41 It’s a standardized interface application for data exchange.
Nick Buraglio 00:12:46 Yeah. What did Greg Ferro call it? He called it garbage can of the internet. You just throw everything into BGP.
Ed Horley 00:12:52 Yeah we can make new extensions BGPMP right.
Tom Coffeen 00:12:55 Yeah that’s right. He said you wanted extensibility. Here’s your extensibility.
Ed Horley 00:12:59 Here it is.
Nick Buraglio 00:13:00 Yeah yeah. It wants to drink from the firehose.
Ed Horley 00:13:05 That’s you probably have all figured out v6 works just fine over BGP. There’s some interesting combinations of things that you can do with BGP. Because you can pass v4 routes across v6 links. You can pass v6 routes across v4 links, v6 routes across the v6 links, v4 routes across v4 links. It’s a pretty flexible application to be able to do this sort of stuff, and fundamentally I don’t see people doing anything strikingly different around BGPv4 versus v6.
Ed Horley 00:13:31 I think the standard behaviors and patterns that you use for BGP today for IPv4 match a great deal in terms of what you do with IPv6. Maybe the core set of differences have more to do with maybe a more thoughtful address plan. So it might change your perspective of summarization. It might change how you tackle bogon lists and things of that nature. But those are more operational issues than design issues, I would say. And so I think just in terms of behavior wise, BGP is going to act like BGP and you’re not going to be super surprised by what you see. I think that’s a fair statement.
Tom Coffeen 00:14:02 I think that’s all correct. There’s the additional wrinkle maybe of dealing with link local addresses as next hops. And you know BGP. You can always get wrapped around the axle with next hop fun with the next hop where it is if it’s reachable that sort of thing. And then how you’re going to manage your configuration based around, you know, v4, you don’t think about it because it’s just a v4 address in the opposite end of the link, with v6, you have to be cognizant of the link local address and what you’re using to peer with and what the next hops are set as a result of that.
Nick Buraglio 00:14:28 That’s also true. That actually just brought up a thought in my mind that for protocols like OSPF, you know, when you’re doing v4 or OSPF v2 for IPv4, you have to have addresses configured, you know, on the point to point links. And they use the protocol that they’re routing, you know, essentially for communication. Right. With v6 you can do it only with link local with OSPFv3, and I’ve actually renumbered a wide area backbone in the middle of the day, the v6 part of it, and no one even knew it happened because no adjacencies flapped. It uses link local for all of the communications and those v6 addresses that are added to the point to points that you see, they’re essentially there for troubleshooting purposes and to make them show up right in traceroute, things like that. That’s a distinct difference, I think, is that, you know, the link local addresses have, you know, they do have a significance in certain ways. And like you said, Tom, they can also bind you up a little bit if you’ve got next hops that aren’t right or, you know, you just have to understand the nuances there.
Ed Horley 00:15:29 I guess we could shift gears and talk a little bit about the second attribute about routing, which is building routing tables. Right. And saying that you’re going to see link local addresses in your routing tables for the vast majority of these routing protocols. And because link local is a legitimate next hop for many of them, you’re going to see next hop link local addresses. And there’s probably tips and tricks and techniques that you can use to be able to make your life a little bit easier in terms of understanding where traffic is actually going, maybe embedding things like router IDs or some other useful piece of metadata related to the link local addresses, which is why you might want to actually set up your link local addresses explicitly, versus just letting them build UI64 or SLAAC in some manner. Yeah, to get a little bit more metadata that helps you sort of determine where traffic is going, although obviously you can just look up your neighbor peer and, you know, sort of determine what’s going on there. And then I guess secondarily, there’s some other common routing attributes that folks use around ACLs to be able to filter stuff.
Ed Horley 00:16:24 And I think the other common one that I see that’s in use is sort of on the Cisco side is some sort of more complex inverse masking. Right? And that stuff just really doesn’t exist in v6 and any practical way that you can make use of it. Although I’ve heard rumors that there’s plans to try and make that stuff available, but I haven’t seen any implementations that actually make use of that. So just realize if you’re doing sophisticated routing stuff where you’re actually using inverse maps for the purpose of controlling routes, may not be a tool in your tool belt in the same way that it was in IPv4. I haven’t seen a lot of people do that recently. I think v4 address space has gotten so bifurcated and split up that it’s not as easy to do some of this type of summarization that we typically see as being more useful. And so you end up writing ACLs that are a lot more specific around, you know, end node addresses versus necessarily weird octet configurations to try and figure out who’s doing what, where.
Ed Horley 00:17:17 But, you know, v6 isn’t going to be reflected in the same way. So I just make mention of that. It’s obviously not a routing thing per se, but it is something that’s sort of routing adjacent. Right.
Tom Coffeen 00:17:27 Well, and sure, and especially with BGP where you’re, you know, you’re doing a lot of prefix lists and a lot of route maps and that sort of thing. You know, you really need to know what the the options are in terms of how you’re filtering things. And I mean, it’s not like back in the old days where you had to do reverse masking to really drill down on the BGP prefix lists and greater than, less than flags make it pretty easy to get granular with that stuff now and with a minimal amount of configuration, but it is a consideration. And to your point, yeah, we just don’t have inverse masking or wild card masking and v6. I hope they don’t re-add it. Please.
Nick Buraglio 00:17:57 Yeah. Please don’t.
Tom Coffeen 00:17:57 Please. Let’s keep it simple. That’s right. And then consider off into the distance, please.
Ed Horley 00:18:07 I’ve heard some rumors that there’s consideration of writing code to do that.
Nick Buraglio 00:18:11 Well, they should, they should keep considering and then decide not to.
Ed Horley 00:18:14 Yeah. Yeah, yeah. Well, you know, I don’t know what Nick’s complaining about. I’m sure he can write some Perl that does the same thing. So.
Nick Buraglio 00:18:23 Oh boy. He, I wrote some C the other day you know.
Nick Buraglio 00:18:29 Another thing that I think is maybe important from the routing perspective is that since we’re talking about BGP, there’s a big move to make BGP more secure. And you know, have it be more deterministic and standard across the way people are operating and implementing it. And you know, the tooling out there to do that for things like building prefix lists or route maps or what have you off of the IRR data. Those exist for v6 as well as v4. So tools like BGP Q3 and you know, some of the other tooling that you use to the IRR toolkits and stuff like that, they’re sort of mostly agnostic that, you know, they just pull the things out that are reported in those public databases, and they can build the protocol that you ask for.
Nick Buraglio 00:19:14 Those things exist. So if you’re used to using those for v4, say, you know, you’re new to v6 and you need to turn it up for your company, but you also control the BGP, you can use some of those existing tools like you’ve already been using them. That’s nice that way that you don’t have to go and do something different. It’s all pretty uniform across the board as far as the routing toolkits go for building that stuff and automating it.
Ed Horley 00:19:37 Yeah, that’s a good point. I guess the secondarily, we should also mention that the routing registry components and the new signing stuff v6 is fully supported and all of those from all the RARs. So if you need to do the announcements and control whose AS is advertising and what prefix. And you know you want to have it signed and you want to have all that other goodness. So you can do that for both v4 and for v6. It’s supportive for both. So it’s not like there’s anything weird going on where v6 is the more wild west than the v4 side or vice versa.
Nick Buraglio 00:20:06 No, it’s it’s pretty uniform across the board at this point, which is really nice.
Tom Coffeen 00:20:11 I guess just to get into just a little bit of the configuration detail around BGP for folks that are super new to it and haven’t turned up any v6 peering sessions and that sort of thing, there’s a lot of address family verbiage or a.
Ed Horley 00:20:23 Good point.
Tom Coffeen 00:20:23 Well, you know, it’s maybe tricky to navigate the first time you’re dealing with it, you know, and like thinking specifically in a Cisco environment and sort of the hoops you have to jump through to activate v6, you know, versus not activating the prefix in v4 that you’re peering over, that sort of thing, just the configuration gotchas that sort of exist there. But really I’m thinking more of the higher level, which is, you know, you have the option, as you mentioned at the outset, when we first start talking about what we haven’t actually even named, which is multiprotocol BGP right. You have the option of v4 carrying your network layer reachability information for either protocol inside the other protocol.
Tom Coffeen 00:20:57 Right. But we should really put it out there very assertively that you don’t do that. Typically I’m not taking my NRLI in v6 and stuffing it in v4 or vice versa. You know, I’m avoiding the sort of fate sharing that might come about from that if it’s not properly planned. Yeah, because there’s no benefit just having a standalone peering session that’s over v6, where all the NRLI is carried for v6 is carried over for v6 and vice versa for v4. That’s the preferred configuration, you know, as far as I’ve seen it. And I wouldn’t want anybody to get sort of wrapped around the axle trying to guess what they’re supposed to do. And they’ve got all these address family options.
Ed Horley 00:21:28 Yeah, that’s a good point. Keep it simple stupid is still a good principle.
Nick Buraglio 00:21:32 Yeah. And as someone who has kind of gone through that, like I’m like, I want to carry everything in v6 and I’ve done it right. I put it all back. Right? Because at the end of the day, I want to have those isolated. I want that failure domain to be small, the shininess of doing it any other way didn’t outweigh it.
Ed Horley 00:21:50 I always look at as operational consideration if you can leave the v4 skill sets and expertise the way they are so that they understand everything they’re looking at, and also within the configuration files of the devices they’re managing, if they’re only touching the v4 related portions of it, you’re reducing your exposure for failures and errors versus if they’re having to work inside of v6 with v4 inside of v6, they’re still working inside of v6. They can make mistakes within that v6 portion and then potentially bring down both sides, which is problematic. And you’re introducing more risk for little gain from an operational perspective I think is probably the principal portion.
Tom Coffeen 00:22:27 Absolutely.
Ed Horley 00:22:27 To Tom’s point, you need to design and think about this. It is a little different. Dual stack is going to be a little different for certain use case scenarios. You may be sharing the exact same circuit from a L1 L2 perspective, but you’re running BGP peering for v4 over it, and then a separate BGP peering for v6 over that exact same link.
Ed Horley 00:22:45 Perfectly acceptable assuming that your provider is willing to set up and configure it that way. You might be forced to do something differently depending on what they do or do not support. And you don’t necessarily have control over that, which is why you have as many geek knobs available to you in BGP as you have, is because of those use case scenarios. And just realize that probably the standard is let’s keep them separate. Let’s run them as two separate ships in the night so that we understand what’s going on. And you know, the fate sharing is really down at the link level of like, okay, the interface is either up or down. Layer two is either up or down. And that determines whether our circuit is either up or down right at any given moment. And I think that’s probably not that the show should really be about best practices, but I think that fits in the category. Probably some good hygiene, best practice around IPv6 for routing anyway, for at least building BGP neighbor peers. And that probably holds true for pretty much any of the routing protocols across the board, I would probably do it something similar.
Nick Buraglio 00:23:35 Yeah. It also gives you the advantage of since they are separate, you know, like if you’re thinking about it from, say, you’re not an enterprise, say you’re a service provider and you want to do something eventually like IPv4 as a service. When all of those peerings are separate, they’re very easy to shove into an L3 VPN and it just becomes
Ed Horley 00:23:54 virtualized.
Nick Buraglio 00:23:55 Yeah. You know, create an overlay that’s only v4, and everything under it is what’s carrying it as v6. It allows you that flexibility of, you know, the modularity. But something else that you brought up, Tom, is that in certain platforms, you know, if you’re new to it, the show command structure maybe slightly different. If it’s an older platform where v6 was added to a legacy code base, you know, you may need to add the IPv6 or IP6 or Inet6.
Ed Horley 00:24:21 And nor is it consistent about where that appears within the the list order.
Nick Buraglio 00:24:26 That’s what I was getting at, is it may not be the same per protocol. It may not be the same per different show command within the same protocol. So you may have to use question marks your friend.
Tom Coffeen 00:24:36 Yeah. Context sensitive help is definitely your friend. Yeah. Don’t expect it to save you from. We’ve all sort of ingrained the fact that the parser and the like a vendor like Cisco and IOS is trying to accommodate sort of the OSI model in some ways, you know, like try to keep your order of commands related to where in the stack you kind of are. And of course, that breaks down with v6 because it’s like, do the BGP come first or the v6 come first? And I can’t remember. And every time I look it up I forget like 30s later.
Ed Horley 00:25:02 And that’s why you write shortcuts.
Nick Buraglio 00:25:05 Yeah. And then one of your boxes is XR and it’s totally different than all the other ones.
Ed Horley 00:25:09 Yep.
Tom Coffeen 00:25:10 Yeah.
Ed Horley 00:25:11 Let’s not even dive into NX-OS.
Tom Coffeen 00:25:12 So we’re talking about routing obviously, but don’t get us started on talking about where the flags and router advertisements are all hidden.
Ed Horley 00:25:18 Oh yes.
Tom Coffeen 00:25:19 What context you have to be ending to, you know, turn one flag off or another one on. It’s oh my God, I have to look it up every time.
Ed Horley 00:25:25 Yes, it’s a good point. Well, I think we covered the major items for routing protocols. I don’t know if there’s any other highlights that we want to talk about for dual stack environments. So is there anything else that we think is.
Tom Coffeen 00:25:37 Not necessarily dual stack, but just to the question of what routing protocol you should be running in v6. And we mentioned, you know, you may be looking for an excuse to go from OSPF to IS-IS. I don’t hear often of people going in the other direction, but I guess anything’s possible. But something that we didn’t mention explicitly, maybe enough, is that there’s definitely the advantage of working with the routing protocol that you’re most familiar with, you know, and so if your shop is like really steeped in OSPF, that’s what you know. And that’s, you know, your all of your troubleshooting chops really built around that.
Tom Coffeen 00:26:05 There’s a lot of inertia there that would potentially prevent you from moving to a new routing protocol. And IPv6 wouldn’t really be a good reason just to do it. You know, it’s like, well, we’re going to do it just because we’re moving to IPv6. It’s like, well, you’re going to be starting from scratch per se. A lot of the same general concepts apply. But, you know, we all know what it’s like. It’s like you’re familiar with what you’re familiar with in your operating environment, and how much more efficient that is at troubleshooting and getting to the bottom of problems and that sort of thing. So I just wanted to make that additional point. It’s like you’re not moving to a new protocol just because of v6, especially if you’re getting an operational benefit from what you really know well and what you can troubleshoot really well. And v6 isn’t going to change that.
Nick Buraglio 00:26:39 Very good point. Since we’re talking about routing, do we want to talk about especially in dual stack environments you know TCAM considerations for if you’re going from single stack to dual stack what you need to remember about, you know, hardware resources.
Ed Horley 00:26:53 Yeah. We can certainly bring it up. I mean it’s something we’ve mentioned on previous shows, but I think it’s good to sort of highlight that dual stack does cost you more from a resource perspective, and it can cost you in terms of real world physical capacity within a platform. And obviously your routing tables have to get populated someplace in order to make forwarding decisions. I think your FIB impacts are going to impact what your TCAM looks like within a given platform, assuming that it’s hardware accelerated forwarding, right, that’s going on and you’re not just dealing with the giant software router, which could care less because that’s just memory at that point. So yeah, if you are making use of TCAM or whatever the next hardware replacement of TCAM is, I can never remember the name of it, but there’s a next generation of sort of memory structure that’s designed to replace TCAM. And yeah, you need to be aware that the fact that automatically IPv6 is going to chew up four times as much memory just to store a singular full address than a v4 address.
Ed Horley 00:27:45 If we assume that we stop at a /64 boundary, which is one of the reasons why we advocate for 64, you’re still using twice as much and assuming that you have pre allocations, most of the manufacturers have pre allocations that they do. Then when you turn on v6 is going to pre allocate a certain amount of address space in order to try and build some efficiencies into how it distributes stuff. And then you have to go in and decide if that allocation, that assumption they made is accurate for your environment. And then the other thing is, if you actually go from dual stack to single stack, are you going back and recovering your TCAM, or did you leave it, you know, configured as a mixed mode IPv4, IPv6, and you didn’t switch back to v6 only and give you all the capacity back that you really need? I don’t know, what else do we need to talk about? I mean, it’s just a shared resource. Even though it’s a ship the night from a routing protocol perspective, you are stuck sharing memory, right? Yeah, yeah, it’s really what it comes down to.
Nick Buraglio 00:28:35 Yeah, I wanted to bring that up. This is probably not really an issue as much anymore. But on older platforms where, you know, you would enable IPv6 and you’d start taking routes. The error mode when you would essentially run TCAM out is like one log, and then you never see another log again. And there’s a cryptic command to check to see if your it’s been, you know, in violation. Just your performance stinks. So I just wanted folks to realize like, hey, you know, when you’re adding something in, you also need to understand that you’re sharing now.
Ed Horley 00:29:05 Yeah. And I understand you can’t control the discard eligibility that goes in for the TCAM. It’s just pretty standardized is like oldest is purged first and relearning is required after that. And that’s what ends up so you can have a tremendous amount of churn, especially if you have environments that have a lot of clients that are changing over, yeah, dramatically. I mean, if you’ve got a pretty fixed set of assets in a data center or something, even with TCAM constraints, you’re probably going to be, you know, maybe, okay, but you definitely want to check and do your homework and make sure if you’re above 50% utilization on your TCAM today for IPv4, the moment you turn on IPv6 and want to support the same number of routes, you’re going to run into problems, right? So that’s just a given because you’re going to have the same number of hosts.
Ed Horley 00:29:46 So you’re going to be dealing with the same structural space. So just realize that you want to sort of optimize around that. And that’s a really good point. I don’t know if there’s any other gotchas that fit in there except for maybe logging and maybe really mentioning very, very quickly. I won’t go into details. Feature parity versus functional parity. You don’t have to worry about getting your log files directed over IPv4 IPv6. I don’t know if that really matters because they can both carry, you know, v4 related routing topology information, v6 related routing topology information and logs and errors and etc., etc.. Right. So for the most part you’re going to have functional parity sort of across the board for what you need. And if you really need feature parity, most of the routing protocols have full feature parity today for everything that you need to do. So this is not really an issue. So just for those that are nervous or trying to figure that out, that’s something that you can sort of check off the list and not be as nervous about.
Ed Horley 00:30:35 Definitely. Still check in the lab. Make sure it performs the way you want. You should always be checking everything in the lab anyway. You shouldn’t be trusting us just from listening to us on a podcast. What the heck do we know? Yeah, yeah, but that’s one of the things I would also mention. All right, let’s wrap it up, you guys. Favorite routing protocol and why?
Tom Coffeen 00:30:51 Well, I’m not going to say it’s ripple because I haven’t really used it.
Ed Horley 00:30:54 It’s the most widely deployed routing protocol though, right? I think it’s the most widely deployed routing protocol that no one knows about because it’s just used in massive mesh networks. Right. So.
Tom Coffeen 00:31:03 And I’m not going to say that we’ve got the EIGRP advocates out there. I’m going to disappoint them. Nothing wrong with it. It works really well. I’m not going to say OSPF could maybe say IS-IS, but I’m going to have to go with BGP and multi protocol BGP.
Ed Horley 00:31:15 Okay. So Tom chose an application.
Tom Coffeen 00:31:17 Because it’s freed us from the tyranny of just routing.
Ed Horley 00:31:23 Nick what’s yours?
Nick Buraglio 00:31:23 Oh I’m going to go the same because I can run as an IGP. I can run it as an EGP. It carries everything I wanted to carry and I know what the best. So I would go with BGP.
Ed Horley 00:31:34 Tom and Nick are into the multifunctional tools. I’ll just stick with my single hammer that works really well. I’m still enamored with what EIGRP could do. So I’ll say it’s still a super useful tool for folks that are in that camp. And if they can actually get more wide common support, I think there’s a bunch of use cases where it actually works insanely well for enterprise deployments. So I’ll just leave it there. But, all right, especially after suffering from so many OSPF outages for area zero problems. Living through those. All right everyone, thanks so much for joining. We’ll catch you the next one. Thanks for joining us for this episode of IPv6 buzz. If you’ve got feedback or follow up on this topic, send us a message at packetpushers.net/FU where FU stands for follow up, we’d love to hear from you and continue the conversation.
Nick Buraglio 00:32:18 Also, at packetpushers.net you’ll find a range of other deep dive technical podcasts for IT pros.
Tom Coffeen 00:32:24 There’s a whole lot more on the Packet Pushers site as well, such as tutorial videos and a community slack channel where you can talk with industry peers and experts. So whether you’re deep in your career or just starting up, Packet Pushers is the place to go to grow both your skills and your personal network.
Ed Horley 00:32:38 So long. And until next time, we’ll see you on the IPv6 internet.
Share this episode
