Re: [j-nsp] EVPN/VXLAN on QFX5100
Ahh yes, that would indeed work... the L3 lookup for the remote VTEP is independent; so inet.0 or vrf-inet.0 what-have-you. - CK. "L2oVxLANoIPoMPLS" I gotta remember that one ;) On 4 Aug 2016, at 12:13 pm, Tim Jackson wrote: > You can run VXLAN over an MPLS LSP on QFX5100 just fine.. As long as the L3 > lookup for the remote VTEP goes across an LSP the VXLAN traffic will too.. > > But it's not l2ompls.. it's l2ovxlanoipompls. > > -- > Tim > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN/VXLAN on QFX5100
Ahh yes, that would indeed work... the L3 lookup for the remote VTEP is independent; so inet.0 or vrf-inet.0 what-have-you. - CK. "L2oVxLANoIPoMPLS" I gotta remember that one ;) On 4 Aug 2016, at 12:13 pm, Tim Jackson wrote: > You can run VXLAN over an MPLS LSP on QFX5100 just fine.. As long as the L3 > lookup for the remote VTEP goes across an LSP the VXLAN traffic will too.. > > But it's not l2ompls.. it's l2ovxlanoipompls. > > -- > Tim > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN/VXLAN on QFX5100
You can run VXLAN over an MPLS LSP on QFX5100 just fine.. As long as the L3 lookup for the remote VTEP goes across an LSP the VXLAN traffic will too.. But it's not l2ompls.. it's l2ovxlanoipompls. -- Tim On Aug 3, 2016 6:52 PM, "Chris Kawchuk" wrote: > You cannot use MPLS as the "underlay" Transport on QFX51xx. I tried the > same -- you need to use VxLAN as the "transport LSP" so to speak. (Think of > VXLAN remote VTEP IP address as being the outer label, and the VNI is the > inner label.) > > There's a config guide floating around out there on the JNPR Website fort > the QFX manual showing how to setup the VTEPs so that the switches setup an > "inet.3" table between each other for remote-next-hop resolution (from > iBGP/MP-BGP sessions), pointing to a remote VTEP IP. > > Good luck! Would be nice if they could do MPLS as the underlay, but > <-insert Trident2+ Pipeline issues-> here. > > - CK. > > > On 4 Aug 2016, at 7:19 am, Joe Freeman wrote: > > > The QFX's are connected via an MPLS/IP connection with LDP/RSVP/ISIS, and > > MP-IBGP. > > > > A show evpn instance extensive command shows that the two switches see > each > > other, but I am unable to learn mac addresses between them. > > ___ > 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] 100mbps bandwidth on a logical interface
This would explain the bandwidth value: https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR471628 Cheers On Thu., 4 Aug. 2016, 01:29 Jonathan Call, wrote: > This is an old switch running 11.4R2. The class-of-service shows nothing > of significance: > > Physical interface: ge-0/0/27, Index: 157 > Queues supported: 8, Queues in use: 4 > Scheduler map: , Index: 2 > Congestion-notification: Disabled > > Logical interface: ge-0/0/27.0, Index: 123 > Object Name Type > Index > Classifier ieee8021p-untrust untrust > 16 > > This value seems so obscure you're probably correct that it is some random > PR. > > Jonathan > > I apologize if this doesn't show up formatted properly. For some reason my > Macbook does not seems to copy and paste well in Hotmail. > > From: dale.s...@gmail.com on behalf of Dale Shaw < > dale.shaw+j-...@gmail.com> > Sent: Wednesday, August 3, 2016 12:53 AM > To: Jonathan Call > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] 100mbps bandwidth on a logical interface > > > Hi Jonathan, > > On 3 August 2016 at 16:23, Jonathan Call wrote: > > > > I have a Gigabit Ethernet port on an EX4200 that is performing very > poorly. It maxes out at about 120Mbps under heavy load. During that heavy > load I see MAC pause frame values increasing as well as dropped packets in > the queue counters. All of this points to the server being the culprit. > [...] > > > > What output do you see with "show class-of-service interface ge-0/0/27" ? > > > I assume based on the existence of "ge-0/0/27" that it's a EX4200-48T/P. > Which Junos release are you running? (might help folks match a PR, if there > is one) > > > Cheers, > Dale > > > ___ > 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] EVPN/VXLAN on QFX5100
You cannot use MPLS as the "underlay" Transport on QFX51xx. I tried the same -- you need to use VxLAN as the "transport LSP" so to speak. (Think of VXLAN remote VTEP IP address as being the outer label, and the VNI is the inner label.) There's a config guide floating around out there on the JNPR Website fort the QFX manual showing how to setup the VTEPs so that the switches setup an "inet.3" table between each other for remote-next-hop resolution (from iBGP/MP-BGP sessions), pointing to a remote VTEP IP. Good luck! Would be nice if they could do MPLS as the underlay, but <-insert Trident2+ Pipeline issues-> here. - CK. On 4 Aug 2016, at 7:19 am, Joe Freeman wrote: > The QFX's are connected via an MPLS/IP connection with LDP/RSVP/ISIS, and > MP-IBGP. > > A show evpn instance extensive command shows that the two switches see each > other, but I am unable to learn mac addresses between them. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EVPN/VXLAN on QFX5100
Joe Qfx5100 does not supoort vpls at least in last 14.1 release Only L2circuit point to point !!! I will double check but it is almost sure ... The correct equipment would be ACX5048 for it EVPN with VXLAN is supoorted but this is a datacenter features that will not transport protocols bpdu ... most like a pdu feature Following the public document that shows how to configure it ... http://www.juniper.net/techpubs/en_US/junos14.1/information-products/pathway-pages/junos-sdn/evpn-vxlan.pdf Att Giuliano Sent from my iPhone > On 3 Aug 2016, at 18:19, Joe Freeman wrote: > > Does anyone have working sample config they can share? > > Our SE recommended trying to use EVPN on our 5100's in place of VPLS since > it's not supported on the 5100's. I'm having trouble getting it to work > between two QFX's in my lab. > > The QFX's are connected via an MPLS/IP connection with LDP/RSVP/ISIS, and > MP-IBGP. > > A show evpn instance extensive command shows that the two switches see each > other, but I am unable to learn mac addresses between them. > > Thanks- > Joe > ___ > 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] BGP/MPLS Question MX Platform
Hello, On 03/08/2016 22:09, Dean B wrote: Thanks. I think the part I'm missing is associating the IP traffic to an LSP and how to prevent it from just going back to IGP routing when the LSP fails. There are several ways to do that. 1) use forwarding-table policy to associate BGP routes with a particular LSP https://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/install-nexthop-edit-policy-options.html This policy should have 2 terms: term 1 from community BGP-ROUTE-COMM then install-nexthop lsp ; term 2 from community BGP-ROUTE-COMM then next-hop discard 2/ You can deny resolution of BGP routes' nexthop via inet.0, and let it only use inet.3. By default, BGP routes' nexthop is resolved via inet.3 and then, if no joy, via inet.0. If You deny inet.0 usage for BGP routes' nexthop resolution, BGP routes will be invaldated once LSP fails. The command is set routing-options resolution rib inet.0 resolution-rib inet.3 3/ You also can configure static discard routes in inet.3 table to set all BGP routes' nexthops to discard should A-C LSP fail: In router A: set routing-options rib inet.3 static route loopback>/32 discard preference 8 In router C: set routing-options rib inet.3 static route loopback>/32 discard preference 8 But - if there are MPLS VPN between A and C, and You want them continue using LDP, then (3) is not a good option. With (3), A-C MPLS VPN will stop working after A-C LSP fails whereas in option (2) only IP traffic will stop working. HTH Thx Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
Interesting...but that wouldn't that break locally connected interfaces that are just IP? On Wed, Aug 3, 2016 at 4:20 PM, Saku Ytti wrote: > On 4 August 2016 at 00:18, Saku Ytti wrote: > > So question is 'how do I ensure, next-hop is only valid when it's via > > LSP tunnel', I'm sure there is good canonical answer to it, but I > > don't know it. > > Aah, I think I know. You can define your resolve ribs in JunOS, just > drop inet.0 from there, then you won't be able to forward traffic > without labeled next-hop. > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
On 4 August 2016 at 00:18, Saku Ytti wrote: > So question is 'how do I ensure, next-hop is only valid when it's via > LSP tunnel', I'm sure there is good canonical answer to it, but I > don't know it. Aah, I think I know. You can define your resolve ribs in JunOS, just drop inet.0 from there, then you won't be able to forward traffic without labeled next-hop. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EVPN/VXLAN on QFX5100
Does anyone have working sample config they can share? Our SE recommended trying to use EVPN on our 5100's in place of VPLS since it's not supported on the 5100's. I'm having trouble getting it to work between two QFX's in my lab. The QFX's are connected via an MPLS/IP connection with LDP/RSVP/ISIS, and MP-IBGP. A show evpn instance extensive command shows that the two switches see each other, but I am unable to learn mac addresses between them. Thanks- Joe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
On 4 August 2016 at 00:09, Dean B wrote: > Thanks. I think the part I'm missing is associating the IP traffic to an > LSP and how to prevent it from just going back to IGP routing when the LSP > fails. From everything I can see it will just drop back to IGP routes if > the LSP disappears. Good point. There must be clean solution, but at least one really dirty solution I can think of, is to ensure you won't have labels to next-hop without RSVP (e.g. LDP in RSVP). Then ensure unlabeled traffic isn't sent out from the box (simple egress fw filter on edge devices interfaces towards core devices will do). It's not exactly kosher, because the route is valid, so you can advertise (and pull traffic) without able to forward it. Which may be huge deal-breaker, or non-issue, depending on your edge services. So question is 'how do I ensure, next-hop is only valid when it's via LSP tunnel', I'm sure there is good canonical answer to it, but I don't know it. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
Thanks. I think the part I'm missing is associating the IP traffic to an LSP and how to prevent it from just going back to IGP routing when the LSP fails. From everything I can see it will just drop back to IGP routes if the LSP disappears. On Wed, Aug 3, 2016 at 4:03 PM, Saku Ytti wrote: > Without reading or doing the work (yay for drive-by-support). Be sure > you forbid the paths from going into secondary paths, just allow them > to fail. > > > Also look into affinities/colors, you can colour code links, and then > tell LSP which colors it is allowed to traverse. Make all your links > blue, but the high-cost link red, and make sure IP traffic LSPs are > allowed to use only blue, but L2VPN is also allowed to use red. > > Sorry for not providing more specific, or configs. I'm lazy, but I > also see that you have good grasp in what you're doing, so I'm > confident you'll be able to get this working. > > > On 3 August 2016 at 23:38, Dean B wrote: > > Ok, I have attempted to lab this up...config here > > http://pastebin.com/53Ebsd7X > > > > I must still be missing something...BGP appears to still use the IGP and > go > > across the high-cost link when I disable the low-cost link between B-C: > > > > (on B) > > 2.2.2.0/24 *[BGP/170] 00:12:13, localpref 100, from 10.10.10.1 > > AS path: 174 I, validation-state: unverified > > > to 10.0.1.1 via lt-0/0/10.2, label-switched-path > > LSP-B-C-L2VPN > > > > The other LSPs do drop that should not be going over the high-cost link. > > I'm guessing I need some knob to tell BGP which LSP to use or not to use? > > > > dean@lab# run show rsvp session logical-system A > > Ingress RSVP: 1 sessions > > To FromState Rt Style Labelin Labelout LSPname > > 10.10.10.2 10.10.10.3 Up 0 1 FF -3 LSP-A-B > > Total 1 displayed, Up 1, Down 0 > > > > Egress RSVP: 1 sessions > > To FromState Rt Style Labelin Labelout LSPname > > 10.10.10.3 10.10.10.2 Up 0 1 FF 3- LSP-B-A > > Total 1 displayed, Up 1, Down 0 > > > > Transit RSVP: 2 sessions > > To FromState Rt Style Labelin Labelout LSPname > > 10.10.10.1 10.10.10.2 Up 0 1 FF 2997923 > > LSP-B-C-L2VPN > > 10.10.10.2 10.10.10.1 Up 0 1 FF 2998083 > > LSP-C-B-L2VPN > > Total 2 displayed, Up 2, Down 0 > > > > dean@lab# run show rsvp session logical-system B > > Ingress RSVP: 2 sessions > > To FromState Rt Style Labelin Labelout LSPname > > 10.10.10.1 10.10.10.2 Up 0 1 FF - 299792 > > LSP-B-C-L2VPN > > 10.10.10.3 10.10.10.2 Up 0 1 FF -3 LSP-B-A > > Total 2 displayed, Up 2, Down 0 > > > > Egress RSVP: 2 sessions > > To FromState Rt Style Labelin Labelout LSPname > > 10.10.10.2 10.10.10.3 Up 0 1 FF 3- LSP-A-B > > 10.10.10.2 10.10.10.1 Up 0 1 FF 3- > > LSP-C-B-L2VPN > > Total 2 displayed, Up 2, Down 0 > > > > Transit RSVP: 0 sessions > > Total 0 displayed, Up 0, Down 0 > > > > dean@lab# run show rsvp session logical-system C > > Ingress RSVP: 1 sessions > > To FromState Rt Style Labelin Labelout LSPname > > 10.10.10.2 10.10.10.1 Up 0 1 FF - 299808 > > LSP-C-B-L2VPN > > Total 1 displayed, Up 1, Down 0 > > > > Egress RSVP: 1 sessions > > To FromState Rt Style Labelin Labelout LSPname > > 10.10.10.1 10.10.10.2 Up 0 1 FF 3- > > LSP-B-C-L2VPN > > Total 1 displayed, Up 1, Down 0 > > > > Transit RSVP: 0 sessions > > Total 0 displayed, Up 0, Down 0 > > > > On Wed, Aug 3, 2016 at 12:18 PM, Saku Ytti wrote: > >> > >> On 3 August 2016 at 19:36, Dean B wrote: > >> > >> Hey, > >> > >> > Hey Saku thanks for clarifying...it makes sense now. So for your > option > >> > "c" > >> > I would just set the ISIS metric to have a higher cost on the > expensive > >> > A-C > >> > link so that it would not normally be used right? I have sample lab > >> > logical > >> > system config here: http://pastebin.com/uzHtzWrw > >> > >> No. In option C you'd have proper metric, metric which cases expensive > >> link to be used normally. But as all traffic would be in RSVP tunnels, > >> you'd ultimately be unable to put LSPs on the SPT path, because there > >> isn't enough capacity, then subsequent LSPs would fall back to off SPT > >> paths, to avoid the congested link. > >> And if there are no available path, then some LPSs would just simply > >> not establish and you'd blackhole traffic. > >> > >> > I'm assuming I need to add an additional LSP to each node that has a > >> > higher > >> > priority and then use that LSP for the l2circuit traffic. What else > >> > would I > >> > need to get the option "c" with blackhole of other traffic during > >> > low-cost
Re: [j-nsp] BGP/MPLS Question MX Platform
Without reading or doing the work (yay for drive-by-support). Be sure you forbid the paths from going into secondary paths, just allow them to fail. Also look into affinities/colors, you can colour code links, and then tell LSP which colors it is allowed to traverse. Make all your links blue, but the high-cost link red, and make sure IP traffic LSPs are allowed to use only blue, but L2VPN is also allowed to use red. Sorry for not providing more specific, or configs. I'm lazy, but I also see that you have good grasp in what you're doing, so I'm confident you'll be able to get this working. On 3 August 2016 at 23:38, Dean B wrote: > Ok, I have attempted to lab this up...config here > http://pastebin.com/53Ebsd7X > > I must still be missing something...BGP appears to still use the IGP and go > across the high-cost link when I disable the low-cost link between B-C: > > (on B) > 2.2.2.0/24 *[BGP/170] 00:12:13, localpref 100, from 10.10.10.1 > AS path: 174 I, validation-state: unverified > > to 10.0.1.1 via lt-0/0/10.2, label-switched-path > LSP-B-C-L2VPN > > The other LSPs do drop that should not be going over the high-cost link. > I'm guessing I need some knob to tell BGP which LSP to use or not to use? > > dean@lab# run show rsvp session logical-system A > Ingress RSVP: 1 sessions > To FromState Rt Style Labelin Labelout LSPname > 10.10.10.2 10.10.10.3 Up 0 1 FF -3 LSP-A-B > Total 1 displayed, Up 1, Down 0 > > Egress RSVP: 1 sessions > To FromState Rt Style Labelin Labelout LSPname > 10.10.10.3 10.10.10.2 Up 0 1 FF 3- LSP-B-A > Total 1 displayed, Up 1, Down 0 > > Transit RSVP: 2 sessions > To FromState Rt Style Labelin Labelout LSPname > 10.10.10.1 10.10.10.2 Up 0 1 FF 2997923 > LSP-B-C-L2VPN > 10.10.10.2 10.10.10.1 Up 0 1 FF 2998083 > LSP-C-B-L2VPN > Total 2 displayed, Up 2, Down 0 > > dean@lab# run show rsvp session logical-system B > Ingress RSVP: 2 sessions > To FromState Rt Style Labelin Labelout LSPname > 10.10.10.1 10.10.10.2 Up 0 1 FF - 299792 > LSP-B-C-L2VPN > 10.10.10.3 10.10.10.2 Up 0 1 FF -3 LSP-B-A > Total 2 displayed, Up 2, Down 0 > > Egress RSVP: 2 sessions > To FromState Rt Style Labelin Labelout LSPname > 10.10.10.2 10.10.10.3 Up 0 1 FF 3- LSP-A-B > 10.10.10.2 10.10.10.1 Up 0 1 FF 3- > LSP-C-B-L2VPN > Total 2 displayed, Up 2, Down 0 > > Transit RSVP: 0 sessions > Total 0 displayed, Up 0, Down 0 > > dean@lab# run show rsvp session logical-system C > Ingress RSVP: 1 sessions > To FromState Rt Style Labelin Labelout LSPname > 10.10.10.2 10.10.10.1 Up 0 1 FF - 299808 > LSP-C-B-L2VPN > Total 1 displayed, Up 1, Down 0 > > Egress RSVP: 1 sessions > To FromState Rt Style Labelin Labelout LSPname > 10.10.10.1 10.10.10.2 Up 0 1 FF 3- > LSP-B-C-L2VPN > Total 1 displayed, Up 1, Down 0 > > Transit RSVP: 0 sessions > Total 0 displayed, Up 0, Down 0 > > On Wed, Aug 3, 2016 at 12:18 PM, Saku Ytti wrote: >> >> On 3 August 2016 at 19:36, Dean B wrote: >> >> Hey, >> >> > Hey Saku thanks for clarifying...it makes sense now. So for your option >> > "c" >> > I would just set the ISIS metric to have a higher cost on the expensive >> > A-C >> > link so that it would not normally be used right? I have sample lab >> > logical >> > system config here: http://pastebin.com/uzHtzWrw >> >> No. In option C you'd have proper metric, metric which cases expensive >> link to be used normally. But as all traffic would be in RSVP tunnels, >> you'd ultimately be unable to put LSPs on the SPT path, because there >> isn't enough capacity, then subsequent LSPs would fall back to off SPT >> paths, to avoid the congested link. >> And if there are no available path, then some LPSs would just simply >> not establish and you'd blackhole traffic. >> >> > I'm assuming I need to add an additional LSP to each node that has a >> > higher >> > priority and then use that LSP for the l2circuit traffic. What else >> > would I >> > need to get the option "c" with blackhole of other traffic during >> > low-cost >> > path failure? >> >> For C you'd need need full-mesh RSVP. >> >> -- >> ++ytti > > -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
Ok, I have attempted to lab this up...config here http://pastebin.com/53Ebsd7X I must still be missing something...BGP appears to still use the IGP and go across the high-cost link when I disable the low-cost link between B-C: (on B) 2.2.2.0/24 *[BGP/170] 00:12:13, localpref 100, from 10.10.10.1 AS path: 174 I, validation-state: unverified > to 10.0.1.1 via lt-0/0/10.2, label-switched-path LSP-B-C-L2VPN The other LSPs do drop that should not be going over the high-cost link. I'm guessing I need some knob to tell BGP which LSP to use or not to use? dean@lab# run show rsvp session logical-system A Ingress RSVP: 1 sessions To FromState Rt Style Labelin Labelout LSPname 10.10.10.2 10.10.10.3 Up 0 1 FF -3 LSP-A-B Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions To FromState Rt Style Labelin Labelout LSPname 10.10.10.3 10.10.10.2 Up 0 1 FF 3- LSP-B-A Total 1 displayed, Up 1, Down 0 Transit RSVP: 2 sessions To FromState Rt Style Labelin Labelout LSPname 10.10.10.1 10.10.10.2 Up 0 1 FF 2997923 LSP-B-C-L2VPN 10.10.10.2 10.10.10.1 Up 0 1 FF 2998083 LSP-C-B-L2VPN Total 2 displayed, Up 2, Down 0 dean@lab# run show rsvp session logical-system B Ingress RSVP: 2 sessions To FromState Rt Style Labelin Labelout LSPname 10.10.10.1 10.10.10.2 Up 0 1 FF - 299792 LSP-B-C-L2VPN 10.10.10.3 10.10.10.2 Up 0 1 FF -3 LSP-B-A Total 2 displayed, Up 2, Down 0 Egress RSVP: 2 sessions To FromState Rt Style Labelin Labelout LSPname 10.10.10.2 10.10.10.3 Up 0 1 FF 3- LSP-A-B 10.10.10.2 10.10.10.1 Up 0 1 FF 3- LSP-C-B-L2VPN Total 2 displayed, Up 2, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 dean@lab# run show rsvp session logical-system C Ingress RSVP: 1 sessions To FromState Rt Style Labelin Labelout LSPname 10.10.10.2 10.10.10.1 Up 0 1 FF - 299808 LSP-C-B-L2VPN Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions To FromState Rt Style Labelin Labelout LSPname 10.10.10.1 10.10.10.2 Up 0 1 FF 3- LSP-B-C-L2VPN Total 1 displayed, Up 1, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 On Wed, Aug 3, 2016 at 12:18 PM, Saku Ytti wrote: > On 3 August 2016 at 19:36, Dean B wrote: > > Hey, > > > Hey Saku thanks for clarifying...it makes sense now. So for your option > "c" > > I would just set the ISIS metric to have a higher cost on the expensive > A-C > > link so that it would not normally be used right? I have sample lab > logical > > system config here: http://pastebin.com/uzHtzWrw > > No. In option C you'd have proper metric, metric which cases expensive > link to be used normally. But as all traffic would be in RSVP tunnels, > you'd ultimately be unable to put LSPs on the SPT path, because there > isn't enough capacity, then subsequent LSPs would fall back to off SPT > paths, to avoid the congested link. > And if there are no available path, then some LPSs would just simply > not establish and you'd blackhole traffic. > > > I'm assuming I need to add an additional LSP to each node that has a > higher > > priority and then use that LSP for the l2circuit traffic. What else > would I > > need to get the option "c" with blackhole of other traffic during > low-cost > > path failure? > > For C you'd need need full-mesh RSVP. > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
On 3 August 2016 at 19:36, Dean B wrote: Hey, > Hey Saku thanks for clarifying...it makes sense now. So for your option "c" > I would just set the ISIS metric to have a higher cost on the expensive A-C > link so that it would not normally be used right? I have sample lab logical > system config here: http://pastebin.com/uzHtzWrw No. In option C you'd have proper metric, metric which cases expensive link to be used normally. But as all traffic would be in RSVP tunnels, you'd ultimately be unable to put LSPs on the SPT path, because there isn't enough capacity, then subsequent LSPs would fall back to off SPT paths, to avoid the congested link. And if there are no available path, then some LPSs would just simply not establish and you'd blackhole traffic. > I'm assuming I need to add an additional LSP to each node that has a higher > priority and then use that LSP for the l2circuit traffic. What else would I > need to get the option "c" with blackhole of other traffic during low-cost > path failure? For C you'd need need full-mesh RSVP. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
Hey Saku thanks for clarifying...it makes sense now. So for your option "c" I would just set the ISIS metric to have a higher cost on the expensive A-C link so that it would not normally be used right? I have sample lab logical system config here: http://pastebin.com/uzHtzWrw I'm assuming I need to add an additional LSP to each node that has a higher priority and then use that LSP for the l2circuit traffic. What else would I need to get the option "c" with blackhole of other traffic during low-cost path failure? Thanks again for all the help. On Wed, Aug 3, 2016 at 11:01 AM, Saku Ytti wrote: > On 3 August 2016 at 18:49, Dean B wrote: > > Hey, > > > Ok, that is going to show how inexperienced I am in MPLS/RSVP/etc. but > what > > is the SPT you are referring to and what JunOS config elements does it > > Shortest Path Tree (result of SPF algorithm). Essentially I'm talking > how you'll configure your IGP, will the expensive link be chosen as > result of IGP configuration or not. > > > Speaking of QoS, might another way to solve this (assuming I could mark > > traffic eligible to discard) be to use use QoS on both sides of the > > high-cost link and just discard that marked traffic? Then I could just > let > > the existing ISIS/LDP stuff do it's thing. > > Devices really don't support exactly this behaviour, not these days. > But if the link is say 1Gbps and you know you won't have more than > 600Mbps of L2VPN. Then if you give L2VPN class/queue >=60% guarantee, > and rest for other traffic, then you'll never drop the L2VPN. Of > course you could do 98% L2VPN, 1% signalling and 1% all other traffic. > Bandwidth will be 'loaned' from class which is not using its > guarantee, so it'll work just fine. > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
On 3 August 2016 at 18:49, Dean B wrote: Hey, > Ok, that is going to show how inexperienced I am in MPLS/RSVP/etc. but what > is the SPT you are referring to and what JunOS config elements does it Shortest Path Tree (result of SPF algorithm). Essentially I'm talking how you'll configure your IGP, will the expensive link be chosen as result of IGP configuration or not. > Speaking of QoS, might another way to solve this (assuming I could mark > traffic eligible to discard) be to use use QoS on both sides of the > high-cost link and just discard that marked traffic? Then I could just let > the existing ISIS/LDP stuff do it's thing. Devices really don't support exactly this behaviour, not these days. But if the link is say 1Gbps and you know you won't have more than 600Mbps of L2VPN. Then if you give L2VPN class/queue >=60% guarantee, and rest for other traffic, then you'll never drop the L2VPN. Of course you could do 98% L2VPN, 1% signalling and 1% all other traffic. Bandwidth will be 'loaned' from class which is not using its guarantee, so it'll work just fine. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
Ok, that is going to show how inexperienced I am in MPLS/RSVP/etc. but what is the SPT you are referring to and what JunOS config elements does it correspond to? Having trouble translating the terms into example config :-) I would probably just start with c (discard 100% of other traffic) then perhaps look into the QoS. Speaking of QoS, might another way to solve this (assuming I could mark traffic eligible to discard) be to use use QoS on both sides of the high-cost link and just discard that marked traffic? Then I could just let the existing ISIS/LDP stuff do it's thing. On Wed, Aug 3, 2016 at 10:28 AM, Saku Ytti wrote: > On 3 August 2016 at 18:10, Dean B wrote: > > Hey, > > > Thanks for everyone's suggestions. RSVP-TE looks like it would be the > > cleanest solution. I'm still a little lost on how that would be > > implemented. Saku in what you are suggesting would the following be > > correct: > > > > ISIS with traffic engineering enabled on all the ring links > > RSVP enabled on all the ring links > > LSPs with normal priority configured on each node to every other node for > > BGP to use > > LSPs configured for l2vpn use on each node that requires them and set > them > > to a high reservation priority > > I essentially have three options: > > a) use SPT, where the expensive link isn't used, put L2VPN with > segment routing on the expensive link > b) use SPT, where the expensive link isn't used, put L2VPN with RSVP > on the expensive link > c) use SPT, where the expensive link is used, have all traffic in RSVP > tunnels, so that non L2VPN traffic will fall-off the SPT path, due to > lack of capacity > > If the low-cost SPT breaks down, and only high-cost link is possible, > what is your desired outcome? > > 1) blackhole 100% of traffic that would switch to the high-cost link > 2) use QoS so that all existing traffic on high-cost link works, but > also all other demand is moved there, and pushed through as much as > possible > > For 2) all of a-c can do it. > For 1) you need c > > > > > > > > So in case of a failure of one of the low-cost links the high reservation > > priority on the l2vpn LSPs will only allow them to form on the expensive > > path and the BGP LSPs will just be down? What will keep BGP from just > using > > the IGP best path at that point? > > > > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 15.1 on MX104
Hi Josh, There's no 15.1R6 yet, but 15.1R4 (or 15.1F6 for Features on steroids release train). There no new Freebsd on PPC platform (so no SMP, no new partitioning scheme and so on). Since 15.1 on PPC is not "Junos OS with upgraded FreeBSD", I suppose there's just no change about memory allocation on MX80/104. Some examples on two MX104 updated to 15.1R4 here: obenghozi@rg-co-01-bodir1-re0> show system processes extensive last pid: 28137; load averages: 0.10, 0.04, 0.01 up 14+17:00:5517:24:04 140 processes: 3 running, 115 sleeping, 22 waiting Mem: 495M Active, 52M Inact, 142M Wired, 277M Cache, 112M Buf, 2904M Free Swap: 1025M Total, 1025M Free obenghozi@rg-co-01-bodir1-re0> show system memory System memory usage distribution: Total memory: 4034560 Kbytes (100%) Reserved memory: 71456 Kbytes ( 1%) Wired memory: 145052 Kbytes ( 3%) Active memory: 506620 Kbytes ( 12%) Inactive memory: 52880 Kbytes ( 1%) Cache memory: 284128 Kbytes ( 7%) Free memory: 2973688 Kbytes ( 73%) Memory disk resident memory: 67932 Kbytes obenghozi@rg-co-01-rhesfr1-re0> show system processes extensive last pid: 13111; load averages: 0.08, 0.10, 0.03 up 5+02:40:3017:23:41 140 processes: 2 running, 116 sleeping, 22 waiting Mem: 482M Active, 51M Inact, 103M Wired, 394M Cache, 112M Buf, 2840M Free Swap: 1025M Total, 1025M Free obenghozi@rg-co-01-rhesfr1-re0> show system memory System memory usage distribution: Total memory: 4034560 Kbytes (100%) Reserved memory: 71456 Kbytes ( 1%) Wired memory: 105404 Kbytes ( 2%) Active memory: 492668 Kbytes ( 12%) Inactive memory: 51892 Kbytes ( 1%) Cache memory: 403340 Kbytes ( 9%) Free memory: 2908996 Kbytes ( 72%) Memory disk resident memory: 57644 Kbytes regards, Olivier > Le 3 août 2016 à 17:14, Josh Baird a écrit : > > I have a MX104 running 13.3R6.5 that is hitting PR1080566. I'm looking to > either upgrade to 14.2R6 or 15.1R6. I know that a new FreeBSD kernel is > introduced in 15.1, but based on the PPC architecture of the RE-MX-104, I > don't believe I will be able to take advantage of the new kernel so I won't > get the key features like SMP, etc [1]. Is this a correct statement? > > In addition, it appears that in versions prior to 15.1, the MX104 is able > to utilize the full 4GB on a 32bit platform due to the way that swap pages > were counted as part of the memory file system partition. Starting in > 15.1, this has changed and I will only get 3Gb usable [1]. This box will > be taking three full tables, so I think having the additional 1Gb of memory > will be beneficial. > > Given that the MX104 cannot really take advantage of the new FreeBSD kernel > and associated features (SMP, etc) and that total available memory will be > decreased, I'm thinking of upgrading to 14.2R6 instead. What are > everyone's thoughts? > > [1] Page 17 - > http://www.juniper.net/techpubs/en_US/junos15.1/information-products/pathway-pages/software-installation-and-upgrade/software-installation-and-upgrade.pdf ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
On 3 August 2016 at 18:10, Dean B wrote: Hey, > Thanks for everyone's suggestions. RSVP-TE looks like it would be the > cleanest solution. I'm still a little lost on how that would be > implemented. Saku in what you are suggesting would the following be > correct: > > ISIS with traffic engineering enabled on all the ring links > RSVP enabled on all the ring links > LSPs with normal priority configured on each node to every other node for > BGP to use > LSPs configured for l2vpn use on each node that requires them and set them > to a high reservation priority I essentially have three options: a) use SPT, where the expensive link isn't used, put L2VPN with segment routing on the expensive link b) use SPT, where the expensive link isn't used, put L2VPN with RSVP on the expensive link c) use SPT, where the expensive link is used, have all traffic in RSVP tunnels, so that non L2VPN traffic will fall-off the SPT path, due to lack of capacity If the low-cost SPT breaks down, and only high-cost link is possible, what is your desired outcome? 1) blackhole 100% of traffic that would switch to the high-cost link 2) use QoS so that all existing traffic on high-cost link works, but also all other demand is moved there, and pushed through as much as possible For 2) all of a-c can do it. For 1) you need c > > So in case of a failure of one of the low-cost links the high reservation > priority on the l2vpn LSPs will only allow them to form on the expensive > path and the BGP LSPs will just be down? What will keep BGP from just using > the IGP best path at that point? -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 100mbps bandwidth on a logical interface
This is an old switch running 11.4R2. The class-of-service shows nothing of significance: Physical interface: ge-0/0/27, Index: 157 Queues supported: 8, Queues in use: 4 Scheduler map: , Index: 2 Congestion-notification: Disabled Logical interface: ge-0/0/27.0, Index: 123 Object Name TypeIndex Classifier ieee8021p-untrust untrust16 This value seems so obscure you're probably correct that it is some random PR. Jonathan I apologize if this doesn't show up formatted properly. For some reason my Macbook does not seems to copy and paste well in Hotmail. From: dale.s...@gmail.com on behalf of Dale Shaw Sent: Wednesday, August 3, 2016 12:53 AM To: Jonathan Call Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] 100mbps bandwidth on a logical interface Hi Jonathan, On 3 August 2016 at 16:23, Jonathan Call wrote: > > I have a Gigabit Ethernet port on an EX4200 that is performing very poorly. > It maxes out at about 120Mbps under heavy load. During that heavy load I see > MAC pause frame values increasing as well as dropped packets in the queue > counters. All of this points to the server being the culprit. [...] What output do you see with "show class-of-service interface ge-0/0/27" ? I assume based on the existence of "ge-0/0/27" that it's a EX4200-48T/P. Which Junos release are you running? (might help folks match a PR, if there is one) Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 15.1 on MX104
Hi, I have a MX104 running 13.3R6.5 that is hitting PR1080566. I'm looking to either upgrade to 14.2R6 or 15.1R6. I know that a new FreeBSD kernel is introduced in 15.1, but based on the PPC architecture of the RE-MX-104, I don't believe I will be able to take advantage of the new kernel so I won't get the key features like SMP, etc [1]. Is this a correct statement? In addition, it appears that in versions prior to 15.1, the MX104 is able to utilize the full 4GB on a 32bit platform due to the way that swap pages were counted as part of the memory file system partition. Starting in 15.1, this has changed and I will only get 3Gb usable [1]. This box will be taking three full tables, so I think having the additional 1Gb of memory will be beneficial. Given that the MX104 cannot really take advantage of the new FreeBSD kernel and associated features (SMP, etc) and that total available memory will be decreased, I'm thinking of upgrading to 14.2R6 instead. What are everyone's thoughts? [1] Page 17 - http://www.juniper.net/techpubs/en_US/junos15.1/information-products/pathway-pages/software-installation-and-upgrade/software-installation-and-upgrade.pdf Thanks, Josh ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
Thanks for everyone's suggestions. RSVP-TE looks like it would be the cleanest solution. I'm still a little lost on how that would be implemented. Saku in what you are suggesting would the following be correct: ISIS with traffic engineering enabled on all the ring links RSVP enabled on all the ring links LSPs with normal priority configured on each node to every other node for BGP to use LSPs configured for l2vpn use on each node that requires them and set them to a high reservation priority So in case of a failure of one of the low-cost links the high reservation priority on the l2vpn LSPs will only allow them to form on the expensive path and the BGP LSPs will just be down? What will keep BGP from just using the IGP best path at that point? On Wed, Aug 3, 2016 at 5:57 AM, Saku Ytti wrote: > On 2 August 2016 at 23:38, Mark Tinka wrote: > >> I'm not opposed to using RSVP if necessary. All links are MPLS > >> capable...just trying to find a way to not let BGP use the A-C link > >> for IP transit traffic and only use it for protection of the MPLS > >> traffic. A-C is a smaller capacity link than the others which is why > >> I don't want to saturate it with IP traffic that can just come from A > >> or C directly. > > > > Good use-case for RSVP-TE. > > RSVP-TE is good solution here, if OP wants to put all traffic in RSVP > tunnels. Make sure expensive path is in SPT, but give L2VPN LSPs > reservation priority, so once the link is full, other traffic will be > off SPT and not use that link. Ensuring maximum amount of traffic gets > best possible service. > > If OP does not want all traffic in RSVP, rather make SPT where > expensive path isn't used, and just put L2VPN in ERO tunnels using > that link. If this is the goal, then I'd absolutely look into Segment > Routing, unsure if it's yet configurable like this in JunOS, dunno how > far 16.1 is in SR implementation, but worth researching. > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 100mbps bandwidth on a logical interface
On 3 August 2016 at 09:23, Jonathan Call wrote: > Neither the port nor the switch has any policer/rate limiting policy defined. > The port is assigned to one VLAN and that VLAN has nothing defined except a > vlan-id. So where does this "Bandwidth: 100mbps" value for the logical > interface come from? On all of the other interfaces that value is 0. I don't think it matters, I think it's only used for SNMP. But for documentation purposes, may be useful to have them set correctly, especially if it's subrate port, so that SNMP has idea of maximum rate. I would disable pause frames, there is no point for server with plethora of memory to ask EX4200 with tiny buffers to buffer for it. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP/MPLS Question MX Platform
On 2 August 2016 at 23:38, Mark Tinka wrote: >> I'm not opposed to using RSVP if necessary. All links are MPLS >> capable...just trying to find a way to not let BGP use the A-C link >> for IP transit traffic and only use it for protection of the MPLS >> traffic. A-C is a smaller capacity link than the others which is why >> I don't want to saturate it with IP traffic that can just come from A >> or C directly. > > Good use-case for RSVP-TE. RSVP-TE is good solution here, if OP wants to put all traffic in RSVP tunnels. Make sure expensive path is in SPT, but give L2VPN LSPs reservation priority, so once the link is full, other traffic will be off SPT and not use that link. Ensuring maximum amount of traffic gets best possible service. If OP does not want all traffic in RSVP, rather make SPT where expensive path isn't used, and just put L2VPN in ERO tunnels using that link. If this is the goal, then I'd absolutely look into Segment Routing, unsure if it's yet configurable like this in JunOS, dunno how far 16.1 is in SR implementation, but worth researching. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
