<span style="font-family: comic sans ms,sans-serif;">Colleagues hi</span><br style="font-family: comic sans ms,sans-serif;"><br style="font-family: comic sans ms,sans-serif;"><span style="font-family: comic sans ms,sans-serif;">I'm currently evaluating equipment for
Metro-Ethernet project, which briefly looks like on this scheme:</span><br style="font-family: comic sans ms,sans-serif;"><br style="font-family: comic sans ms,sans-serif;"><img style="font-family: comic sans ms,sans-serif;" alt="http://vugluskr.mml.org.ua/~doka/.1/netmod.jpg" src="http://vugluskr.mml.org.ua/%7Edoka/.1/netmod.jpg"><br style="font-family: comic sans ms,sans-serif;">
<br style="font-family: comic sans ms,sans-serif;"><span style="font-family: comic sans ms,sans-serif;">i.e. there are 8 core nodes (colored in blue, A-Sn) and 8
aggregation nodes (everyone consists of 8 stacked switches with 48xGE/2xTGE). Also, there is one gateway node (BGP-0) which provide connection to
other ISPs.</span> <span style="font-family: comic sans ms,sans-serif;">There will be MPLS
between core nodes, which will be used to provide L3 VPNs.<br><br style="font-family: comic sans ms,sans-serif;"></span><span style="font-family: comic sans ms,sans-serif;">Every aggregation node serve up to 400 access switches, connected in star (i.e. no rings in access) over GE dark fiber (i.e. GE FX must be on aggregation side). It </span><b style="font-family: comic sans ms,sans-serif; color: rgb(255, 0, 0);">MUST NOT</b><span style="font-family: comic sans ms,sans-serif;"> do local switching between access nodes, it must just pass traffic between access nodes and core</span>, where on core corresponding VLANs will be connected to corresponding VRFs. Since I don't want to expand MPLS cloud beyond core (from both price and complexity perspective), I see two ways to provide such isolation:<br>
<br>1) using QinQ between Aggregation and Core (thus, tunneling access links to core, where all them will be terminated). In this case switch also must support:<br>1.1) <b>CoS mutation</b> (copying CoS from C-VLAN to S-VLAN and vice versa)<br>
1.2) <b>selective tunneling</b> (i.e. some VLANs will be tunneled using second tag, some VLANs - switched locally)<br><br>
2) using kind of port protection (PVLAN or something similar) between all 8x48 ports in aggregation stack (i.e. no traffic between these ports, just to/from core-facing interfaces) and using Proxy ARP on core nodes.<br>
<br>While second way is supported on more switches, it looks not so flexible and scalable as Selective QinQ. May be, anyone can comment these ways? Or suggest other ones? Personally I'd prefer using Selective QinQ.<br>
<br>Connection between aggregation & core will be done with 10:1 oversubscription and redundancy will be done in the following way:<br>
<br><img alt="http://vugluskr.mml.org.ua/~doka/.1/coreagg.jpg" src="http://vugluskr.mml.org.ua/%7Edoka/.1/coreagg.jpg"><br>
<br>i.e. 400 GE links to access switches will be served with 4 TenGig links to core, from different switches in stack, to different (as possible) linecards in core node.<br style="font-family: comic sans ms,sans-serif;">
<br>So, I'm evaluating MLX-series on core and XMR on internet gateway. My questions regarding these devices:<br><br>1) how much bandwidth per slot they support? There are max 4xTGE linecards available - is it chassis limit?<br>
2) if chassis is 100G-per-slot capable - are there 8xTGE and 1x100G linecards on roadmap?<br>3) whether MLX support termination of QinQ, in way like to:<br><br><span style="font-family: courier new,monospace;">int TenGig 0/1.5</span><br style="font-family: courier new,monospace;">
<b style="font-family: courier new,monospace;"> <span style="color: rgb(255, 0, 0);">encapsulation dot1q 5 second-dot1q 10</span></b><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> ip vrf forwarding <VRF name></span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> ip address x.x.x.x/N</span><br><br>4) are there ways to control CoS in C-VLAN/S-VLAN on egress (depending on MPLS Exp or DSCP) in case of double-tagging? <br><br>Regarding aggregation: it looks for me, that using CES or CER on aggregation is overkill in my case. I don't need MPLS, while these devices built with MPLS in mind. FastIron aren't GE/TGE capable. Whether BigIron RX-series supports Selective QinQ / CoS mutation mechanisms?<br>
<br>Thanks so much! :-)<br style="font-family: comic sans ms,sans-serif;">
<span style="font-family: comic sans ms,sans-serif;"></span>
<br style="font-family: comic sans ms,sans-serif;">
<span style="font-family: comic sans ms,sans-serif;">-- </span><br style="font-family: comic sans ms,sans-serif;"><span style="font-family: comic sans ms,sans-serif;">/doka</span><br style="font-family: comic sans ms,sans-serif;">
<br style="font-family: comic sans ms,sans-serif;"><span style="font-family: comic sans ms,sans-serif;">/*-- <a href="http://doka-ua.blogspot.com/" target="_blank">http://doka-ua.blogspot.com/</a> --*/</span><br style="font-family: comic sans ms,sans-serif;">