Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Enterprise MPLS

Folks,

we have 2 core switches (6500 3XLBs) at the core doing inter vlan routing.

I plan to move towards enterprise MPLS as a test pilot. My question is that as follows:

Lets say that i have vlan 300 terminating on both core switches. both core switches also have a layer 3 interface.

Core A

Interface vlan 300

ip vrf forwarding A

ip address 10.10.10.1 255.255.255.0

Core B

interface vlan 300

ip vrf forwarding A

ip address 10.10.10.2 255.255.255.0

Will i be able to pind from 1 PE to the other? using vrf table of customer A?

what is the idle senario in which a person is spanning vlan between switches (typical vlan configguration in an enterprise), what changes would he have to make in his topology or ip addressing scheme when he moves to enterprise MPLS.

Thanks

12 REPLIES
Purple

Re: Enterprise MPLS

Hi Parwal,

I think I understand what you are getting at now...

Since you are using layer 3 interfaces (SVIs) to terminate both VLANs, what that means is that the VLAN effectively terminates at your layer3 switch. The fact that you are using the same VLAN is immaterial. They are treated as two distinct VLANs. Although you have placed both interfaces in the same VRF, they will not be able to communicate because you now have two interfaces within the same VRF with the same subnet. That is address duplication and will not work.

If you want to extend your VLAN between two sites, you need to use either Ethernet over MPLS or VPLS. When you use layer 3 VPNs, all interfaces belonging to a VRF have to have unique subnets.

Hope that helps - pls rate the post if it does.

Paresh

Re: Enterprise MPLS

Hello,

a ping vrf A 10.10.10.2 on Core A will give you connectivity.

Moving from a VLAN environment with ONE IP routing instance to VLANs in different VRFs of course needs some thought regarding required connectivity.

In a first step I would not change IP addressing at all. Topology itself also has not to change.

Start with enabling MPLS in one VLAN (later the backbone), then setup VRFs for a test environment containing one VLAN and then move every VLAN (except MPLS VLAN) into one VPN ... easier for rollback.

Once you are sure all applications and the like are doing well, you can start to sort different VLANs/interfaces into their "destination" VRF. By setting Route Targets properly you still can get connectivity, where you need it.

Hope this helps! Please rate all posts.

Regards, Martin

New Member

Re: Enterprise MPLS

Martin,

I am confussed. You said

a ping vrf A 10.10.10.2 on Core A will give you connectivity.

I can not pint 10.10.10.2 from core A and Paresh confirmed that it will not work, because core A will see 10.10.10.0/24 is a directly connected interface?

how will it know to go to core B vlan 300 to ping 10.10.10.2.

Thanks

Re: Enterprise MPLS

Hello Parwal,

How would this work without VRFs? Core A would "see" by looking at the interface IP and netmask, that the destination IP is in the local VLAN and issue an ARP for 10.10.10.2 - this ARP should arrive at Core B and be answered.

And then the connectivity should be no problem. Did you try to ping without VRFs in place? What is the outcome?

Regards, Martin

New Member

Re: Enterprise MPLS

Martin,

I am trying it now as we speak, you are awesome guy! always willing to help. I appreciate your response a lot.

One question question on the side, you mentioned that you have helped a lot of customers move away from pure 3 routing within the enterprise to enterprise MPLS. My question is:

1) Did you change the routing protocol in the core to ospf or is-is? we are running eigrp in the core, but we do not plan to implement traffic engineering so i should not have a problem right? i could do MPLS over eigrp for smooth transition and may be later, change routing with the core from eigrp or ospf.

2) We have a lot of edge devices doing layer 3 routing. lets say a 3550 connected to the core doing later 3 routing as well. We plan to use VRF lite for that, did you do the same when the layer 3 interfaces were present at edge devices? what protocol did you use to exchange routes using vf lite, i think eigrp is not supported, please correct me if i am wrong, but we can not use EIGRP to exchnage routes using vrf-lite on 3550 switches?

3) we have a lot of multicast devices connected to edge devices doing layer 3 routing, does vrf-lite have any limitations on multicast traffic???

Thanks,

Re: Enterprise MPLS

Hello Parwal,

thank you for the compliments, thats part of being motivated to help in the forum.

Regarding numbers ... I would say a couple of customers is closer to the truth than many ;-)

Anyhow...

A1) No. My opinion on migration is to rather have a couple of small steps than to have one big change. The reason is, that it is easier for staff to follow the changes and also to isolate unforseen problems during migration and solve them. Not everyone is a CCIE and it should be done with operations in mind.

With respect to MPLS VPN the IGP has only few things it should deliver. The main purpose of the IGP is to announce the BGP next-hop addresses to allow building LSPs with the help of LDP. Another property is fast convergence. Both requirements can be fulfilled with EIGRP. In case you are comfortable with it: I would not change it unless there is a strong reason to do so.

A2) Well in the designs I was involved there was only once a Multi-VRF design. And that was involving Cisco routers. So no issue with respect to IP routing protocols. In all other cases VLANs were deployed right to the PE and there the IP routing took place.My opinion on Multi-VRF is: Use the IGP which is available. In fact even RIPv2 will be useful in some places. In the 3550 I think you are right. So you have the option of converting your access switches to L2 or to utilize another, supported IGP.

A3) With respect to multicast in a Multi-VRF environment: I didn´t implement it. But from a theoretical point of view: There are not even labels used in the Cisco solution, so I do not see, what should prevent one from using it. But this is just a deduction from all the theory I know. Finally there will eb no other way to find an answer that to setup a lab and test it. I would be happy to get the results in case you test it.

Hope this helps! Please rate all posts.

