Comments for vpls.us http://vpls.us Who, What, When, Where, Why VPLS? Tue, 02 Oct 2012 21:41:34 +0000 hourly 1 http://wordpress.org/?v=3.4.2 Comment on vpls versus mpls vpn by TimC http://vpls.us/?p=183&cpage=1#comment-385 TimC Tue, 02 Oct 2012 21:41:34 +0000 http://vpls.us/?p=183#comment-385 Applications suiting VPLS versus MPLS. Well, considering that VPLS runs over MPLS, (at least in most cases). It's kind of a chicken and an egg thing. For VPLS to operate it needs MPLS. However that doesn't mean that from the customers perspective that the behaviour would be any different. From the Customer perspective, he is either sending a layer 2 packet and doing the routing to the end node himself, or he is taking advantage of the MPLS VPN routing of his traffic and sending it into the provider as a layer 3 packet. (Note that in both cases he his mostly likely sending it to the provider as layer 3. In VPLS it ignores the layer 3 header, and in MPLS VPN it looks at the header. The Layer 2 method is going to involve more overhead, because the end nodes are going to have to broadcast for address resolution and the like, they are also most likely going to be exchanging some layer 2 BPDUs, however the Layer 3 complexity at the layer 2 model is a lot less. It probably doesn't have to keep larger routing tables. (Depending on the design of course). Where as the Customer CPE will have to have a larger routing table, and be running a routing protocol. As for applications, well the only thing that I can think of that would be handled differently between the two types of networks would be multicast based applications. Where the layer 2 multicast would use multicast frames for distribution into to the network, and if the network had some sore of multicast snooping it would restrict or reduce the amount of multicast traffic that would be going to every location. With the Layer 3 VPN multicast well I guess it depends on how the provider is running his Multicast. Either using the draft rosen method or the multiprotocol BGP method. essentially both would look the same from the customer perspective, but could generate loads more traffic and complexity on the SP. As for Data Centre applications. I'm assuming you are referring to a large hosted data centre, where the SP is providing IAAS type applications to a large number of customers. A lot of the vendors have come up with ways of transporting data between locations. This doesn't mean that they are any better or worse than MPLS/VPLS for location to location. But usually are geared towards addressing some particular problems that are encountered in Data Centers. Data Centers implicitly have their own problems. Dealing with lots of different customers and VLANs creates scaling issues in VPLS. However MPLS VPNs really have the opportunity to shine inside of a data Centre. By building a hosted VM service at the edge of a MPLS cloud it would be possible to create interconnections which allow customer VMs to talk within their VPNs easily. Mutliple host locations would easily interact with each other just as if the VMs where another node on the customers location. The only problem I've seen with the VPN inside of a data center revolves around the firewalling between customers. Large scale data centers are going to require immensely large firewalls. It's ridiculous how much the firewalls are going to cost that allow customer traffic in and out of the hosted VM data centre. And even with these large firewalls, They still won't be able to handle the amount of domains for the multiple customers. One of the largest problems with Firewall companies today is this lack of visualization. I guess I've not written anything on this topic before, and I guess I've been on a hiatus for quite awhile. But this is one of the larger topics of concern in data centers today. Applications suiting VPLS versus MPLS. Well, considering that VPLS runs over MPLS, (at least in most cases). It’s kind of a chicken and an egg thing. For VPLS to operate it needs MPLS. However that doesn’t mean that from the customers perspective that the behaviour would be any different. From the Customer perspective, he is either sending a layer 2 packet and doing the routing to the end node himself, or he is taking advantage of the MPLS VPN routing of his traffic and sending it into the provider as a layer 3 packet. (Note that in both cases he his mostly likely sending it to the provider as layer 3. In VPLS it ignores the layer 3 header, and in MPLS VPN it looks at the header. The Layer 2 method is going to involve more overhead, because the end nodes are going to have to broadcast for address resolution and the like, they are also most likely going to be exchanging some layer 2 BPDUs, however the Layer 3 complexity at the layer 2 model is a lot less. It probably doesn’t have to keep larger routing tables. (Depending on the design of course). Where as the Customer CPE will have to have a larger routing table, and be running a routing protocol.

As for applications, well the only thing that I can think of that would be handled differently between the two types of networks would be multicast based applications. Where the layer 2 multicast would use multicast frames for distribution into to the network, and if the network had some sore of multicast snooping it would restrict or reduce the amount of multicast traffic that would be going to every location. With the Layer 3 VPN multicast well I guess it depends on how the provider is running his Multicast. Either using the draft rosen method or the multiprotocol BGP method. essentially both would look the same from the customer perspective, but could generate loads more traffic and complexity on the SP.

