cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
766
Views
10
Helpful
9
Replies

MPLS vpn test lab

Jon Marshall
Hall of Fame
Hall of Fame

I am trying to setup a basic lab. I have the following setup:-

CE1->PE1->P1->PE2->CE2. I have attached the relevant configs.

All the CE & PE routers are 2600's and the P1 router is a 7206VXR. I am running OSPF in the MPLS network between the PE & P routers. I am using ldp as the label distribution protocol. BGP is running between the CE & PE routers.

I have a couple of questions:-

1) Basic MPLS setup. I think this is working in that if i ping from the LAN side of the CE1 to the LAN side of the CE2 it works. The P1 router has no knowledge of these subnets. However a "sh mpls forwarding-table" command on the PE routers shows no bytes tag switched and yet if i do a "debug mpls packet" on the P1 router i can see the packets going through. If the P1 router doesn't know the LAN subnets then am i right to assume it must be label switching ?

2) The configs attached are to test a VPN setup. I have the MPLS & VPN architectures book and i have gone through all the show commands to troubleshoot and it all looks right. The routes are in the vrf routing table, the mpls forwarding table looks okay but i cannot ping from CE1 to CE2.

If i debug on the P1 router i can see the packets coming in with 2 labels as expected but i can't see them being transmitted.

I have done some searching and know that 2600's are not officially supported but my understanding is that the features i need are on the routers. I have tried a number of different IOS versions but to no avail.

Any help would be much appreciated

Jon

9 Replies 9

Harold Ritter
Cisco Employee
Cisco Employee

1) what do you mean by basic mpls setup. How are routes learnt from CE1 to CE2 and vice versa. BGP?

If routes from CE1 and CE2 are unknown to the P router and that your ping from CE1 to CE2 is working then P1 is probably label switching the packets. The fact that the counters are not incremented when you do a "show mpls for" might be a bug.

2) Do you have an entry in the mpls forwarding table (lfib) on P1 for the top label you see when you do the "debug mpls packet"? Could you include a "show mpls ldp nei" and "show mpls for" from P1.

What 2600 do you use? What release and feature do you use? show ver would be welcomed.

Thanks,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Harold Ritter
Cisco Employee
Cisco Employee

I just checked you mpls vpn setup again you are missing in the configs you attached. You should have "ip vrf forwarding NR_prod" under fa0/0 on both PE1 and PE2. Is this a typo or are you really missing this command in your lab?

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

thanks for your responses

1) yes it's a typo, i do have the "ip vrf forwarding NR_prod" on the fa0/0 interfaces on the PE routers.

2) Basic mpls - i meant no VPN's etc. I have ospf between the PE & P routers. I have MP-BGP between PE1 & PE2. Between the PE & CE routers i am running standard BGP.

3) All 2600 routers are 2621XM's. The IOS i am trying with is c2600-spservicesk9-mz.123-4.T4.bin altho i have also tried c2600-spservicesk9-mz.123-8.T10.bin and c2600-telco-mz.123-7.T12.bin.

4) On the 7200 i'm running c7200-p-mz.123-16.bin and have also tried c7200-p-mz.124-5.bin

5) The packet from PE1 comes into the P1 router labelled as 19/24. The mpls forwarding table on P1 has the entry

19 Untagged 81.144.17.55/32 2137750 Fa0/1 172.16.1.6

which is correct as far as i can see as this is PE2.

I have included the sh mpls output from the P1 router and a sh ver of one of the PE routers ( they are both the same ).

Once again, many thanks for your replies.

The issue definitely seems to be on P1. The entries in the LFIB for both 81.144.17.54 and 55 have an action of untagged, which will result in all labels being removed from the packet before it is forwarded to the outbound interface. This didn't matter in your basic MPLS scenario but it does in the MPLS VPN one. Both labels are stripped and the packets is forwarded to the egress PE and then it is dropped since the egress PE doesn't have an entry for the destination IP address in its global routing table.

The normal action for these entries should be "pop tag" since the P router is also the penultimate hop and therefore the top label should be popped.

To find out why these entries have an action of untagged rather than pop tag, do a "show ip cef 81.144.17.54" and "show ip cef 81.144.17.55" on P1. The next hop for these two addresses should correspond to one of the addresses bound to peer LDP Ident, such as 172.16.1.10 for 81.144.17.54 or 172.16.1.6 for 81.144.17.55 to be considered valid.

Could you also provide the full configs for PE1, PE2 and P1.

Thanks,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

That makes a bit more sense now. I assumed that because the action was untagged that this only applied to the top label and the packet would be sent on by P1 with with the VPN label intact. This is down to my misunderstanding of the actions ie untagged vs pop tag.

I did a the show ip cef commands as suggested and they do point to the PE router as the next hop. I've included the output and a "sh run" of the PE & P routers.

Many thanks

Here's the issue. You have "no tag-switching advertise-tags" configured on both PE1 and PE2, which is preventing both PEs from advertising the implicit null label for their respective loopback address to P1.

Just remove these two statements by entering "tag-switching advertise-tags" and everything should start working.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

That did the trick. Don't know why i put this in but it looks like i must have as it's not the default. Not sure i entirely understand the reason you give but a bit more reading should sort it out.

My colleagues at work will be relieved as i was becoming a bit "obsessive" about this. Don't have much chance to do MPLS in my day job but i find it one of the more interesting subjects.

Many thanks for all your help

Sorry for being a bit cryptic in my previous posting. The reason the LFIB entries for 81.144.17.54/32 and 81.144.17.55/32 on P1 have an action of Untagged is because a label is not received for these prefixes from PE1 and PE2 respectively due to the "no tag-switching advertise-tags".

This command is usually used when you want to apply label advertisement filtering. Label filtering is generally employed to only allow label advertisement for the loopback address of each PE as follow:

! disable unfiltered label advertisement

no tag-switching advertise-tags

! enable filtered label advertisement for prefixes in ACL 1

tag-switching advertise-tags for 1

access-list 1 permit 81.144.17.54

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Right, think i get it now and that saved me a bit of reading time :-). Still no idea how i ended up with this in the config as i definitely wasn't trying to do label filtering. Still, as usual, learnt a more about MPLS vpn's by it not working than if it had worked straight away.

Cheers

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: