Re: [j-nsp] MX80 Q-in-Q
Does MX ambiguous vlan?
Please rephrase the question.
If you're asking whether the MX80 supports dual tagged Ethernet
traffic, the answer is yes. E.g.
ge-1/0/0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 11 {
vlan-tags outer 1063 inner 900;
family inet {
address 10.9.130.1/30;
}
}
}
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IP monitoring on SRX 240 Cluster
Dear all,
I have configured srx 240 cluster. Ip monitoring for cluster failover is
not working. What are the suitable values for the ip monitoring. My
configurations are as below. I am using JUNOS 11.2 . Is there any
modifications required ?
redundancy-group 1 {
node 0 priority 130;
node 1 priority 129;
preempt;
interface-monitor {
ge-0/0/4 weight 255;
ge-5/0/4 weight 255;
ge-0/0/5 weight 255;
ge-5/0/5 weight 255;
ge-0/0/7 weight 255;
ge-5/0/7 weight 255;
ge-0/0/8 weight 255;
ge-5/0/8 weight 255;
ge-0/0/9 weight 255;
ge-5/0/9 weight 255;
ge-0/0/10 weight 255;
ge-5/0/10 weight 255;
ge-0/0/11 weight 255;
ge-5/0/11 weight 255;
ge-0/0/6 weight 255;
ge-5/0/6 weight 255;
ge-0/0/3 weight 255;
ge-5/0/3 weight 255;
}
ip-monitoring {
global-weight 255;
global-threshold 155;
retry-interval 3;
retry-count 10;
family {
inet {
192.168.X.1 {
weight 155;
interface reth9.0 secondary-ip-address 192.168.x.2;
}
}
}
}
}
Regards,
Bikash Bhattarai | Dristi Tech (P.) Ltd | +977 9851039710 |
www.dristi.com.np
Lazimpat, Kathmandu |Tel 977 1 4427949 | Fax 977 1 4410385*
*
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos labeled-unicast announces unusable routes, certainly this is a bug
Probably not what you want to hear at the moment but it is working as designed. There is nothing in BGP RFCs which mandate that BGP-LU _must_ consult LDP/RSVP/LFIB etc before announcing routes. To force BGP-LU to consult LDP/RSVP and automatically advertise/withdraw routes matching LSP endpoints, use combination of: 1/ mpls traffic-engineering bgp-igp-both-ribs (installs LDP/RSVP routes in inet.0 and in inet.3) 2/ BGP-LU export policy which exports LDP/RSVP routes as well as own loopback (all of them are in inet.0 as a result of [1] above) 3/ resolve-vpn under BGP LU family which causes received BGP-LU routes to install in both inet.0 and inet.3, for inet-vpn NH resolution HTH Thanks Alex - Original Message - From: Jeff Wheeler j...@inconcepts.biz To: juniper-nsp juniper-nsp@puck.nether.net Sent: Monday, January 21, 2013 12:25 AM Subject: [j-nsp] Junos labeled-unicast announces unusable routes,certainly this is a bug Dear List, The process of raising a PR with JTAC generally makes me want to scream, so I thought I would post first, and perhaps some kind Juniper person can input a PR# without me having to reproduce the problem again and jump through twenty hoops to later be told working as designed. When configuring BGP labeled-unicast on Junos, you might think (like I hoped) that you could use LDP to create FECs and allocate labels, and then use those labels in your MP-BGP session. Unfortunately this does not work, and the basic reason is Junos BGP wants to allocate its own labels, and won't consult the LDP FEC table to see if any already exist for a given protocol next-hop which is being announced to the neighbor. Fine, so it wants to allocate its own labels. However, trying to avoid this behavior, I found it's pretty easy to get Junos to announce broken labeled-unicast routes that can never work, even though the receiving BGP speaker has no idea they are invalid. The receiver will just install the routes, forward traffic, and the traffic will get blackholed. This happens because Junos is trying to announce NLRI with no allocated labels (because layer-3 next-hop is not self) and it can't announce them when labeled-unicast is configured, because the documentation is wrong, and you canNOT actually configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the same BGP session. It simply does not work, and the Juniper documentation on this subject is incorrect. So what happens is, the announcing router knows it wants to announce a prefix, but it has no label stack for it, won't allocate one, and instead it just puts in label 1048575, or 2^20-1. This label is not in the LFIB, so when that router receives packets with that label, it doesn't pop the label and do a layer-3 look-up. Instead, it just discards the packets. Worse than that, the announcing router's `show route advertising-protocol bgp neighbor` output is incorrect. It shows no label, even though it really is sending a label stack with 2^20-1. You have to go over to the receiving router to find this out. So this combination of documentation bugs and ridiculous Junos ability to announce labeled BGP routes that it knows for sure are invalid, is quite foolish, to say nothing of the fact that it won't just use FECs you already created using LDP. :/ Anyway, if you ever get labeled BGP routes with label 2^20-1, this might be why. Hopefully some kind Juniper folks will be willing to file some bugs on this for me, because I don't have a week to fight with JTAC about it. It is, however, very easy to reproduce the problem. :-) Thanks -- 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
Re: [j-nsp] SCBE-MX XE XFP socket
It is for timing. On Jan 14, 2013, at 7:01 AM, Leigh Porter leigh.por...@ukbroadband.com wrote: Hey All, Does anybody know what the XE XFP socket on the SCBE-MX for? I cannot find any documentation about it anywhere. It's on the end of the card next to the clock interface. -- Leigh __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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] Junos labeled-unicast announces unusable routes, certainly this is a bug
On Mon, Jan 21, 2013 at 4:27 AM, Alex Arseniev alex.arsen...@gmail.com wrote: Probably not what you want to hear at the moment but it is working as designed. No, it isn't. Junos BGP is announcing routes it knows, for sure, are invalid. It knows that because BGP is making up a wrong label (2^20-1) because it hasn't allocated one, and it can't announce the route without a label. This is an inexcusable bug that is very far from working as designed. The documentation is wrong, you cannot configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the same BGP session. If it worked as documented, the above behavior would not happen, and AFI=1 SAFI=1 would be available to use for these routes. That is not the case. -- 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
[j-nsp] (no subject)
My friends started noticing the change during the fourth week of putting this new diet to work http://kyokushin-kctl.com/weight.drop.n.php?SID=055 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos labeled-unicast announces unusable routes, certainly this is a bug
You CAN configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the same BGP
session by specifying inet.3 for labeled-unicast routes:
family inet {
unicast;
labeled-unicast {
rib {
inet.3;
}
}
}
And redistributing LDP/RSVP routes from inet.3 makes perfect LSP stitching
through BGP-LU by label swapping.
Best Regards,
Krasi
On Mon, Jan 21, 2013 at 12:59 PM, Jeff Wheeler j...@inconcepts.biz wrote:
On Mon, Jan 21, 2013 at 4:27 AM, Alex Arseniev alex.arsen...@gmail.com
wrote:
Probably not what you want to hear at the moment but it is working as
designed.
No, it isn't.
Junos BGP is announcing routes it knows, for sure, are invalid. It
knows that because BGP is making up a wrong label (2^20-1) because it
hasn't allocated one, and it can't announce the route without a label.
This is an inexcusable bug that is very far from working as
designed.
The documentation is wrong, you cannot configure both AFI=1 SAFI=1 and
AFI=1 SAFI=4 on the same BGP session. If it worked as documented, the
above behavior would not happen, and AFI=1 SAFI=1 would be available
to use for these routes. That is not the case.
--
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
Re: [j-nsp] MX80 Q-in-Q
On Mon, 21 Jan 2013, lppmas...@yandex.ru wrote: Does MX ambiguous vlan? Do you ambiguous questions ask? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Any word on MX80 MS-DPC?
OK, thanks for the responses everyone! -richard On Sat, Jan 19, 2013 at 8:36 AM, David Kotlerewsky webnet...@gmail.comwrote: Bet on the price being the same for the MS-MPC as the MS-DPC, as the MS-MPC is the replacement for the aging MS-DPC. The MS-MIC will probably be cheaper, but also less powerful since its a smaller form factor, and goes into a less powerful box. Sent from my iPhone On Jan 18, 2013, at 5:21 PM, OBrien, Will obri...@missouri.edu wrote: Interesting. My ms-dpc were very pricy. It'll be interesting to see a price on that one. Will On Jan 18, 2013, at 7:13 PM, Richard Hesse richard.he...@weebly.com wrote: This product was slated to be released in 2012 according to a few KB docs on juniper.net, but 2012 has come and gone without the release of some sort of MS-DPC card. Anyone know if this has been killed off or if it will actually ship in 2013? TIA. -richard ___ 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
Re: [j-nsp] Junos labeled-unicast announces unusable routes,
certainly this is a bug MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I see someone beat me to it but you can specifying inet.3. The docs on this stuff are really poor but that is how you would want to do it so you know known MPLS destinations are being advertised. Now if you want to advertise non MPLS destinations as labeled unicast it does work as well, nothing says it has to be MPLS switched on the advertising router. Phil From: Jeff Wheeler Sent: =E2=80=8E1/=E2=80=8E21/=E2=80=8E2013 6:05 To: Alex Arseniev Cc: juniper-nsp Subject: Re: [j-nsp] Junos labeled-unicast announces unusable routes, certainly this is a bug On Mon, Jan 21, 2013 at 4:27 AM, Alex Arseniev alex.arsen...@gmail.com wr= ote: Probably not what you want to hear at the moment but it is working as designed. No, it isn't. Junos BGP is announcing routes it knows, for sure, are invalid. It knows that because BGP is making up a wrong label (2^20-1) because it hasn't allocated one, and it can't announce the route without a label. This is an inexcusable bug that is very far from working as designed. The documentation is wrong, you cannot configure both AFI=3D1 SAFI=3D1 and AFI=3D1 SAFI=3D4 on the same BGP session. If it worked as documented, the above behavior would not happen, and AFI=3D1 SAFI=3D1 would be available to use for these routes. That is not the case. -- 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
Re: [j-nsp] (no subject)
Are you ready to lose 7 pounds of fat in your first week? Start now http://radiosonfm.com/weight.drop.n.php?SID=918 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Redundancy with MX
Hi, I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. This is what I have come up with so far: a) 2xMX80 Pro: Two seperate devices so less prone to config errors and chassis failure Con: Using redundant uplinks is more complicated (LB would need to be done via routing protocol) b) 1xMX240/480 with redundant SCB and RE Pro: Easier to use redundant uplinks (LACP) Con: Config error as well as chassis failure brings the whole PoP down Any further arguments? Best practices? What did you deploy? Best regards, Markus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
Marcus - I am building about 10 PoPs and opted for the dual mx-80 design. Also looked at making the PoPs all layer 2 with a pair of exs. Plan to use MC-LAG where applicable. On Jan 21, 2013, at 3:43 PM, Markus H hauschild.mar...@gmail.com wrote: Hi, I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. This is what I have come up with so far: a) 2xMX80 Pro: Two seperate devices so less prone to config errors and chassis failure Con: Using redundant uplinks is more complicated (LB would need to be done via routing protocol) b) 1xMX240/480 with redundant SCB and RE Pro: Easier to use redundant uplinks (LACP) Con: Config error as well as chassis failure brings the whole PoP down Any further arguments? Best practices? What did you deploy? Best regards, Markus ___ 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] Redundancy with MX
Any constraints? Power? Bandwidth? What's the driver/function? Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghe...@suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk On 21 Jan 2013, at 20:40, Markus H hauschild.mar...@gmail.com wrote: Hi, I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. This is what I have come up with so far: a) 2xMX80 Pro: Two seperate devices so less prone to config errors and chassis failure Con: Using redundant uplinks is more complicated (LB would need to be done via routing protocol) b) 1xMX240/480 with redundant SCB and RE Pro: Easier to use redundant uplinks (LACP) Con: Config error as well as chassis failure brings the whole PoP down Any further arguments? Best practices? What did you deploy? Best regards, Markus ___ 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
[j-nsp] Fwd: MX80 Q-in-Q
Thanks for the reply.
I need to terminate Q-in-Q with multiple internal tags.
inner-list
Junos 11.4R1.14
Allows you to create only if the interface will be family bridge,
I need a L3 interface.
21.01.2013, 18:55, sth...@nethelp.no sth...@nethelp.no:
Does MX ambiguous vlan?
Please rephrase the question.
If you're asking whether the MX80 supports dual port Ethernet
traffic, the answer is yes. E.g.
ge-1/0/0 {
flexible-vlan-tagging;
encapsulation flexible ethernet services;
unit 11 {
vlan tags outer 1063 inner 900;
family inet {
address 10.9.130.1/30;
}
}
}
Steinar Haug, Nethelp consulting, sth...@nethelp.no
Завершение пересылаемого сообщения
___
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] Fwd: MX80 Q-in-Q
Your question is still a bit ambiguous.
If you have an inner-list and want to bind it to a L3 interface, then you
need to make a bridge domain and attach the IRB to that.
Alternatively, depending on what you want, we're doing something along the
lines of the below, where we bind customers together in DHCP groups and
relay them to a DHCP server with option-82, so we know which customer gets
what IP - again, not sure if it's customers or what that you're trying to
stitch together ;-)
Cheers, Bjørn
unit 301 {
proxy-arp restricted;
vlan-tags outer 1198 inner 42;
family inet {
mac-validate strict;
unnumbered-address lo0.0 preferred-source-address x.x.x.x;
}
}
and under forwarding-options dhcp-relay:
group data {
active-server-group data;
overrides {
always-write-option-82;
}
relay-option-82 {
circuit-id {
use-interface-description logical;
}
}
interface ge-0/0/0.301;
..
}
On Mon, Jan 21, 2013 at 11:23 PM, lppmas...@yandex.ru lppmas...@ya.ruwrote:
Thanks for the reply.
I need to terminate Q-in-Q with multiple internal tags.
inner-list
Junos 11.4R1.14
Allows you to create only if the interface will be family bridge,
I need a L3 interface.
21.01.2013, 18:55, sth...@nethelp.no sth...@nethelp.no:
Does MX ambiguous vlan?
Please rephrase the question.
If you're asking whether the MX80 supports dual port Ethernet
traffic, the answer is yes. E.g.
ge-1/0/0 {
flexible-vlan-tagging;
encapsulation flexible ethernet services;
unit 11 {
vlan tags outer 1063 inner 900;
family inet {
address 10.9.130.1/30;
}
}
}
Steinar Haug, Nethelp consulting, sth...@nethelp.no
Завершение пересылаемого сообщения
___
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
[j-nsp] RE : Junos 12.3 Release Date
It should be issued by the end of the month (31st)... Caillin Bathern caill...@commtelns.com a écrit : 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 _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundancy with MX
On (2013-01-21 21:40 +0100), Markus H wrote: I wonder what kind of redundancy the community would prefer for small-medium sized PoPs. a) 2xMX80 b) 1xMX240/480 with redundant SCB and RE a) no question. As long as you can live with modest RE performance of MX80. Routing separated two units always better than stateful single unit. Frankly, I'm not sure if dual RE even delivers better MTBF, since it does expose you to new issues, even outside HW failures. It probably does deliver you better MTTR though. jabbering: I've been installing 8 MX960 in last week and this week, 5/8 of them suffered from some type of FW misprogram. They were delivered with export software, so field-tech pushed template config, disabled lo0 filter and enabled telnet, to allow remote management. After remotely over telnet upgrading RE (no ISSU) and swapping or reloading master RE, I found that RE filter was again enabled, even though it was not seen in config I could observe my telnet packets hitting discard term couter of filter which wasn't on any interface. Fix was 'commit full'. I've seen other issues too, affecting transit traffic too, post-upgrade. I've not yet lost RE due to HW failure though. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