As for Data Centre applications. I’m assuming you are referring to a large hosted data centre, where the SP is providing IAAS type applications to a large number of customers. A lot of the vendors have come up with ways of transporting data between locations. This doesn’t mean that they are any better or worse than MPLS/VPLS for location to location. But usually are geared towards addressing some particular problems that are encountered in Data Centers. Data Centers implicitly have their own problems. Dealing with lots of different customers and VLANs creates scaling issues in VPLS. However MPLS VPNs really have the opportunity to shine inside of a data Centre. By building a hosted VM service at the edge of a MPLS cloud it would be possible to create interconnections which allow customer VMs to talk within their VPNs easily. Mutliple host locations would easily interact with each other just as if the VMs where another node on the customers location.

The only problem I’ve seen with the VPN inside of a data center revolves around the firewalling between customers. Large scale data centers are going to require immensely large firewalls. It’s ridiculous how much the firewalls are going to cost that allow customer traffic in and out of the hosted VM data centre. And even with these large firewalls, They still won’t be able to handle the amount of domains for the multiple customers. One of the largest problems with Firewall companies today is this lack of visualization. I guess I’ve not written anything on this topic before, and I guess I’ve been on a hiatus for quite awhile. But this is one of the larger topics of concern in data centers today.

]]> Comment on vpls versus mpls vpn by Mark http://vpls.us/?p=183&cpage=1#comment-379 Mark Thu, 19 Apr 2012 22:40:46 +0000 http://vpls.us/?p=183#comment-379 Be interested in your thoughts on what applications might suit VPLS vs MPLS. Would think Data centre applications that must have flat Ethernet addressing across several sites like virtual machine environments. How has your view evolved since you wrote this article? Be interested in your thoughts on what applications might suit VPLS vs MPLS. Would think Data centre applications that must have flat Ethernet addressing across several sites like virtual machine environments.

How has your view evolved since you wrote this article?

]]> Comment on RFC 4762 by chado http://vpls.us/?p=49&cpage=1#comment-372 chado Tue, 13 Sep 2011 06:44:12 +0000 http://vpls.us/?p=49#comment-372 Hello, Thanks for the feedback. Finaly, I had a guy from Juniper and he confirms to me that inter-AS VPLS option B with BGP autodiscovery and LDP signaling is not supported by Juniper platforms. Hello,

Thanks for the feedback.
Finaly, I had a guy from Juniper and he confirms to me that inter-AS VPLS option B with BGP autodiscovery and LDP signaling is not supported by Juniper platforms.

]]> Comment on RFC 4762 by TimC http://vpls.us/?p=49&cpage=1#comment-371 TimC Fri, 09 Sep 2011 14:42:20 +0000 http://vpls.us/?p=49#comment-371 I can think of two reasons why this isn't happening. 1) fec 129 isn't properly being passed on your BGP session. It's establishing your session but not passing the information for your targeted LDP sessions to establish. Upgrade to Junos 11.2 or higher and it'll fix it. 2) you have an MTU mismatch between the the Juniper and the Cisco. the LDP session won't establish if that's the case. The MTU is set on the physical interface or on the service instance on the Cisco. However you set it on the routing-instance for the juniper. MTU is a screwed up mess on cisco. They don't support "officially" setting MTU on the bridge-domain. However older versions of code Pre RLS7 did allow the setting and did establish the MTU between the devices. Great question. let me know if you are still having problems. Also, I'm on a slow link in the middle of nowhere so it might take a couple days for me to respond this next week. I can think of two reasons why this isn’t happening.

1) fec 129 isn’t properly being passed on your BGP session. It’s establishing your session but not passing the information for your targeted LDP sessions to establish. Upgrade to Junos 11.2 or higher and it’ll fix it.

2) you have an MTU mismatch between the the Juniper and the Cisco. the LDP session won’t establish if that’s the case. The MTU is set on the physical interface or on the service instance on the Cisco. However you set it on the routing-instance for the juniper.

MTU is a screwed up mess on cisco. They don’t support “officially” setting MTU on the bridge-domain. However older versions of code Pre RLS7 did allow the setting and did establish the MTU between the devices.

Great question. let me know if you are still having problems.

Also, I’m on a slow link in the middle of nowhere so it might take a couple days for me to respond this next week.

]]>