Re: [j-nsp] Mixed Cisco/Juniper MPLS network
On Friday, August 16, 2013 12:29:00 AM Adam Vitkovsky wrote: Well as Chinese say, be careful what you wish for :) There actually is such a command (sort of) it's advertise passive only under router isis. I enter RID interfaces into ISIS with cmd passive interface loopbck 0. And that's all I need to be advertised by an IGP underpinning an MPLS backbone. All the rest is in the VRFs. That would be a bit of a hammer :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
On (2013-08-14 12:40 -0400), Eric Van Tol wrote: So what you're saying is that there is definitely some other issue here and it's not necessarily the fact that the destinations are allocated labels, but rather the label allocation is exposing an underlying problem. If so, that narrows it down and points me in the right direction. I'm trying to replicate in the lab, as I just had an idea, thanks to your response. Yes, it should work. Consider PE1-P1-P2-PE2-PE3 Lets presume PE3 is non-MPLS box, but you're allows it in PE2 label ACL, then PE2 would give PE3/loop label. So PE1 would impose label, switch would be swapped by P1, P2 and popped by PE2. I'd really love to hear back from you, when you figure out what was causing the issues. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
On Wednesday, August 14, 2013 06:33:42 PM Saku Ytti wrote: I'd only use separate blocks if I specifically have next-hops which MUST NOT be label switched (I don't have, but some prefer INET not to be label switched, so they run INET to different loopback than VPNv4) In your case, it seems it would make more sense to figure out what the actual problem is and then go back to flat/static ACL for all core loops. To make my life simpler, I've generally created a prefix list which I've attached to the LDP session, that covers all my IPv4 allocations. While it makes more sense to stick to prefixes that cover only Loopbacks and/or any interface addresses for which you want LDP LSP's created, this can get tricky quite quickly depending on how/where your network grows. If it's any consolation, IOS only allocates LDP labels to IGP prefixes by default. Since (I hope) you don't carry your customer routes inside your IGP, you will generally only assign labels to infrastructure routes, i.e., backbone and Loopback interfaces. Fair point, one could argue that in-house static routes pointing toward customer links will also end up with labels as IOS considers static routing an IGP when it comes to label allocation, but you generally don't run MPLS across customer point-to-point links anyway. How much this noise is an issue to you vs. lower administrative overhead when deploying boxes depends on your unique operational circumstances. The problem comes when you've run out of space and you need to address new devices out of a block that wasn't in your filter to begin with, e.g., a new allocation from your RIR. This is where having a standard router/switch configuration helps a lot, because you can easily update the prefix lists via a bulk configuration upload with applications such as RANCID and friends, instead of going to every device hand- at-a-time. Hope this helps. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
On (2013-08-15 17:27 +0200), Mark Tinka wrote: To make my life simpler, I've generally created a prefix list which I've attached to the LDP session, that covers all my IPv4 allocations. This has some scaling implications, back when we were not filtering label advertisements we exhausted M10i NHDB due to the labels. It may also hurt convergence as rerouting needs to consider more next-hops. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
On Thursday, August 15, 2013 05:48:24 PM Saku Ytti wrote: This has some scaling implications, back when we were not filtering label advertisements we exhausted M10i NHDB due to the labels. It may also hurt convergence as rerouting needs to consider more next-hops. Labels would only be assigned to IGP routes, which are typically limited to backbone and Loopback interfaces. As customer routes aren't carried in the IGP (unless you're my competitor, so go right ahead, hehe), that is not an issue. Granted, you use more FIB slots than you would have if you were simply filtering against Loopback addresses, but this is a function of, as you say, scale, i.e., how many backbone links are in the network. Also, this is less of a problem for newer platforms that have larger and/or discrete FIB's, and also quicker control planes. If Cisco had a command that implemented the Junos behaviour, e.g,., mpls ldp label allocation loopbacks-only without needing to tinker around with filters, I'd be the first one to implement it :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
-Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Thursday, August 15, 2013 12:04 PM To: juniper-nsp@puck.nether.net Cc: Saku Ytti Subject: Re: [j-nsp] Mixed Cisco/Juniper MPLS network If Cisco had a command that implemented the Junos behaviour, e.g,., mpls ldp label allocation loopbacks-only without needing to tinker around with filters, I'd be the first one to implement it :-). Mark. Isn't this what the aforementioned allocate global host-routes command does? We do run this command on our ME3600s, but we also do filtering. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
On (2013-08-15 18:04 +0200), Mark Tinka wrote: Labels would only be assigned to IGP routes, which are typically limited to backbone and Loopback interfaces. As customer routes aren't carried in the IGP (unless you're my competitor, so go right ahead, hehe), that is not an issue. And as you pointed out, static routes, which quickly adds up. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
Not exactly. allocate global host-routes will allocate a label for any /32 prefix. While this should only be your loopbacks, it will catch any /32 route including static routes etc... Darren http://www.mellowd.co.uk/ccie From: e...@atlantech.net To: juniper-nsp@puck.nether.net Date: Thu, 15 Aug 2013 12:42:09 -0400 Subject: Re: [j-nsp] Mixed Cisco/Juniper MPLS network -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Thursday, August 15, 2013 12:04 PM To: juniper-nsp@puck.nether.net Cc: Saku Ytti Subject: Re: [j-nsp] Mixed Cisco/Juniper MPLS network If Cisco had a command that implemented the Junos behaviour, e.g,., mpls ldp label allocation loopbacks-only without needing to tinker around with filters, I'd be the first one to implement it :-). Mark. Isn't this what the aforementioned allocate global host-routes command does? We do run this command on our ME3600s, but we also do filtering. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
If Cisco had a command that implemented the Junos behaviour, e.g,., mpls ldp label allocation loopbacks-only without needing to tinker around with filters, I'd be the first one to implement it :-). Well as Chinese say, be careful what you wish for :) There actually is such a command (sort of) it's advertise passive only under router isis. I enter RID interfaces into ISIS with cmd passive interface loopbck 0. And that's all I need to be advertised by an IGP underpinning an MPLS backbone. All the rest is in the VRFs. adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Mixed Cisco/Juniper MPLS network
Hi all, We've had MPLS running on our network for years using JUNOS and until only very recently, we haven't had to deal with any of our Cisco equipment needing MPLS. That changed when we started purchasing ME3600X switches so we could provide VPN services in our metro fiber rings. I'm trying to wrap my head around how other people handle the label filtering in Cisco-world. As you know, JUNOS will only advertise a label for the local loopback, but IOS will advertise anything it has a destination to. Because of this, we've had to implement label filtering on the Cisco switches. While this works, it seems kind of cumbersome, especially when we need to add a new MPLS-capable device to the network, a prefix-list has to be updated. If a non-MPLS device is added, another prefix-list has to be updated. Is this the normal way of doing things, or is there something I am missing? I suppose we could assign a certain range of addresses out of our loopback subnet to be used solely for non-MPLS devices, but what happens when one day we need to add MPLS capabilities via a license or an entire hardware replacement? Any ideas or clue-bats upside the head would be appreciated. THanks, evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
On (2013-08-14 11:37 -0400), Eric Van Tol wrote: Is this the normal way of doing things, or is there something I am missing? I suppose we could assign a certain range of addresses out of our loopback subnet to be used solely for non-MPLS devices, but what happens when one day we need to add MPLS capabilities via a license or an entire hardware replacement? What is the issue if you allow non-MPLS devices in the loopback ACL for 'advertise-labels'. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
In my experience, I have seen used the knob to only allocate labels for host routes or use a prefix-list match that covers ALL your nodes loopback addresses so that the prefix-list does not have to be constantly touched. router# configure terminal router(config)# mpls ldp label router(config-ldp-lbl)# allocate global host-routes -Colby On Aug 14, 2013, at 11:37 AM, Eric Van Tol e...@atlantech.net wrote: Hi all, We've had MPLS running on our network for years using JUNOS and until only very recently, we haven't had to deal with any of our Cisco equipment needing MPLS. That changed when we started purchasing ME3600X switches so we could provide VPN services in our metro fiber rings. I'm trying to wrap my head around how other people handle the label filtering in Cisco-world. As you know, JUNOS will only advertise a label for the local loopback, but IOS will advertise anything it has a destination to. Because of this, we've had to implement label filtering on the Cisco switches. While this works, it seems kind of cumbersome, especially when we need to add a new MPLS-capable device to the network, a prefix-list has to be updated. If a non-MPLS device is added, another prefix-list has to be updated. Is this the normal way of doing things, or is there something I am missing? I suppose we could assign a certain range of addresses out of our loopback subnet to be used solely for non-MPLS devices, but what happens when one day we need to add MPLS capabilities via a license or an entire hardware replacement? Any ideas or clue-bats upside the head would be appreciated. THanks, evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
use a separate range and keep your network clean On 2013-08-14 8:37 AM, Eric Van Tol wrote: Hi all, We've had MPLS running on our network for years using JUNOS and until only very recently, we haven't had to deal with any of our Cisco equipment needing MPLS. That changed when we started purchasing ME3600X switches so we could provide VPN services in our metro fiber rings. I'm trying to wrap my head around how other people handle the label filtering in Cisco-world. As you know, JUNOS will only advertise a label for the local loopback, but IOS will advertise anything it has a destination to. Because of this, we've had to implement label filtering on the Cisco switches. While this works, it seems kind of cumbersome, especially when we need to add a new MPLS-capable device to the network, a prefix-list has to be updated. If a non-MPLS device is added, another prefix-list has to be updated. Is this the normal way of doing things, or is there something I am missing? I suppose we could assign a certain range of addresses out of our loopback subnet to be used solely for non-MPLS devices, but what happens when one day we need to add MPLS capabilities via a license or an entire hardware replacement? Any ideas or clue-bats upside the head would be appreciated. THanks, evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
On (2013-08-14 12:22 -0400), Eric Van Tol wrote: I've not been able to reproduce it in the lab, but traffic to destinations that are on non-MPLS devices have problems. Customers report slow bandwidth and/or page timeouts. I thought perhaps an MTU issue, but physical interface MTUs network-wide are 9000 with MPLS MTUs set to 1546. As soon as I added the non-MPLS devices to the prefix-list to prevent label allocation, the problems stopped. I'd only use separate blocks if I specifically have next-hops which MUST NOT be label switched (I don't have, but some prefer INET not to be label switched, so they run INET to different loopback than VPNv4) In your case, it seems it would make more sense to figure out what the actual problem is and then go back to flat/static ACL for all core loops. Maybe add one less used non-MPLS box as allowed and reserve some additional resourced to help troubleshooting when problem is in effect. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixed Cisco/Juniper MPLS network
-Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Saku Ytti Sent: Wednesday, August 14, 2013 12:34 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Mixed Cisco/Juniper MPLS network I'd only use separate blocks if I specifically have next-hops which MUST NOT be label switched (I don't have, but some prefer INET not to be label switched, so they run INET to different loopback than VPNv4) In your case, it seems it would make more sense to figure out what the actual problem is and then go back to flat/static ACL for all core loops. Maybe add one less used non-MPLS box as allowed and reserve some additional resourced to help troubleshooting when problem is in effect. So what you're saying is that there is definitely some other issue here and it's not necessarily the fact that the destinations are allocated labels, but rather the label allocation is exposing an underlying problem. If so, that narrows it down and points me in the right direction. I'm trying to replicate in the lab, as I just had an idea, thanks to your response. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
