cool, makes sense. thx.
Most large P/PE routers are no longer TCAM based.
exact match or not it’s all done in hardware so I would expect the difference in processing time to be negligible. again though I haven’t bothered to do any research (might dig into it a bit tomorrow) so I could easily be wrong.
Usually, yes. This one is more to the point though. Makes it easy for the fresh-out-of-college engineers at work.
And MPLS in particular is one case where knowing a lot about the implementation doesn’t tell you much about how it’s used.
I feel like this would be expensive for an enterprise trying to implement MPLS on infrastructure that is less than adequate. I would imagine if your enterprise is large enough that it can benefit from MPLS you would most likely already have the equipment in place to handle it. And any modules that are required would be way cheaper than more devices. This is just a thought so correct me if I’m wrong.
Also, what are the licensing costs associated with MPLS?
I’m reading the RFC doc now. I can see the great amount of complexity that goes into this. Luckily I’m not looking to implement it right now and I’m just trying to understand it. Haha
I may be misunderstanding the question, but if you’re running tunnels between your sites and you want a full mesh of tunnels, you’ll need a full mesh of tunnels.
I’ll piggy back on this and mention this is very similar to the advantage that OpenFlow gives existing switching hardware: turn the switches in to efficient routers by taking the advanced processing required for layer 3+ packet inspection and pushing it to separate computational devices. You can use your knowledge of existing TCP/IP topology to configure the switching behavior, but not incur the overhead of processing the packets on the switching devices.
Also, i should point out that, say you have:
A-1-2-3-B
where A and B are customer routers, and 1,2,3 are carrier routers.
1 and 3 are MPLS edge routers and 2 is one (or a collection) of interior routers, all running MPLS.
Routers 1 and 3 have todo some work as packets enter or leave the MPLS domain; they look at protol routing information, source and destination information, and port information, and then either assign or remove MPLS tags.
I.e. router 1 adds a “2944” tag to an incomming packet and hands it to router 2. Router 2 sees 2944 and automatically knows where to send the packet in one single table lookup. It will remove the 2944, replace it with a 1333 and hand it to router 3. Router 3 sees 1333, strips the tags, and hands a non-mpls packet to router B.
I for one welcome our new DRAM-array overlords.
What do they use for fib storage then?
They wouldn’t sell the router if it didn’t perform reasonably well, sure. But you’re paying for the custom silicon to do prefix matching, and you pay more for a bigger routing table. Using labels means that you can handle bigger networks using less silicon because the label hides the details of what prefixes are behind it. The bottom line is more performance (and less power/heat, as haakon666 points out) for your money.
Well, that’s the nature of reality. I’d hope you’re right, that a place that could benefit from MPLS had the infrastructure already in place and could just as easily upgrade the IOS and make the configuration changes. But reality is dictated by budgets…
As for licensing costs? I couldn’t tell you, I don’t really get list prices on things…educational discount.
Here’s what I understand: with an MPLS L3VPN I could have a full mesh, where all sites can speak to each other without going through a central hub, and the traffic which flows from CE to CE (over the provider network) is not encrypted.
The question is, how to encrypt it? All the encryption examples I’ve seen involve applying ipsec to some kind of GRE tunnel or the like. Since I already have the MPLS network, I already have some kind of segregated network so my thinking is that the need for an additional level of tunneling is removed?
Is it as simple as just applying some crypto-map to the interface? I’m looking at a Cisco IPsec guide and one of the commands specifies the peer of the map – if the MPLS is fully-meshed, then IIRC this would require N*(N-1)/2 configurations.
The next question then, is whether there is there a way to do it dynamically, where I just have the interface encrypt/decrypt everything going out of/in to it, and if so, how?
I worded that crappily. I was wondering if there were any licensing costs associated with MPLS specifically or if you were referring to the licensing costs associated with other functions on devices. Not what it actually costs.
I second this guy, many enterprise networks that I’ve worked on did not have the gear necessary to implement MPLS which hindered our ability to segment our network, meaning we had to implement VLANs and VRF lite to route network traffic differently, however this meant having different IP address spaces in the core network for each VRF which was not the best I must admit, but did allow us to segment traffic.
Sorry, encryption isn’t my thing; we own our fibre, so it’s not really an issue.
If you’re hooking into your own VRF in a MPLS L3VPN, your traffic is already segregated from everyone else’s; the only people sniffing it are going to be your provider (and the government, and law enforcement). Whether you then build the (as you correctly note) n*(n-1) encrypted tunnels you need to build an encrypted full mesh comes down to what your security needs are (though if you’re going to do that, why pay any premium associated with getting an L3VPN service; you may as well just tunnel over the internet).
If your router doesn’t have the Advanced IP services IOS loaded on it, then that would be a cost of upgrade. Most routers come with the IP Base IOS.
though if you’re going to do that, why pay any premium associated with getting an L3VPN service; you may as well just tunnel over the internet
That’s the perspective I have too; this is just a thought experiment considering how to achieve this goal, regardless of whether it’s needed or not.