Re: [j-nsp] MX, ARP cache with L2 bridging
Digging up an old thread here hoping that this was resolved further. I am facing the same problem (in the lab) as the original poster that the ARP cache on an MX platform irb interface actually enters a physical interface rather than the irb.xxx interface. End result being that even if the mac-address moves, layer 3 traffic is still blackholed until the ARP cache expires... Any ideas? Thanks in advance.. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chuck Anderson Sent: Wednesday, 19 September 2012 7:36 AM To: Nicolaj Kamensek Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX, ARP cache with L2 bridging On Tue, Sep 18, 2012 at 11:24:04PM +0200, Nicolaj Kamensek wrote: Am 18.09.2012 20:57, schrieb Chuck Anderson: Hi, That is not true in my experience. L2 MAC Learning takes effect immediately upon seeing traffic enter the new MX port. The ARP entry will point to the new L2 next-hop immediately. interesting because we just had a server being relocated to a different switch on a differekt xe port on the mx and after clearing the arp cache for the specific irb interface, the host was up immediately. We are running 11.4R2.14 and a show arp actually shows the xe interface instead of the irb interfaces as one would expect. It may be that if the server or client host is quiet and not sending anything that MAC learning will not occur right away. In that case the traffic will be sent to the old port until the MAC table entry ages out. By clearing the ARP, you cause the router to send an ARP broadcast to all ports (because something is probably trying to reach the server still), which triggers the otherwise quiet server/client to respond, causing the MX to learn the new L2 port where the MAC address now lives. This is a generic problem with Ethernet MAC learning, not something specific to the MX. If you keep a pinging going FROM the server to the default gateway for example, it should pick up the L2 move fairly quickly. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] S-NAT-IN-MX5-MX10
Yep. S-NAT-IN-MX5-MX10 is for inline NAT on the Trio which is 1:1 NAT with no PAT. Totally stateless. For CG-NAT variants you need an MS-MIC service card (MS-MIC-16G) which sits in the back of the MX80 and the correct licence JAA-NAT-1, JAA-NAT-10 or JAA-NAT-100. Cheers, Caillin -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Thursday, 9 January 2014 3:52 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] S-NAT-IN-MX5-MX10 On Thursday, January 09, 2014 03:49:29 AM Skeeve Stevens wrote: I wonder if anyone knows more about this license. S-NAT-IN-MX5-MX10 The description says: INLINE NAT SOFTWARE LICENSE - IT ALLOWS TO RUN NAT FEATURES ON A MX5 OR MX10. But I am not sure what that really means. Is it for LSN/CGN? Is it needed on top of the service card? Someone will need to clarify for me here, but if this is the same inline NAT services you get on the bigger chassis, it will only support 1:1 NAT. Mark. -- This transmission or any part of it is intended solely for the named addressee. It is confidential. The copying or distribution of this transmission or any information it contains, by anyone other than the addressee, is prohibited. CommTel Network Solutions cannot be held accountable for any comments, statements or attachments. If you have received this transmission in error, please phone +61 3 8340 6100 or by reply e-mail to the sender. If you are not the named addressee, you must destroy the original transmission and its contents. You may not rely on electronically transmitted material unless requested that the transmission is subsequently confirmed by fax or letter. Material transmitted to you should also be checked by reference to a hard copy of that material printed directly from our word processing system. Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos BNG PPPoE inside a VPLS
There are two ways I know of load-sharing PPPoE across BNGs. PADO delay being configure manually on each BNG achieves this but this is a poor way of doing it. If the BNG a client has established with fails then the client holds the PPPoE session up until its timeout and then tries to re-establish to another BNG. The other is a cool feature that the SmartEdge does where you can actually make the PADO only go out if you are the VRRP master (and the PPPoE packets have a source MAC of the VIP). This way when your VRRP fails over and G-ARPs are sent out by the backup BNG it attracts the PPPoE traffic from the client. For an unknown session the backup BNG then immediately sends a PADT which causes the client to re-establish its PPPoE session with the new BNG. I wish this was a feature mirrored by other vendors as it is a nice way of providing backup in case your stateful VC fail-over doesn't work for whatever reason. As mentioned before, if you used PWHT on Juniper you can always dual-home the PW to multiple BNGs but even so the risk is that you have to wait for the CPE to notice a timeout on the PPPoE session before it will try to re-establish with the new BNG. Of course all this says is that you should have a physically diverse VC for each BNG and a redundant path from each MSAN to multiple BNG VCs in case the whole VC dies (failed ISSU anyone?). Cheers, Caillin -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Terebizh, Evgeny Sent: Friday, 27 September 2013 5:34 PM To: Paul Stewart; William Jackson Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Junos BNG PPPoE inside a VPLS I've seen a similar scenario. Yes, I guess it's up to client's machine which PADO to use. Typically host machine answers to the first PADO it gets. It could be assumed that the load would be split between two redundant NAS boxes as the least loaded NAS is gonna serve clients first (I mean it would send PADO back to the client first). I believe same applies to IPoE; the least loaded NAS would send DHCP offer faster and the client would use first offer it gets just like in PPPoe scenario. HTH /ET On 9/27/13 4:24 AM, Paul Stewart p...@paulstewart.org wrote: I'm curious on the load sharing you mentioned here... So you have a VPLS path from DSLAM going to two different BNG nodes at the same time? How does the PPPOE session setup work - first one to answer? (presuming you are referring to PPPOE) Love to hear more about this as we have talked about scenarios like I believe you are referring to... Thanks, Paul On 2013-09-26 5:39 PM, William Jackson william.jack...@gibtele.com wrote: The reason for the VPLS use is that we have multiple BNG nodes that load share the PPPoE sessions. And to mitigate single points of failure. I believe Juniper might just be looking into this scenario as well. ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos BNG PPPoE inside a VPLS
ET It's not that bad comparing to IPoE model. At least you got PPP keepalives, so it won't take a long time for a CPE to re-establish internet connectivity through terminating existing session and creating a new one. As I recall, In IPoE scenario CPE will keep existing session up for 75% of dhcp lease time configured which could take some time unless your CPE supports ARP ping. Anybody knows if Juniper MX/E support this feature? CB DHCP leases can be quite short still, 5 min or less if your router/DHCP server can support it. Some BNGs can also split-lease DHCP (not sure if Juniper can do this, anybody?) where the BNG maintains a short lease with the client but only relays a long lease (1 day etc) to the main DHCP server reducing the resource requirements of the servers. ET Nice feature. As far as I understand you can't achieve load sharing using it, right? You've got single master for existing VRRP group and master handles PADO replies, so when backup BNG takes over it would consider *every* session unknown. Is my understanding correct? CB Yes when the backup BNG takes over it does consider every session unknown and sends a PADT to kill the session immediately on the CPE so it is quite fast to failover. You can also achieve load balancing by running multiple VRRP groups on each interface and tying some subinterfaces/vlan/vlan-ranges to each group. ET Since we're using the juniper mail list it's worth mentioning the Virtual-chassis feature of JUNOS which is kinda nice I believe (didn't use it though). CB I agree with you that Juniper VC on the MX is a fantastic feature and the stateful session failover is great but I would still like to see a last-line-of-defence in case a software bug or ISSU failure brings down the entire VC in one hit. -- This transmission or any part of it is intended solely for the named addressee. It is confidential. The copying or distribution of this transmission or any information it contains, by anyone other than the addressee, is prohibited. CommTel Network Solutions cannot be held accountable for any comments, statements or attachments. If you have received this transmission in error, please phone +61 3 8340 6100 or by reply e-mail to the sender. If you are not the named addressee, you must destroy the original transmission and its contents. You may not rely on electronically transmitted material unless requested that the transmission is subsequently confirmed by fax or letter. Material transmitted to you should also be checked by reference to a hard copy of that material printed directly from our word processing system. Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2VPN Termination
Alternatively use routed VPLS on the core box if it is also an MX and a standard VPLS instance on the edge: http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuratio n/vpls-irb-solutions.html Or if you are game then in the next release you should get psX interfaces on the MX for direct PWHT although it will still be bound to an lt- interface underneath. Documentation already exists for this for 13.1. Caillin -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Friday, 26 July 2013 8:11 AM To: m...@kenweb.org; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] L2VPN Termination lt- interfaces are definitely a way to do it. In my case I put an lt- interface in a VPLS instance that was paired to another lt- with family inet .. in a virtual router instance. I had a routed VPLS for names sake. In my situation though the lt- interface doesn't move much traffic. I'm unsure of what might happen if you tried to move real traffic through it. I'll find out what 400 Mb/s or so of traffic looks like on Monday haha ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-T VPLS fowarding problem
Hi Mathias,
First try adding set chassis fpc XX pic XX tunnel-services
bandwidth 1g|10G. You then have tunnel services on the MX80. Can't
remember if this has any caveats on being done to a live system though..
Also check show route forwarding-table table vpls70134 extensive to
check for forwarding entries.
Cheers,
Caillin
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mathias
Sundman
Sent: Friday, 29 March 2013 9:11 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX5-T VPLS fowarding problem
I've just built a new MPLS network consisting of 6 MX5-T routers using
RSVP signaled LSPs where all routers work a combined P/PE routers.
The core network has been running fine for several weeks. L3VPN works
fine.
Now I try to establish a VPLS Point-to-Point tunnel between two adjacent
routers called solir1 and solir2. Outside of xe-0/0/3 of each router
there is access switch called solis1 and solis2, where I for the testing
purpose has configured an IP in the same subnet on each of the switches:
solis1 config:
interface Vlan1144
ip address 10.155.9.1 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir1,peerint=xe-0/0/3
switchport mode trunk
!
solis2 config:
interface Vlan1244
ip address 10.155.9.2 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir2,peerint=xe-0/0/3
switchport mode trunk
!
solir1 config:
masun@solir1 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1144 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1144;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1144;
route-distinguisher 49079:70134;
vrf-target target:49079:70134;
protocols {
vpls {
site-range 10;
mac-table-size {
1024;
}
mac-statistics;
no-tunnel-services;
site solis1-vpls70134 {
site-identifier 1;
interface xe-0/0/3.1144;
}
}
}
}
}
}
masun@solir1 show configuration interfaces xe-0/0/3 description
type=core,subtype=isc,peer=solis1,peerint=Te1/49;
enable;
traps;
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
masun@solir2 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1244 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1244;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1244;
route-distinguisher 49079:70134;
vrf-target target:49079:70134;
protocols {
vpls {
site-range 10;
mac-table-size {
1024;
}
mac-statistics;
no-tunnel-services;
site solis2-vpls70134 {
site-identifier 2;
interface xe-0/0/3.1244;
}
}
}
}
}
}
masun@solir2 show configuration interfaces xe-0/0/3 description
type=core,subtype=isc,peer=solis2,peerint=Te1/49;
enable;
traps;
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
The VPLS connection is up on each side:
masun@solir2 show vpls connections
...
Instance: vpls70134
Local site: solis2-vpls70134 (2)
connection-site Type St Time last up # Up
trans
1 rmt Up Mar 28 16:11:30 2013
1
Remote PE:
Re: [j-nsp] SRX240H vs SRX240H2
Worth noting also that the B2 will not do IPS etc, same as the B1, even though it has as much RAM as the H1. -Original Message- From: Skeeve Stevens Sent: 19/01/2013 2:55 PM To: Tim Eberhard Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX240H vs SRX240H2 SRX240B = 1Gb RAM - only 512mb RAM accessible, can be upgraded to 240H SRX240H = 1Gb RAM SRX240B2 = 2Gb RAM - only 1Gb RAM accessible, can be upgraded to 240H2 SRX240H2 = 2Gb RAM Processor and everything else is apparently the same. When distributors run out of Series 1, you wont be able to buy them... and since they are the same price, why would you want to? From what I understand, the reason for the upgrade is that the UTM was getting very memory intensive and needed the extra space to work properly. ...Skeeve * * *Skeeve Stevens, CEO - *eintellego Pty Ltd ske...@eintellego.net ; www.eintellego.net Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco – IBM - Brocade - Cloud - Check out our Juniper promotion website! eintellego.mx Free Apple products during this promotion!!! On Sat, Jan 19, 2013 at 2:40 PM, Tim Eberhard xmi...@gmail.com wrote: I always thought the SRX240H was the memory upgraded version to the 240B (aka base). The 240H2 I believed has the memory upgrade and a faster (possibly just overclocked?) processor. Perhaps I am incorrect though. The H2 line is pretty new and I haven't touched one yet to compare. On Fri, Jan 18, 2013 at 6:09 PM, David Kotlerewsky webnet...@gmail.com wrote: Same specs, just a memory upgrade. Sent from my iPhone On Jan 18, 2013, at 1:47 PM, Robert Hass robh...@gmail.com wrote: Hi What is difference between SRX240H and SRX240H2 except doubled memory/flash. I'm mostly interested are CPUs are same. Rob ___ 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 ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
Interesting to see that the PR is listed as resolved in 13.1R1. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Sebastian Wiesinger Sent: Thursday, 21 February 2013 8:32 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX80 BGP performance after reboot * Sebastian Wiesinger juniper-...@ml.karotte.org [2013-02-19 13:57]: Yes, I agree. But that's a design decision so ATAC is not interested. I'll try to get this to Juniper trough my SE but I don't know if that'll do any good. So Juniper is aware that this is a problem (at least for some people) and there are people working on it. It's not trivial so I don't expect any short-term solutions / improvement. There is also a NANOG discussion regarding this: http://mailman.nanog.org/pipermail/nanog/2013-January/054694.html The current PR seems to be PR836197 https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR836197 Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
Couldn't RPD just reduce the TCP window size for BGP sessions to reduce the rate at which it can receive routes from neighbouring routers? This would mean that your FIB would always be synched to your RIB and other routers would not blackhole by sending traffic to the router in question (who's FIB is lagging behind its RIB), no? -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, 12 February 2013 12:43 PM To: 'Juniper NSP' Subject: Re: [j-nsp] MX80 BGP performance after reboot I was there for that lightning talk (and very recently seen that feature actually happening) but what's getting described here by the OP doesn't seem to be the same maybe I'm misunderstanding. Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wheeler Sent: February-11-13 6:59 PM To: Juniper NSP Subject: Re: [j-nsp] MX80 BGP performance after reboot On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: I noticed that a MX80 takes quite a long time after reboot to put all routes into the KRT. Is that normal for that box? It takes around 10 minutes after BGP is established to get all the routes into the KRT Yes, the routes taking a long time to install is normal, unfortunately. I feel like it has got worse since 10.4 but that might be my imagination. I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was something like if you want your routers to install routes, call Juniper and reference PR#whatever because they do not want to fix this bug. I am hopeful that the move away from a single Junos release strategy to some segregation among different products will allow Juniper to be more flexible in how they allocate development resources to different platforms. If I had to guess, I'd say the ddos-related log messages you are reading are related to excessive need to generate ttl_exceeded packets because of routing loops while BGP is announcing to neighboring routers but the routes are not actually installed in the FIB yet. Even if I am wrong about the specifics here, I am certain it is only a symptom of the problem which is unrelated to the ddos-protection feature. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Is Juniper moving features to AFL on EX Series in 12.3?
Hi Skeeve, This has already been discussed in the Junos 12.3 Release Date thread and a Juniper employee has stated that this is a documentation error that will fixed. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Skeeve Stevens Sent: Friday, 8 February 2013 1:05 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Is Juniper moving features to AFL on EX Series in 12.3? All, Something has just been pointed out to me, and I'd like to get the communities take on it. It seems that Juniper has moved features to the Advanced Features License in 12.3. *This is the link for the EX License Overview on 12.2* http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/ex-series -software-licenses-overview.html#jd0e146 Features Requiring a License on EX3200, EX4200, EX4500, EX4550, EX6200, and EX8200 Switches To use the following features on Juniper Networks EX3200, EX4200, EX4500, EX4550, EX6200, and EX8200 Ethernet Switches, you must install an advanced feature license (AFL): - Border Gateway Protocol (BGP) and multiprotocol BGP (MBGP) - Intermediate System-to-Intermediate System (IS-IS) - IPv6 protocols: OSPFv3, RIPng, IS-IS for IPv6, IPv6 BGP - MPLS with RSVP-based label-switched paths (LSPs) and MPLS-based circuit cross-connects (CCCs) --- *This is the link for the EX License Overview on 12.3* http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/ex-series -software-licenses-overview.html#jd0e146 Features Requiring a License on EX3200, EX4200, EX4500, EX4550, EX6200, and EX8200 Switches To use the following features on Juniper Networks EX3200, EX4200, EX4500, EX4550, EX6200, and EX8200 Ethernet Switches, you must install an advanced feature license (AFL): - Border Gateway Protocol (BGP) and multiprotocol BGP (MBGP) - Generic Routing Encapsulation (GRE) - Intermediate System-to-Intermediate System (IS-IS) - Multicast Listener Discovery version 1 and 2 (MLDv1 and MLDv2) - MPLS with RSVP-based label-switched paths (LSPs) and MPLS-based circuit cross-connects (CCCs) - Multicast Source Discovery Protocol (MSDP) - RIPng (RIP next generation) - OSPFv1/v2 (with four active interfaces) - OSPFv3 - S-VLAN - Unicast reverse-path forwarding (RPF) - Virtual routing and forwarding (VRF) - Virtual Router Redundancy Protocol (VRRP) Doesn't this increase the cost of these switches by a ton of money if you want features you used to get for free? I would have thought that IPv6 would have been something that would have started to be in the base license since everyone is starting to need it as standard. This sounds a little opportunistic in my opinion. This looks like these layer 3 switches are becoming more and more like Layer 2 dumb switches the higher the Junos version goes. Maybe 13.x will have IPv4 in AFL? ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net We are the bridge between business and technology Juniper - Cisco - Cloud ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RR cluster
Are these dedicated RR's or are they combined RR/PE devices? -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks Sent: Wednesday, 6 February 2013 2:02 PM To: Ali Sumsam; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] RR cluster vanilla ibgp between the RRs would work On 2/5/13 6:36 PM, Ali Sumsam ali+juniper...@eintellego.net wrote: Hi All, I want to configure two RRs in my network. What should be the relation between two of them? I want them to send updates to each other and to the RR-Clients. Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco - Brocade - IBM ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
There are some per-logical-system processes but there are also some that are chassis wide. Logical systems also do not support some features, including I believe most MS-DPC functions, FA-LSPs (go figure) and some others. You will also always have a single cos and chassis process for all logical systems so no real help for a crash there. Also, maintenance/provisioning tools will almost never work properly with logical systems for some reason or another so I would recommend keeping logical systems limited to the lab for testing larger scenarios on less equipment.. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stephen Hon Sent: Friday, 25 January 2013 9:53 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Redundancy with MX Ouch... I picked a single MX480 chassis design over a dual MX80 because of the unavailability of the MS-DPC card in the MX80. We're very new to Juniper here with close to no practical experience. Nonetheless, we're migrating away from Brocade NetIron MLX to the MX and we figured that dual RE and SCB would helpful relative to ISSU and NSR but I guess the general consensus is that it's preferable to have separate routers over redundant RE's. I'm wondering though, would dividing some of the routing duties into logical systems help to protect from a massive system-wide problem? From what I understand the logical systems spin up their own set of processes and have their own configuration so it would seem that there could be some level of protection. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 12.3 Release Date
The X44-D10 release is Junos 12.2 for SRX/J Series platforms, eg flow-mode code. Flow mode is branching away from real Junos as 12.1X44-D10, D15, D20...etc until 13.2 or 13.3 when they will consolidate again so that development of flow-mode code can be sped up. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Andrei-Marius Radu Sent: Wednesday, 23 January 2013 4:08 AM To: Maarten van der Hoek; Tima Maryin; Saku Ytti; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Junos 12.3 Release Date Hello Maarten, From the name (X44-D10) that is a special release for a specific platform (could be QFX, PTX or something else). As far as I am aware 12.3 will be released at the beginning of 2013 and indeed it will be an EEOL release. Cheers, Andrei. On 22/01/2013, Maarten van der Hoek maar...@vanderhoek.nl wrote: Guys, The 12.1X44-D10 which was released last week is the EEOL release! (According to the release notes) I've the fealing 12.3 will therefor not be released! Brgds, Maarten -Oorspronkelijk bericht- Van: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] Namens Tima Maryin Verzonden: dinsdag 22 januari 2013 10:26 Aan: Saku Ytti CC: juniper-nsp@puck.nether.net Onderwerp: Re: [j-nsp] RE : Junos 12.3 Release Date Technically 12.3 belongs to 2012 and it's the last release of 2012 so it should be EEOL. On 22.01.2013 13:09, Saku Ytti wrote: http://www.juniper.net/support/eol/junos.html --- 1Extended End of Life (EEOL) Release: Beginning with Junos 8.1 Juniper offers an Extended End of Life (EEOL) Release. The last Junos Release to reach general availability in a particular calendar year is the EEOL Release. So is our 2012 EEOL 12.2 or 12.3? : ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junos 12.3 Release Date
Hi all, Does anyone have a release date for 12.3 (real 12.3, not SRX special X releases)? The last I heard from Juniper was before the end of 2012... Cheers, Caillin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LDP on ex4200/3200 series..and 1RU LSR?
No multicast today either... just a head ups :( L3VPNs also missing until the end of the month.. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ben Dale Sent: Thursday, 20 December 2012 11:25 PM To: juniper-nsp@puck.nether.net List Subject: Re: [j-nsp] LDP on ex4200/3200 seriesand 1RU LSR? On 20/12/2012, at 4:58 PM, Michel de Nostredame d.nos...@gmail.com wrote: Possibly Juniper is positioning ACX for that? But ACX has far lower port density and those 1U ACX has only DC power-supplier. This was my feeling too, but there is *currently* no VPLS support on ACX. I'm hoping that will change in the future. The passive cooling is a big win and although the data sheet doesn't mention it, there is an AC version of the ACX 1100 on the pricelist: ACX1100 Universal Access Router, AC Version, Dual power supply, 1RU, ETSI 300, SyncE/1588v2, Temperature hardened, Passively cooled,8xGE RJ45, 4xGE RJ45/SFP Combo (Optics Sold Separately) I've got a pair of these coming into the lab in the new year (lead times are currently measured in *months*) and will be interested to see what the limitations are. They're priced right in the middle of the J4350 and J6350 too which is also interesting. On Wed, Dec 19, 2012 at 10:32 PM, Mark Tees markt...@gmail.com wrote: Can't help but wonder what they were thinking with that design. How many people out there want this functionality in a 1RU box? On 20/12/2012, at 1:00 PM, Tim Jackson wrote: It can't even pass packets with 1 label. -- Tim On Wed, Dec 19, 2012 at 7:44 PM, Mark Tees markt...@gmail.com wrote: Would it be feasible still for only outer label operations? To use as P router would you only ever need to work with outer label? Sent from some sort of iDevice. On 20/12/2012, at 9:52 AM, Craig Askings caski...@ionetworks.com.au wrote: On 19 December 2012 20:18, Mark Tees markt...@gmail.com wrote: Hi list. Has anyone heard about if there is ever going to be support for LDP on the ex4200/3200 series? From what I understand the chipset on ex4200/3200 does not support more than one mpls label, so LDP etc is not possible on that hardware. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LDP on ex4200/3200 series..and 1RU LSR?
Mmmm an ME3600/ME3800 equivalent would be nice.. with VPLS and the slightly higher operating temperatures too.. please santa :) -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tees Sent: Wednesday, 19 December 2012 9:19 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] LDP on ex4200/3200 seriesand 1RU LSR? Hi list. Has anyone heard about if there is ever going to be support for LDP on the ex4200/3200 series? Also, has anyone heard if Juniper is planning a 1RU switch (24-48 GigE + a few 10GBE ports) that has full MPLS support? I noticed that the ex4500/4550 has full MPLS capability according to https://www.juniper.net/techpubs/en_US/release-independent/junos/topics/ concept/ex-series-software-features-overview.html Would be nice if eventually there would be an ex4200 equivalent with the same sort of functionality. *enter wish list here* Cheers! Mark ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
Sigh.. If only there was selective flow mode on the SRX/J... -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Per Westerlund Sent: Friday, 7 December 2012 4:24 AM To: Phil Mayers; Dale Shaw Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry This is a flow mode configuration (Juniper calls it router mode, not packet mode), that emulates pure packet mode by allowing all packets to start a flow, and having a default permit-all for all flows. The sole reason for having this is to enable flow-mode things like IPsec and NAT at the same time as having almost the same behavior as pure packet mode. I am working on another mail or two with examples of selective packet mode that I believe might solve Dale's original problem (and perhaps his quest for pure routing with IPsec). /Per 6 dec 2012 kl. 14:15 skrev Phil Mayers: On 06/12/12 10:58, Per Westerlund wrote: To follow up my own post (even more to follow), here is the config you use on a J-series router to put it in router-mode. Nothing magic, just some configuration. This will work with SRX as well, there is nothing J-series specific in here. This config is found in /etc/config/jsr-series-routermode-factory.conf, and the box I picked it from was running Junos 10.2R4.8 Is this *actually* in router mode, or is it just in a permit-all flow mode? In particularly, you seem to be missing a packet-mode statement for IPv4 or MPLS (which also disables flow mode for IPv4) What does show security flow status say? ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
This just becomes long and painful when you want to run the box as an MPLS device primarily and as an IPSec/Crypto box for some traffic.. -Original Message- From: 叶雨飞 [mailto:sunyuc...@gmail.com] Sent: Friday, 7 December 2012 12:21 PM To: Caillin Bathern Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry you can run your main routing instance in flow mode , and apply filters to send those into other VRs (flow or not) for further processing. On Thu, Dec 6, 2012 at 4:45 PM, Caillin Bathern caill...@commtelns.com wrote: Sigh.. If only there was selective flow mode on the SRX/J... -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Per Westerlund Sent: Friday, 7 December 2012 4:24 AM To: Phil Mayers; Dale Shaw Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX, UDP traffic, routing asymmetry This is a flow mode configuration (Juniper calls it router mode, not packet mode), that emulates pure packet mode by allowing all packets to start a flow, and having a default permit-all for all flows. The sole reason for having this is to enable flow-mode things like IPsec and NAT at the same time as having almost the same behavior as pure packet mode. I am working on another mail or two with examples of selective packet mode that I believe might solve Dale's original problem (and perhaps his quest for pure routing with IPsec). /Per 6 dec 2012 kl. 14:15 skrev Phil Mayers: On 06/12/12 10:58, Per Westerlund wrote: To follow up my own post (even more to follow), here is the config you use on a J-series router to put it in router-mode. Nothing magic, just some configuration. This will work with SRX as well, there is nothing J-series specific in here. This config is found in /etc/config/jsr-series-routermode-factory.conf, and the box I picked it from was running Junos 10.2R4.8 Is this *actually* in router mode, or is it just in a permit-all flow mode? In particularly, you seem to be missing a packet-mode statement for IPv4 or MPLS (which also disables flow mode for IPv4) What does show security flow status say? ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ 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] SRX100 for dual 100M uplink routing network in packetmode.
Hi Mike, I must disagree here, although I never verified it myself a Juniper Engineer I know did show me some in production configurations showing MPLS over GRE over IPSec on a single branch router (I think J not SRX) so it is possible. This was on 10.3R1.9. You must use the lt-0/0/0 interface to send the GRE packets into a separate virtual router for encryption/transport over IPSec as this clears the packet-mode flag. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mike Williams Sent: Wednesday, 28 November 2012 10:25 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX100 for dual 100M uplink routing network in packetmode. On Tuesday 27 November 2012 23:08:04 Michel de Nostredame wrote: PS: I just got a SRX100 and am going to do some POC with selective-packet-mode. Basically I want to route my traffic into GRE tunnel in packet-mode and route GRE packet over IPsec to remote SSG site in flow-mode because IPsec needs flow module. Hopefully this can suppress my session-table usage to only one for two records. I hate flow-mode JUNOS for a long long long time since J-series, but the SRX prices are simply irresistible. Michel, We wanted to do that with some SRX650s. Doesn't work. Sorry. Seems like some flag is on the packet saying it's packet-mode, which isn't removed/reset when it's wrapped in a GRE header, so IPSec sees a packet-mode packet and drops it. This was with 10.4R6.5, we didn't get the chance to try anything newer. -- Mike Williams ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Limitation of Reduced scale L3 features
Hi Robert, As I understand you do not get VRFs/L3VPNs when you have the reduced scale line cards. Should be 1 million routes for the full scale too I think but someone else might want to confirm that for the Trio. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Robert Kern Sent: Sunday, 28 October 2012 7:49 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Limitation of Reduced scale L3 features Hi all, I have some questions regarding Reduced scale L3 features for MPC-3D-16XGE-SFPP line card. All info I could get on Juniper site is that difference is just the number of routes in routing(forwarding) table - 32k. Is this really the only difference or there are some other limitations? What is the size of routing (forwarding) table for Full scale L3 feature license? Thanks very much, Robert ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] WAN input prioritization on MX
More to the point I believe the original commenter was talking about packet marking, not queuing or classification :) And here I believe that junos doesn't work well... If you have a link that carries both transit and newly injected traffic you are stuffed when you try to perform a rewrite to correctly mark ingress node traffic but also try to transparently pass through traffic from a trusted source using the same FC. Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks Sent: Monday, 15 October 2012 2:35 PM To: Serge Vautour; Chris Evans; Gustavo Santos Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] WAN input prioritization on MX Yes, that's just what I said in so few words :-) Classification = ingress Queuing = egress From: Serge Vautour sergevaut...@yahoo.camailto:sergevaut...@yahoo.ca Reply-To: Serge Vautour se...@nbnet.nb.camailto:se...@nbnet.nb.ca Date: Sun, 14 Oct 2012 10:06:37 -0700 To: dhanks dha...@juniper.netmailto:dha...@juniper.net, Chris Evans chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com, Gustavo Santos gustkil...@gmail.commailto:gustkil...@gmail.com Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] WAN input prioritization on MX Humm. My understand, at least with the command sets I'm use to using, is that you do classification on ingress and then queuing and marking on egress. When you do classification, the packets are assigned to a Forwarding Class (FC) inside the box. This makes sure the box gives those packets proper treatment inside the box and that the packets get assigned to the proper egress interface queue. While the packets exit the queue (based on egress schedulers), the packet QoS headers are remarked. Basically, this diagram: http://www.juniper.net/techpubs/images/g017213.gif Packets travel through the box based on the outer boxes following the solid lines. The dotted lines all point to or from the FC to identify how the decision is made. Serge From: Doug Hanks dha...@juniper.netmailto:dha...@juniper.net To: Chris Evans chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com; Gustavo Santos gustkil...@gmail.commailto:gustkil...@gmail.com Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Sent: Sunday, October 14, 2012 12:09:53 AM Subject: Re: [j-nsp] WAN input prioritization on MX How is this weird? You can mark on ingress, but the queuing happens on the egress interface when it's to be transmitted. On 10/13/12 6:07 AM, Chris Evans chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com wrote: JUNOS does a weird way of marking packets.. It is done on the egress of the box, not on ingress (there is an exception in a few newer modules that can do this). So it is probably working as the other poster mentioned. Make sure you take this methodology into consideration as it can hinder your granularity of CoS with marking vs passing through and you inadvertently remark traffic you didn't mean to. On Sat, Oct 13, 2012 at 8:21 AM, Gustavo Santos gustkil...@gmail.commailto:gustkil...@gmail.comwrote: Doug and Hanks @juniper. I had to left the office and leave configuration as is. On monday I will update you after verify what you have pointed, What I can tell is that I didn't have made any modification on the systems default class of service / mapping configuration. Thank you! Gustavo Santos Analista de Redes CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER 2012/10/13 Harry Reynolds ha...@juniper.netmailto:ha...@juniper.net Doug raises some good points. Also, for testing, perhaps add some counters to the terms to aid in confirming matches. You may also want to show config | display detail/inheritance to see if the prefix list is expanding as you expect. Regards -Original Message- From: juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.neth er.net [mailto: juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-bounces@puck .nether.net] On Behalf Of Doug Hanks Sent: Friday, October 12, 2012 9:36 PM To: Gustavo Santos; juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] WAN input prioritization on MX I'm sure it's working just fine. Are you checking the egress interface to see if the traffic is being marked and queued properly? A common mistake is to check the ingress interface queues. If this doesn't work, we would need to see your entire class-of-service configuration. On 10/12/12 6:04 PM, Gustavo Santos gustkil...@gmail.commailto:gustkil...@gmail.com wrote: Hi, I'm new on Juniper class of service / shaping. I'm reading some tech docs from Juniper and a Juniper's MX book, but it's kind tricky. Today I get asked to
Re: [j-nsp] pic has no CoS queuing
Hi Lukasz, It looks like you only have a port queuing DPC (-R) not a H-QoS DPC (-R-Q or -R-EQ). Without the -Q/-EQ DPCs I do not believe you can configure the per-unit COS functions. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Lukasz Trabinski Sent: Tuesday, 9 October 2012 9:44 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] pic has no CoS queuing Hi I trying to configure shaping-rate on logical 10Gbit/s interface: xxx@xxx# show class-of-service interfaces xe-3/0/0 unit 591 shaping-rate 1k; xxx@xxx# show interfaces xe-3/0/0 per-unit-scheduler per-unit-scheduler; What I'm doing wrong? xxx@xxx# commit check [edit class-of-service interfaces xe-3/0/0 unit 591] 'shaping-rate' cannot configure bandwidth (pic has no CoS queuing) error: configuration check-out failed Hardware is: FPC 3REV 17 750-021566 YP4998DPCE 4x 10GE R CPUREV 04 710-022351 YN3030DPC PMB PIC 0 BUILTIN BUILTIN 1x 10GE(LAN/WAN) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Dynamic Profiles Question
Hi Everyone, I am playing around with subscriber management on 12.2R1.3 MX series in the lab at the moment and I have a question about the RI variable. https://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/config uration-statement/routing-instances-edit-dynamic-profiles.html This link says that I can configure a static routing instance name rather than using the $junos-routing-instance variable yet I am finding I cannot configure this. Does anyone know how this can be done? I also cannot find a way to set a default for the junos-routing-instance variable which would be an alternative. Does anyone know how this can be done? [edit] admin@MX5T# set dynamic-profiles test routing-instances ? Possible completions: $junos-routing-instance Dynamic profile routing instance name + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups [edit] admin@MX5T# set dynamic-profiles test routing-instances internet ^ syntax error. admin@MX5T# set dynamic-profiles test routing-instances internet I am also seeing some odd behaviour with vlan rewrite/push/pop/bridging when using dynamic profiles and vlan auto-configuration. Has anyone else had issues here or have any recommendations? Regards, Caillin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best-site VPLS convergence feature in Junos 12.2?
I notice it is using a new field in the update and that it is tied to the label block of the PE so it might be that a single update can now wipe all MAC address routes for a PE rather than having to send a route withdrawal for every MAC address which could take some time? Regards, Caillin Sent from my Windows Phone -Original Message- From: Per Granath Sent: 28/09/2012 7:02 PM To: Clarke Morledge; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Best-site VPLS convergence feature in Junos 12.2? It seems also mac-flush is now available with BGP based VPLS - before that was only supposed to work with LDP based. Possibly that is a more important improvement. I see that there is a new best-site feature in Junos 12.2 for improving the convergence time in VPLS multi-homed environments: http://www.juniper.net/techpubs/en_US/junos12.2/topics/example/vpls- multihoming-convergence-example.html The site-preference election method for determining the primary vs. backup site uses BGP signalling so that the PEs can select the highest value to indicate which site will actively handle traffic in order to prevent loops, thus making the non-primary site passive. In our experience, if you commit a PE configuration with a higher site value, VPLS converges quicker than when you commit a PE configuration with a lower site value. So perhaps the new best-site feature might help. But operationally, it looks like the old site-preference and best-site methods for determining the primary are pretty much the same. Am I missing something? Does the best-site method really improve convergence, and if so, how so? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config help for basic MPLS setup
On point 2 there, the ex can only process one label at a time but there could be a larger label stack than that so it can be a P router. -Original Message- From: sth...@nethelp.no Sent: 25/09/2012 8:25 AM To: matt...@corp.crocker.com Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Config help for basic MPLS setup I have an MX80 and 3 EX4200s connected via 10GigE running MPLS, OSPF, etc. I have some ethernet-ccc links working between the gear. I'm trying to setup my first MPLS based routing VRF (L3VPN ???) between a new SRX210 and the MX80 (going through the EX4200s). Eventually the configuration will look like this Internal LAN - SRX210 --[MPLS]-- EX4200 --[MPLS]-- EX4200 -- [MPLS] -- MX80 --[Internal LAN] -- Firewall The SRX210 is a PE router owned and controlled by me. I have a couple other basic IP routes on it for other customers. The idea here is that all traffic on ge-0/0/0.0 gets routed to the MX80 through an LSP in the routing-instance corp.crocker.com For testing the SRX is connected directly to the MX80 bypassing the EX4200s SRX has OSPF going with MX80 but does not have BGP configured. MX80 has BGP with my upstreams and other border routers I'm sure I'm missing some MPLS filters or something but I'm not sure what. I see a couple of problems here: 1. MPLS L3VPNs use BGP to distribute the VPN label. Thus you *must* have a full BGP mesh between your PEs (or you can of course use route reflectors/confederations). 2. As far as I know the EX switches can only handle *one* MPLS label. You need at least two labels for MPLS L3VPNs. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config help for basic MPLS setup
Hi Matt, You should only need iBGP between the PE routers, eg the SRX and the MX. Just configure family inet-vpn unicast to pass the VRF/VPN routes. Cheers, Caillin From: Matthew Crocker [mailto:matt...@corp.crocker.com] Sent: Tuesday, 25 September 2012 9:16 AM To: Caillin Bathern Cc: sth...@nethelp.no; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Config help for basic MPLS setup The EX4200s will be P routes so I should be ok. I'll get BGP running on the SRX EXs tomorrow. The SRX MX80 will be PE. I'll update tomorrow if I can't get it working. Thanks. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Sep 24, 2012, at 6:55 PM, Caillin Bathern caill...@commtelns.com wrote: On point 2 there, the ex can only process one label at a time but there could be a larger label stack than that so it can be a P router. From: sth...@nethelp.no Sent: 25/09/2012 8:25 AM To: matt...@corp.crocker.com Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Config help for basic MPLS setup I have an MX80 and 3 EX4200s connected via 10GigE running MPLS, OSPF, etc. I have some ethernet-ccc links working between the gear. I'm trying to setup my first MPLS based routing VRF (L3VPN ???) between a new SRX210 and the MX80 (going through the EX4200s). Eventually the configuration will look like this Internal LAN - SRX210 --[MPLS]-- EX4200 --[MPLS]-- EX4200 -- [MPLS] -- MX80 --[Internal LAN] -- Firewall The SRX210 is a PE router owned and controlled by me. I have a couple other basic IP routes on it for other customers. The idea here is that all traffic on ge-0/0/0.0 gets routed to the MX80 through an LSP in the routing-instance corp.crocker.com For testing the SRX is connected directly to the MX80 bypassing the EX4200s SRX has OSPF going with MX80 but does not have BGP configured. MX80 has BGP with my upstreams and other border routers I'm sure I'm missing some MPLS filters or something but I'm not sure what. I see a couple of problems here: 1. MPLS L3VPNs use BGP to distribute the VPN label. Thus you *must* have a full BGP mesh between your PEs (or you can of course use route reflectors/confederations). 2. As far as I know the EX switches can only handle *one* MPLS label. You need at least two labels for MPLS L3VPNs. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Logical Systems Interconnection by Physical Interface
You are probably trying to ping from the base router not from the
logical system.
Try ping 10.0.5.254 logical-system R1 rapid
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Juniper
Maillist
Sent: Friday, 27 July 2012 10:55 PM
To: Jayaraj Shantharam
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Logical Systems Interconnection by Physical
Interface
Hi Jay,
I think the address is correct and taken from JNCIE stuy guide.
Regards,
Abdullah
On Jul 27, 2012, at 3:28 PM, Jayaraj Shantharam
jay_shantha...@rediffmail.com wrote:
Hi Abdul,
I think the obvious problem is address 10.0.5.254/24
Regards
Jay
On Fri, 27 Jul 2012 17:49:13 +0530 wrote
Hello,
I have two logical systems configured on m7i router, I want to connect
both LSs through two physical interfaces on the same router (fe-0/0/0
and fe0/1/0): My configs on both interfaces like:
R1)
root@JNCIE-SP# run show configuration logical-systems R1
interfaces {
fe-0/0/0 {
unit 1 {
vlan-id 111;
family inet {
address 10.0.5.1/24;
}
}
}
}
P1)
root@JNCIE-SP# run show configuration logical-systems P1
interfaces {
fe-0/1/0 {
unit 1 {
vlan-id 111;
family inet {
address 10.0.5.254/24;
}
}
}
}
However, when I ping from R1 to P1 I got the following message ping:
sendto: Can't assign requested address
What's the reason for that?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Follow Rediff Deal ho jaye! to get exciting offers in your city
everyday.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and
content filtering.http://www.mailguard.com.au/mg
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX/MX G.8032 with OAM CCM's
Hi Ben,
My experience with MX (and other vendors) ERPS is that you will get very
good convergence times without enabling OAM at all. Unless you have
intermediate non-ERPS capable switches that require the OAM or
intermediate xWDM transponders without fault reflection etc then I would
recommend testing it without OAM configured and see what your results
are.
Cheers,
Caillin
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ben Boyd
Sent: Tuesday, 5 June 2012 5:03 AM
To: Ben Dale
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX/MX G.8032 with OAM CCM's
Here is config from one of the MX nodes:
oam {
ethernet {
connectivity-fault-management {
action-profile rmep-defaults {
default-actions {
interface-down;
}
}
maintenance-domain d1 {
level 0;
maintenance-association control {
inactive: continuity-check {
interval 10ms;
loss-threshold 5;
hold-interval 1;
}
mep 2 {
interface xe-2/0/0;
remote-mep 1 {
action-profile rmep-defaults;
}
}
}
}
maintenance-domain d8 {
level 0;
maintenance-association control {
inactive: continuity-check {
interval 10ms;
loss-threshold 5;
hold-interval 1;
}
mep 1 {
interface xe-1/3/0.16;
remote-mep 2 {
action-profile rmep-defaults;
}
}
}
}
}
}
}
protection-group {
ethernet-ring sidera-ring-1 {
east-interface {
control-channel {
xe-1/3/0.10;
}
}
west-interface {
control-channel {
xe-2/0/0.10;
}
}
data-channel {
vlan 1-4094;
}
}
}
Here is one of the configs from the EX nodes:
protection-group {
ethernet-ring sidera-ring-1 {
east-interface {
control-channel {
xe-0/1/0.0;
}
}
west-interface {
control-channel {
xe-0/1/2.0;
}
}
control-vlan MANAGEMENT;
data-channel {
vlan [ MANAGEMENT CUSTOMER_A CUSTOMER_B CUSTOMER_C
CUSTOMER_D_TRUNK L2TUNNEL ];
}
}
}
oam {
ethernet {
connectivity-fault-management {
action-profile rmep-defaults {
default-actions {
interface-down;
}
}
maintenance-domain d5 {
level 0;
maintenance-association control {
inactive: continuity-check {
interval 10ms;
loss-threshold 5;
hold-interval 1;
}
mep 2 {
interface xe-0/1/0.0 vlan-id 13;
remote-mep 1 {
action-profile rmep-defaults;
}
}
}
}
maintenance-domain d6 {
level 0;
maintenance-association control {
inactive: continuity-check {
interval 10ms;
loss-threshold 5;
hold-interval 1;
}
mep 1 {
interface xe-0/1/2.0 vlan-id 14;
remote-mep 2 {
action-profile rmep-defaults;
}
}
}
}
}
}
}
When OAM is activated, several of my interfaces in the ring start
bouncing..
I'm wondering if the EX's just can't handle the 10ms interval.
Customer is looking for sub 50ms convergence times (competing with REP
on Ciscos).
We skipped configuring it, but if we make it back, I'll set it up to
400ms x 3 and see if that
Re: [j-nsp] R: MX5-T logical-routers question
I would caution against using logical tunnel interfaces between
different logical systems.
Get two SFPs and a short piece of fibre and use a physical loopback. We
have experienced issues with lt interfaces between LRs when using MPLS
and JTAC have told us not to do it as well.
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Palmentieri,
Nunzia (NSN - IT/Rome)
Sent: Tuesday, 22 May 2012 10:42 PM
To: ext Mihai Gabriel; juniper-nsp@puck.nether.net
Subject: [j-nsp] R: MX5-T logical-routers question
shold be
php.
Da: juniper-nsp-boun...@puck.nether.net per conto di ext Mihai Gabriel
Inviato: mar 22/05/2012 14.32
A: juniper-nsp@puck.nether.net
Oggetto: [j-nsp] MX5-T logical-routers question
Hello,
I am trying to test some features with an MX5-T router with
logical-systems but my results are below expectations and I don't
understand what's wrong.
The topology and the config are very simple: R1 --- R2 ---R3 :
mx5t# run show version
Hostname: mx5t
Model: mx5-t
JUNOS Base OS boot [11.4R2.14]
JUNOS Base OS Software Suite [11.4R2.14] JUNOS Kernel Software Suite
[11.4R2.14] JUNOS Packet Forwarding Engine Support (MX80) [11.4R2.14]
JUNOS Online Documentation [11.4R2.14] JUNOS Routing Software Suite
[11.4R2.14]
mx5t# show chassis
fpc 1 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
inactive: adaptive-services {
service-package layer-2;
}
}
pic 1 {
tunnel-services {
bandwidth 1g;
}
}
}
network-services ip;
mx5t# show R1
interfaces {
lt-1/1/10 {
unit 12 {
encapsulation ethernet;
peer-unit 21;
family inet {
address 10.10.10.1/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 1000 {
family inet {
address 1.1.1.1/32;
}
family iso {
address 49.0001...00;
}
}
}
}
protocols {
rsvp {
interface all;
}
mpls {
label-switched-path mihai {
to 3.3.3.3;
no-cspf;
}
interface all;
}
isis {
interface all;
}
}
mx5t# show R2
interfaces {
lt-1/1/10 {
unit 21 {
encapsulation ethernet;
peer-unit 12;
family inet {
address 10.10.10.2/24;
}
family iso;
family mpls;
}
unit 23 {
encapsulation ethernet;
peer-unit 32;
family inet {
address 10.10.20.2/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 1001 {
family inet {
address 2.2.2.2/32;
}
family iso {
address 49.0001...00;
}
}
}
}
protocols {
rsvp {
interface all;
}
mpls {
interface all;
}
isis {
interface all;
}
}
mx5t# show R3
interfaces {
lt-1/1/10 {
unit 32 {
encapsulation ethernet;
peer-unit 23;
family inet {
address 10.10.20.3/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 1003 {
family inet {
address 3.3.3.3/24;
}
family iso {
address 49.0001...00;
}
}
}
}
protocols {
rsvp {
interface all;
}
mpls {
interface all;
}
isis {
interface all;
}
}
While a ping from R1 loopback to R3 loopback is successful , a
traceroute from R1 to R3 doesn't show the transit router R2 (I tried
with and without mpls), and a lsp from R1 to R3 is failing to come up.
x5t# run show route logical-system R1
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[Direct/0] 01:07:53
via lo0.1000
2.2.2.2/32 *[IS-IS/15] 01:02:44, metric 10
to 10.10.10.2 via lt-1/1/10.12
3.3.3.0/24 *[IS-IS/15] 01:02:20, metric 20
to 10.10.10.2 via lt-1/1/10.12
3.3.3.3/32 *[IS-IS/15] 01:02:20, metric 20
to 10.10.10.2 via lt-1/1/10.12
10.10.10.0/24 *[Direct/0] 01:07:53
via lt-1/1/10.12
10.10.10.1/32 *[Local/0] 01:07:53
Local via lt-1/1/10.12
10.10.20.0/24 *[IS-IS/15] 01:02:44, metric 20
to 10.10.10.2 via lt-1/1/10.12
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
49.0001../56
*[Direct/0] 01:02:59
via lo0.1000
Re: [j-nsp] SRLGs in Inter-Area LSPs
Hi Lukasz, Thanks for your response. I agree that the TED is restricted to an ospf area for CSPF calculation however using the expand-loose-hop option on the ABRs should enable a cspf LSP to be set up to the remote area assuming that the ABRs are loose hops. The problem I am having is I am not yet sure if the CSPF conditions (admin groups, SRLGs, etc) will be applied when that loose-hop expansion (cspf calculation by the ABR to reach the next ABR) is made by the ABR. BGP-LU and the use of NHS attribute for scaling beyond a single area are definitely in play for multi-point VPNs however for any point-to-point L2VPNs we feel it would be much easier to generate an end-to-end dynamic LSP instead. I am hoping to try this in the lab soon but I was hoping for any insight list members might have for this. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Lukasz Dudzinski Sent: Sunday, 20 May 2012 7:22 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRLGs in Inter-Area LSPs Hi, I do not have an experience in multi-area MPLS techniques, so I'm not able to help you too much in that matter. But I'm sure that typically MPLS Traffic Engineering is restricted to single area of IGP protocol. If I understood your mail correctly you try to create a CSPF-based RSVP LSP between different IGP areas, which is not possible just like that. That is because MPLS TE relies on IGP TE database, which (like the link state database) is restricted to single IGP area. TE-DB is an extension of link state DB. Such information like Admin Groups, SRLG membership or BW reservation are stored in TE database. If size of your network force you to use IGP hierarchy I suggest you to take a look on such things like LDP-over-RSVP, Seamless MPLS or BGP Labelled Unicast. Lukasz On 2012-05-18 09:17, Caillin Bathern wrote: Hi All, I posted this to the J-Net forums but no luck. Just wondering if SRLGs are carried through between IGP areas, both for OSPF and for IS-IS? The scenario for this would be passing a cspf routed RSVP LSP from PE1 in Area 1 through to PE2 in Area 2. We would maintain a secondary standby LSP path for this traffic with exclude-srlg enabled. Assuming that the primary path takes the IGP routed path PE1 - ABR1 - ABR3 - PE2 then the secondary path will take the path PE1 - ABR2 - where? If SRLGs are carried through by the IGP then then the path should go PE1 - ABR2 - ABR4 - PE2, however if the SRLGs are not carried through then the IGP could in make the secondary path PE1 - ABR2 - ABR3 - PE2 which obviously is not a great standby secondary path... /--- ABR1 ---| |--- ABR3 ---\ PE1 (Area1) | Area 0 | (Area2) PE2 \--- ABR2 ---| |--- ABR4 ---/ If anybody knows this scenario and can shed some insight it would be greatly appreciated. Cheers, Caillin ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRLGs in Inter-Area LSPs
Hi All, I posted this to the J-Net forums but no luck. Just wondering if SRLGs are carried through between IGP areas, both for OSPF and for IS-IS? The scenario for this would be passing a cspf routed RSVP LSP from PE1 in Area 1 through to PE2 in Area 2. We would maintain a secondary standby LSP path for this traffic with exclude-srlg enabled. Assuming that the primary path takes the IGP routed path PE1 - ABR1 - ABR3 - PE2 then the secondary path will take the path PE1 - ABR2 - where? If SRLGs are carried through by the IGP then then the path should go PE1 - ABR2 - ABR4 - PE2, however if the SRLGs are not carried through then the IGP could in make the secondary path PE1 - ABR2 - ABR3 - PE2 which obviously is not a great standby secondary path... /--- ABR1 ---| |--- ABR3 ---\ PE1 (Area1) | Area 0 | (Area2) PE2 \--- ABR2 ---| |--- ABR4 ---/ If anybody knows this scenario and can shed some insight it would be greatly appreciated. Cheers, Caillin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Interface to be used for Trunking MPLS
Try using encapsulation flexible-ethernet-services on the CE facing
interface.
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Saba Sumsam
Sent: Friday, 18 May 2012 9:29 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Interface to be used for Trunking MPLS
Hi,
I have an MX-80 acting as a PE router, where ge-1/1/1 is the CE-facing
interface which is connected to the trunk port of a switch. The
configuration looks like this:
[edit interfaces ge-1/1/1]
flexible-vlan-tagging;
encapsulation vlan-ccc;
unit 0 {
encapsulation vlan-ccc;
vlan-id-range 700-800;
family ccc;
}
[edit protocols]
connections remote-interface-switch VLAN700-800 interface ge-1/1/1.0
connections remote-interface-switch VLAN700-800 transmit-lsp LSP_MX
connections remote-interface-switch VLAN700-800 receive-lsp LSP_EX
VLAN range 700-800 is being transported across MPLS to the remote PE
device. The same interface, ge-1/1/1 is also receiving VLAN400 (through
the
trunk) but should not be sent via MPLS but to another switch connected
to the MX-80. I tried the following configuration on the same interface:
[edit interfaces ge-1/1/1]
unit 400 {
family bridge {
interface-mode trunk;
vlan-id-list 400;
'unit 400'
Link encapsulation type is not valid for device type
error: configuration check-out failed
Any suggestions how to make this work? The same physical interface
should be able to send specific VLANs out over MPLS and others out any
other interfaces.
Regards.
*Saba Sumsam*
*Network Engineer - Level 2*
eintellego Pty Ltd
s...@eintellego.net a...@eintellego.net ; www.eintellego.net
Phone: 1300 753 383 ; Fax: (+612) 8572 9954
Cell +61 (0)424753773
facebook.com/eintellego
PO Box 7726, Baulkham Hills, NSW 1755 Australia
The Experts Who The Experts Call
Juniper - Cisco - Brocade - IBM
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Message protected by MailGuard: e-mail anti-virus, anti-spam and
content filtering.http://www.mailguard.com.au/mg
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
