They were indeed Internet prefixes which we don't need to routes through our tunnels .
Somehow they started getting labeld , once I upgrade the IOS and reloaded the router, problem cleared.
Below you have the memory log entries I got yesterday after adjusting the MPLS label range to 200000.
I think you definitely right about limiting the advertisement of labels.
894786: Sep 17 15:40:21.397 UTC: %SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed from 0x31B87CF, alignment 0
894785: Sep 17 15:40:16.190 UTC: %LSD-4-LABEL_RESOURCE: label range 16-100000 exhausted
-Traceback= 19D735Fz 31D6AEFz 31E230Ez 31E22DEz 18C9BF4z 18C9444z 1904196z 190393Az 19038D7z
894784: Sep 17 15:39:58.319 UTC: %SYS-2-CFORKMEM: Process creation of Exec failed (no memory). -Process= "TTY Background", ipl= 0, pid= 58
[Message Details] -Traceback= 19D735Fz 31B0304z 31A886Az 31ACD5Ez 31B87CFz 31B924Dz 3FC0C3Cz 3F75A40z 3F759E7z 3F7581Ez 3F794DBz 3F7887Dz 3FA0ED5z 3FAC4C5z 3FAC06Bz 3FABC88z
-Process= "Tag Control", ipl= 0, pid= 431
Alternate Pool: None Free: 0 Cause: No Alternate pool
Pool: Processor Free: 394014700 Cause: Memory fragmentation
894783: Sep 17 15:39:51.255 UTC: %SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed from 0x31B87CF, alignment 0
Regarding the GR Recovery , this is all we get in the log but like you said I don't think this caused the
888136: Sep 14 21:49:34.794 UTC: %LDP-5-GR: GR session 188.8.131.52:0 (inst. 6): interrupted--recovery pending
888138: Sep 14 21:49:38.882 UTC: %LDP-5-GR: GR session 184.108.40.206:0 (inst. 5): starting graceful recovery
Vinit, I will be on holiday as from Sunday, I really thank you for the assistance. and wish you all the best.
Have a nice weekend.
I increased the mpls label range and got memory errors. couldn't save the config anymore and had to undo the change.
I'm now back to previous situation but with latest IOS: c3900e-universalk9-mz.SPA.153-3.M6.bin
Not sure how to fix this mpls label range.
Can you share the below output:
- show mem statistics
I actually want to see how much memory is available on the router.
quick question: Did you increase the label range to 1M? I dont think it will be a good idea to do that on 3900 series platform.
I tried to increase the the label range to 200000 but got memory issues.
Now is back to 100000.
This is my memory status
sho mem stat
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Processor 200AE680 1552116256 697472996 854643260 832424312 832065908
I/O D5AE680 313524224 89315980 224208244 224208244 224183292
thank you for this great opportunity!
Some weeks ago this question was posted here in the MPLS section:
I found it interesting enough to set up a simplified gns3 lab, just with a direct OSPF point-to-multipoint backup-link instead of a DMVPN. As we know, the OPSF point-to-multipoint network type advertises a hostroute instead of the interface's real subnetmask and the network-ID in the corresponding Router-LSAs. These LSAs are exchanged between the PEs via MPLS and the hostroutes are installed in the neighboring PE's routing-tables, but no labels are received for those /32-prefixes, only for the corresponding subnet, because that's the only routing-table entry of the neighboring PE. That's (I guess) why packets destined to the point-to-multipoint interface cannot be forwarded via MPLS in this scenario.
So I couldn't find a better solution than filtering out the hostroutes locally by distribute-lists - just what the original poster did.
I guess it is a very uncommon design to have a backup-link with OSPF point-to-multipoint interfaces between PEs but I'd really like to know if you could provide with a better way to solve this problem.
I agree with your last statement that its very un-common to see a backup link with OSPF P2M interfaces. Let me do some testing before i get back to you with some definite answer.
How would you encrypt customer traffic traversing a plain ISP MPLS backbone? What'd be the options other than IPSec? And which the main problems one would encounter?
I dont really think its a good idea to encrypt the customer traffic in the ISP Core as there will already be overhead of labels (IGP as well as VPN label). Thus adding another ipsec header maximum data size that can be transmitted from the ISP core. I have personally not seen any deployment of ISP core using IPSec. The customer data is already secure as its going as a vpnv4 update and to decode the packet, they will have to look inside the mpls packet itself.
Though customer can encrypt their traffic between CE to CE using ipsec which is the most preferred design but again, the only challenge will be the maximum data size that can be transferred across the ipsec tunnel. If the CE device has Jumbo MTU and same is the case with ISP then it would be better (atleast for the applications which send packets with higher segment size and with DF bit set).
Hope this answers your question.