Hello Sunny, on an ethernet fiber SFP you should be able to configure L3 unless the port belong to a L2 only module. If the port belongs to an F1, F2 or F2e module this may be the root cause as these modules are L2 only.   When you wrote FC I thought you were meaning fiber channel ports.   Again a fiber channel optics is not an ethernet optics   Hope to help Giuseppe       ... View more

Hello, the trick with MPLS is that multiple MPLS labels can be stacked there is a bit that says if the label is the bottom of stack (bit S). So for example an MPLS L3 VPN requires to use a two labels stack, the inner label travels unchanged from the sender PE node to the destination PE node and its meaning is locally defined on the destination PE node where that MPLS label means a VRF or a a destination IPv4 prefix within a VRF. The external label also called IGP label is actually changed at each router hop and it is simply the end to end Label switched path from the source PE to the destination PE with destination the destination PE loopback address. For an EoMPLS pseudowire again a double stack of labels are used with again the external label being the only one that changes at each hop and the internal label means an access L2 circuit out of it the ethernet frame has to be delivered.   This is the reason why MPLS header does not need a protocol type, the use of multiple labels provide the capability to understand what to do with the payload and the context is provided by a signaling protocol that can be LDP, RSVP TE or MP BGP with address families. To be noted on each node a single label space exists and if label 2500 is used for a service it cannot be taken for a different service. This was a choice of MPLS designers to avoid to add unnecessary overhead to the user traffic in the data plane. To say things correctly MPLS introduced the concepts of data plane and control plane. The control plane is the exchange of messages of protocols that build LSPs and MPLS based services using the label stack concept. The data plane is the moving of user traffic within MPLS LSPs that follow an end to end path and P nodes in the middle do not need to know what they are switching they just swap change the incoming external lavel with the outgoing label and outgoing interface they do not need to inspect deeper the MPLS frames.   Hope to help Giuseppe     ... View more

Hello Orkhan, now I see your issue You would need to use a different access link on the PE node to be able to support same Vlan on different customers.   There are some tricks to perform Vlan tag rewrite in EoMPLS in order to accomodate different Vlan tags at the two ends of the pseudowire but I am afraid they are not enough for your needs. The only way to scale more then this would be to use 802.1Q in 802.1Q tunneling: in this case the configuration of the port towards the customer would be an 802.1Q tunnel and you would assign an external Vlan-tag specific for each customer. This second scenario would require an external access switch. However, in this way the customer would be allowed to pass frames with any possible vlans between pseudowires defeating your provisioning model.   Hope to help Giuseppe Larosa ... View more

Hello Jitex, if you are going to use the Nexus as simple L2 transparent switches, there is no issue as the MPLS frames are still ethernet frames eventually with an 802.1Q tag followed by the MPLS ethertype. Also in the signaling plane this would nor be an issue. If you instead mean you would like to have the Nexus act as P nodes in the MPLS cloud they should be able to be used for this. If you mean you would like to use the Nexus as a VPLS PE node this needs to be checked. Making a search I ahve found the following:   You need the MPLS license installed according to the following thread https://supportforums.cisco.com/t5/other-data-center-subjects/nexus-7000-supports-vpls/td-p/2478928   Hope to help Giuseppe   ... View more