Re: [j-nsp] BGP Route Reflectors
On 1/Jun/15 10:42, Raphael Mazelier wrote: I suppose that is refering to the two main mode of design for RRs : - data traffic pass trough the RR, in band RR - data paths are not trought the RR, out of band RR The right terminology would be in-path or out-of-path. But I suppose *-band works just the same. In-path is basically where the RR is an active traffic-forwarding router, typically your core routers. These makes sense because control plane topology would also follow forwarding plane topology. Out-of-path would be where the RR is an independent router through which traffic is never forwarded. It can sit anywhere in the network, and provide routing to its clients anywhere in the network. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BGP Route Reflectors
Hi all I was reading some terms regarding BGP route reflectors and read the terms in-band and out-of-band route reflectors , I searched to see the difference but honestly nothing clear about it , can anyone please explain ? Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP Route Reflectors
Le 01/06/15 10:26, Mohammad Khalil a écrit : Hi all I was reading some terms regarding BGP route reflectors and read the terms in-band and out-of-band route reflectors , I searched to see the difference but honestly nothing clear about it , can anyone please explain ? I suppose that is refering to the two main mode of design for RRs : - data traffic pass trough the RR, in band RR - data paths are not trought the RR, out of band RR -- Raphael Mazelier ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MPLS label stack limits on MX line cards
Hi folks, Before I start labbing I thought I'll just ask around to see if someone has the results already I'm looking for exact numbers for the below: How many labels can be imposed at once on to a frame with PUSH operation? How many labels can be removed at once from a frame with POP operation? What is the overall limit on the number of labels in the stack and what happens to a packet wen this limit is crossed? -well I kind of know the answer to this one. How many labels can MX peek into the frame for load-sharing/hashing? Thanks adam --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Quick way to Shift MPLS traffic away from an interface
Hi, I think this is what you are after: switch-away-lsps https://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/switch-away-lsps-edit-protocols-mpls-interface.html -Marcin. On Wed, May 20, 2015 at 8:55 AM, tim tiriche tim.tiri...@gmail.com wrote: Hello, What is the quick way to shift LSP traffic from an interface after increasing the igp metric? question: - What command can I use to find all lsp traversing the iface and a good way to clear them? I am assuming I would need to run clear mpls optimize-aggressive on the lsp's on that particular router only? Is my understanding correct? - Is it a good idea to turn on optimize-aggressive? Any best practices or pointers would be appreciated! -Tim ___ 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] MPLS label stack limits on MX line cards
The default limit is 3 but you can change it to 5 http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/interfaces-mpls-maximum-labels.html I heard something about increasing this limit probably for segment routing (but it was two years ago ) BTW I didn't find a reference how small platforms that support only 3 labels will be able to do traffic engineering in segment routing (ACX,QFX,ME3600 ) Nitzan On Mon, Jun 1, 2015 at 6:15 PM, Adam Vitkovsky adam.vitkov...@gamma.co.uk wrote: Hi folks, Before I start labbing I thought I'll just ask around to see if someone has the results already I'm looking for exact numbers for the below: How many labels can be imposed at once on to a frame with PUSH operation? How many labels can be removed at once from a frame with POP operation? What is the overall limit on the number of labels in the stack and what happens to a packet wen this limit is crossed? -well I kind of know the answer to this one. How many labels can MX peek into the frame for load-sharing/hashing? Thanks adam --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --- ___ 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] MPLS label stack limits on MX line cards
On (2015-06-01 21:04 +0300), Nitzan Tzelniker wrote: Hey, The default limit is 3 but you can change it to 5 http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/interfaces-mpls-maximum-labels.html I heard something about increasing this limit probably for segment routing (but it was two years ago ) BTW I didn't find a reference how small platforms that support only 3 labels will be able to do traffic engineering in segment routing (ACX,QFX,ME3600 For normal forwarding and even for FRR use cases your label depth would be modest. But as you say, for TE you would have pathological cases where stack will be much deeper. I'm not convinced this is a hard problem. I don't believe the stack depth limit are inherently about byte count, but more about indirection count. And if we think of TE ERO as single indirection, rather than chain of hops, then we might be able to impose multiple labels as single rewrite at one go (at cost of inflating next-hop count) If platform can do IPV6 tunneling, it can impose 40 bytes, it does not seem far fetched that you could impose 10 labels instead, provided they can be returned in single lookup/indirection. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX5100 IRB Interface counters
Hi, I'm having an issue monitoring traffic statistics on IRB interfaces. The counters appear to only be counting control plane traffic. I need to monitor L3 traffic being forwarded on the interface. I've seen some references to this behavior in EX series switches, however not the QFX. Is there a way to accomplish this? I would be grateful for any assistance. Thanks, Vinny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] AP oddness
I have two APs connected to the same EX4200. Both are controlled by the same (and only) WLC. When a client enables WIFI near the first AP that person is able to access the Internet. When the same client enables WIFI under the second AP they cannot connect to the Internet. The port configuration for each AP is identical. The WLC is configured to authenticate clients via Steel Belted Radius (PEAP/802.1X) and put the clients into different VLANs based on their SBR profile. In the case of the first AP the logs show the client IP changing from 0.0.0.0 to the correct IP for their VLAN. In the latter, the client IP is observed changing from 0.0.0.0 to 169.254.x.x as if DHCP (or VLAN assignment) failed. Both ports have the same configuration and any new APs added to the WLC have the same problem. Jonathan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS label stack limits on MX line cards
Hi Saku, I am sure it is solvable issue my concern is that in ASIC platform ( compered to network processor ) it will not be solvable in software and we will have to wait for a one or two hardware refresh cycles before it will be available. Maybe the direction should be to do some kind of hierarchy (as the platforms with the limitation are mostly access devices ) e.g. send the packet with up to 3 labels to the nearest aggregation PE and it will do the traffic engineering (something like H-VPLS ) Nitzan On Mon, Jun 1, 2015 at 11:05 PM, Saku Ytti s...@ytti.fi wrote: On (2015-06-01 21:04 +0300), Nitzan Tzelniker wrote: Hey, The default limit is 3 but you can change it to 5 http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/interfaces-mpls-maximum-labels.html I heard something about increasing this limit probably for segment routing (but it was two years ago ) BTW I didn't find a reference how small platforms that support only 3 labels will be able to do traffic engineering in segment routing (ACX,QFX,ME3600 For normal forwarding and even for FRR use cases your label depth would be modest. But as you say, for TE you would have pathological cases where stack will be much deeper. I'm not convinced this is a hard problem. I don't believe the stack depth limit are inherently about byte count, but more about indirection count. And if we think of TE ERO as single indirection, rather than chain of hops, then we might be able to impose multiple labels as single rewrite at one go (at cost of inflating next-hop count) If platform can do IPV6 tunneling, it can impose 40 bytes, it does not seem far fetched that you could impose 10 labels instead, provided they can be returned in single lookup/indirection. -- ++ytti ___ 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] AP oddness
A few basic questions: - Have you double checked that the APs are configured with an identical set of profiles on all radios? - Are you terminating end user traffic at the AP via a local switching profile, or tunelling everything back to the controller (the default)? If the latter, the only thing that the EX4200 port configuration is relevant to is the AP getting back to the controller. - Have you verified that the users are actually ending up on the right VLAN via show sessions network? - What code rev are you on? I had quite a few problems during the brief time I ran 9.1, so I'd recommend the latest 9.0 release (MR4, I believe). If nothing obvious jumps out, you may also have luck enabling trace debugging for the afflicted client: set trace dot1x level 10 mac mac-addr set trace sm level 10 mac mac-addr set trace radius level 10 mac mac-addr You can then use show log trace to view the buffer, and clear trace all to disable the debugging when you're done. http://kb.juniper.net/InfoCenter/index?page=contentid=KB20351 Frank Sweetser fs at wpi.edu| For every problem, there is a solution that Manager of Network Operations | is simple, elegant, and wrong. Worcester Polytechnic Institute | - HL Mencken On 6/1/2015 4:47 PM, Jonathan Call wrote: I have two APs connected to the same EX4200. Both are controlled by the same (and only) WLC. When a client enables WIFI near the first AP that person is able to access the Internet. When the same client enables WIFI under the second AP they cannot connect to the Internet. The port configuration for each AP is identical. The WLC is configured to authenticate clients via Steel Belted Radius (PEAP/802.1X) and put the clients into different VLANs based on their SBR profile. In the case of the first AP the logs show the client IP changing from 0.0.0.0 to the correct IP for their VLAN. In the latter, the client IP is observed changing from 0.0.0.0 to 169.254.x.x as if DHCP (or VLAN assignment) failed. Both ports have the same configuration and any new APs added to the WLC have the same problem. Jonathan ___ 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