Regards, Martin

New Member

Re: Enterprise MPLS

Martin,

I have a question for you. I would appreciate if you could help me. You seem to know the maximum about enterpise MPLS.

My question is that i want to implement enterprise MPLS in my organisation, we only have 2 other customers who use our network. So i want to use enterpise MPLS for them and use regular Larer 3 routing for our own traffic.

Can this be done? do you forsee any issues with that.

Thanks

Parwal

Re: Enterprise MPLS

Hello Parwal,

you can do this, there should be no unsolvable issues.

In case you need to access customer equipment (router, switches, Servers, ...) I would use a standard firewall, which has an interface in your network, and one interface in each customer VRF. This can also be implemented through a trunk with different VLANs between PE and FW. Potentially you can do NAT on the FW as well.

Make sure you have a scalable RD, RT, VRF naming/numbering concept. Also carefuly design your customer IP routing to avoind loops. Plan the migration steps carefully and plan for rollback. Adjust MPLS MTU. Protect the PEs from ressource exhaustion (CPU, memory, MACs, etc.).

DOCUMENT IT!!!

And finally get a Global Knowledge MPLS instructor like me to teach MPLS to your 1st and 2nd level personel ;-)

Otherwise you might end up doing 24x7 support alone ...

Hope this helps! Please rate all posts.

Regards, Martin

New Member

Re: Enterprise MPLS

Martin,

We introduced Enterprise on our live network and it was a disaster, users complaining about latency to other networks with the company but not to the internet.

All i did was following:

Core A ----- Core B ------ Core C

All core switches are layer 3 routed links. Pure layer 3 routing using eigrp.

I enabled tag switching on Core A and Core B only. So when i typed in "show mpls forwarding table", I was able to see all prefixs (vlans) on core C and connected networks with a tag(ingress and exgress) associated with them.

I enabled MPLS on the layer 3 link between the two switches (Core A and Core B)

Core A config after enabling MPLS. Vlan 503 connects Core A and Core B

interface Vlan503

ip address 10.32.0.34 255.255.255.252

ip pim sparse-dense-mode

ipx network A200020

mpls ip

interface GigabitEthernet3/1

no ip address

switchport

switchport access vlan 503

switchport mode access

Users connected to Core A through edge switches were experiencing latency when they tried to access the servers on switches connected to Core C.

My question is that is Tag switching is enabled between 2 links (layer 3 link between CoreA & B).

Will the packets which were originally layer 3 routed will now be tag switched????

if that is the case, then once the packet arrived at Core B, it was pop tagged and then routed to Core C?

Can it be jumbo frame problem? i did not enable that in any of the switches??

What i did was very very simple, only enabled tag switching and it brought the network almost down as all users were companining of latency.

Any ideas?

Thanks

Re: Enterprise MPLS

Hello Parwal,

this sounds like an MTU issue. You have to enable MPLS MTU adjustment using "mpls mtu 1508". In case MPLS is enabled and you have a label it will be used. This means, that an IP packet with 1500 Bytes will have 1504 Bytes afterwards and the switch will see this to be larger than the interface MTU. The result is, that it is dropped, because there exists no fragmentation for labeled packets.

Dropping evey IP packet with 1500 Bytes will definately affect downloads and like giving your users latency for the least.

Also make sure that you have the latest IOS on the 6500, because there was an issue with "mpls mtu" not working before 12.2(18)SXD (not sure I remember the IOS version correctly).

Also make sure all L2 switches transporting labeled packets are configured to accept jumbo frames.

To answer your other question: a labeled packet arriving at CoreB will be label switched to CoreC and not routed. This is also true for the CEF action "pop".

Hope this helps! Please rate all posts.

Regards, Martin

New Member

Re: Enterprise MPLS

Martin,

Would you be kind enought to please tell me what do i need to do to enable support for jumbo frames on 3550 series switches?

Also, i am having a difficult time understanding your statement:

"To answer your other question: a labeled packet arriving at CoreB will be label switched to CoreC and not routed. This is also true for the CEF action "pop". "

Why would the packet arriving at coreB will be labelled switches to coreC, there is no tag switching configured between CoreB and CoreC.

I was surprised to see that all the labels on Switch A did not say that they would POP the label even thought CoreB was the last switch for tag swicthing as there was not tag switching configure between B&C.

Any advice would be highly appreciated.

Thanks,

Parwal

Re: Enterprise MPLS

Hello Parwal,

the jumbo frame support can be enabled on a Catalyst 3550 through "3550(config)#system mtu 1546". The detailes are found at

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml#3550

Regarding label switching on coreB to coreC:

As any LSR in frame-mode MPLS coreB will choose per default a local label for every network in its IP routing table. These labels will be announced to coreA through LDP. This means IP packets towards those destinations will arrive at coreB with the respective Label in place (imposed by coreA). Thus coreB has to consult the LFIB, i.e. the traffic will be label-switched towards the next hop of coreB. The label in the arriving packet will instruct coreB whether it should forward the traffic labeled or as plain IP packet (like to coreC).

coreB will only choose Label no. 3 ("pop", implicit Null label) in case it has to perform an IP lookup to find the destination. This is only the case, if the network is directly connected to coreB. Destination IP could be coreB´s IP or any attached host, which can not be determined from the label allone, ths an IP lookup is needed.

If the network is found at coreC (or behind) the forwarding decision can be determined from the label alone, there is no need for an IP lookup on coreB.

So in short: coreB will be label switching all traffic for networks not directly connected to coreB and will perform IP lookups for all incoming IP packets.

Hope this helps! Please rate all posts.

Regards, Martin

155
Views
35
Helpful
12
Replies