Re: [j-nsp] JUNOS and MX Trio cards
On Thursday 01 July 2010 05:27:26 am Joe Hughes wrote: > I began an exercise a few months back researching the > options available to replace some of our Cisco gear with > Juniper. At the time - it was looking like a combination > of the M7i and the EX series switches - We implemented this combo for some Metro deployments in our attempt to have a non-STP-based control plane in the Access. It works quite well. But the MX80 makes much more sense now. > but since > learning the EX has limitations in regard to MPLS and > the fact the M7i is getting old - the MX looked a > perfect candidate; decent port density with sufficient > horsepower. Despite the attractiveness of the platform, > I'm not sure I could cope with the sleepless nights. We couldn't wait to get the Trio-based cards and moved to purchase our new batch of MX480 DPC's. Even if we'd gotten them (which would have been several months later), tons of bugs would need to be worked out (recall the start of this thread). The real PITA is that the Trio cards will give you more value for money when you start looking at platforms like the MX240 or higher. Just that the code sucks today. I mean, what Richard was trying to do was pretty stock. If this issue is not limited to the batch of kit he received, JUNOS has really become something else. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
On Wednesday 30 June 2010 05:28:39 pm Derick Winkworth wrote: > I understand > things will get much, much better in 10.3 thru 10.5. Without any confirmation from anyone at Juniper, I suspect the same. This would be a mirror experiences with JUNOS 9, where anything pre-9.3 was really terrible. When I look back at JUNOS 8, 8.5 seems to be the favorite, although I see 8.1 has EEOL (well, that seems to have run out too, last May). If we trend this, it would make sense to stay on 8.5 and 9.6 until 10.3 is out, and remain on that up to 10.6 until 11.3 is out, and then on that till 11.6 until 12.3 is out... see a pattern :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stripping off BGP Prepends
On Wed, Jun 30, 2010 at 04:37:55PM -0700, Tony Li wrote: > > On Jun 30, 2010, at 12:17 AM, Richard A Steenbergen wrote: > > > There is absolutely no way to implement anything like this in JUNOS, not > > even with hidden commands, despite about 10 years of asking for a secret > > way to manipulate the as-path. > > Arbitrary manipulations of the AS path would break BGP's loop > avoidance mechanism, resulting in an Internet full of forwarding > loops. No, arbitary manipulation of the AS path COULD break bgp's loop detection mechanism, if used incorrectly (but so could a lot of things). That's why I said make it hidden, so the average idiot won't come along and screw themselves. Unfortunately there are some times when you just NEED to do it, and running things through a custom BGP implementation isn't always easy when you can't do ebgp-multihop for political reasons. Note that I don't consider the OP's situation to be a legitimate application for it, I want it for my own reasons. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stripping off BGP Prepends
You can create a temporary static route and redistribute it upstream using bgp while blocking the original one. But this is with implication that the route will be belonging to you AS# but it is for temporary anyway until your customer strips their AS prepend. Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stripping off BGP Prepends
On Jun 30, 2010, at 12:17 AM, Richard A Steenbergen wrote: > There is absolutely no way to implement anything like this in JUNOS, not > even with hidden commands, despite about 10 years of asking for a secret > way to manipulate the as-path. Arbitrary manipulations of the AS path would break BGP's loop avoidance mechanism, resulting in an Internet full of forwarding loops. Tony ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
On 30 June 2010 15:49, Chris Evans wrote: > Is there any way that someone could tell me how to reproduce the stalled > route issue? How do I see if is happening etc? > > We are about to purchase some mx's to replace our m series and would love to > nail this. The question of stability (or lack of) is of interest to me. I began an exercise a few months back researching the options available to replace some of our Cisco gear with Juniper. At the time - it was looking like a combination of the M7i and the EX series switches - but since learning the EX has limitations in regard to MPLS and the fact the M7i is getting old - the MX looked a perfect candidate; decent port density with sufficient horsepower. Despite the attractiveness of the platform, I'm not sure I could cope with the sleepless nights. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Redundant VPLS to redundant switching topologies
On Wed, Jun 30, 2010 at 04:53:54PM -0400, Ross Vandegrift wrote: > Subject: [j-nsp] The status of VLAN ID spaces on the MX Oops - forgot to update the subject of this message when I changed the topic :) Ross -- Ross Vandegrift r...@kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] The status of VLAN ID spaces on the MX
Hi everyone, Suppose that I have redundant aggregation switches, S1 and S2. Every access device gets an uplink from each. S1 and S2 have a trunk between them. STP is running to break the loops. All of this is at layer 2. Is there any way to provide multihomed VPLS to some or all VLANs without introducing a forwarding loop? I've been unable to come up with an effective solution. This is on MX if it makes a difference. Ross -- Ross Vandegrift r...@kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] P2MP LSP
Mark, So from your replies: it look like we have already provisioned P2MP tunnel right? Then in document they talk about static lsp and dynamic LSP configuration then what is it all about? Now about PMSI attribute if tunnel is already built then why do we need to communicate the PMSI information? Still bit confused about the PMSI attribute usage. David W. On Wed, Jun 30, 2010 at 4:33 AM, Mark Tinka wrote: > On Wednesday 30 June 2010 03:18:34 am David water wrote: > > > Using those route types we can communicate about the > > source and destinations in MVPN. > > Source information is learned by the Sender PE router. This > can either be through the VPN C-RP infrastructure or MSDP. > > Receiver PE routers would then use this information to > generate Type 5 Source Active AD (Auto-discovery) routes. > These routes allow the Receiver PE routers to identify > active Multicast sources. > > Ideally (I say ideally because we had some nasty bugs in our > case), this would then lead to the generation of Type 7 > Source Tree Join routes on the Receiver PE routers, assuming > the router learns of C-join information, e.g., static IGMP > configuration, or has a Type 6 Shared Tree Join route and > receives a Type 5 route. > > You can reference this entire process in the documents I > sent you earlier. > > > Now as we know how to > > discover the source and receiver its time for RSVP to > > take care of building the P2MP right? > > It doesn't necessarily happen in this sequence. > > P-tunnel setup, i.e., association of a p2mp LSP with the RSI > carrying MCAST-VPN NLRI would be part of your standard > configuration when implementing BGP/MPLS NG-MVPN's. > > The PMSI attribute allows the P-tunnel to be announced in > the network via BGP. When the Receiver PE routers receive > this information, they bind the P-tunnel to the correct RSI > that imported it. Once the P-tunnel is bound to the right > RSI, the Receiver PE router can forward the Multicast > traffic into the local VRF, using MPLS. > > Again, see those documents I sent. They get into very good > detail about the process. > > > So RSVP does use > > the the BGP discovered information to establish LSP, > > correct? So this way LSPs are totally dynamic. > > Not quite - the p2mp LSP's are setup by hand. BGP is just > used to distribute control plane information about Multicast > routing data. Once the control plane provides sufficient > information, traffic is forwarded down the pre-setup p2mp > LSP's (MPLS data plane). > > If you're looking at dynamic p2mp LSP setup, consider mLDP > (Multicast LDP). Like in regular LDP for unicast > applications, it's dynamic. > > I don't have any solid details yet on Juniper's plans re: > mLDP, but I know Cisco are pushing this very heavily, along > with some other options to using BGP as a replacement for > PIM. > > Good times ahead between Juniper and Cisco, in this space > :-). > > Cheers, > > Mark. > -- David W. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
On Wed, Jun 30, 2010 at 09:54:16AM -0400, Phil Bedard wrote: > When were you evaulating it? I think both of those two features have been > available for some time now, almost 2 years. > Less than a half year. What we had in the lab: - few boxes 7750 SR-7, IOM2 based hw, running TiMOS 7.something - few boxes 7450 ESS, don't rember OS version - Agilent N2X router tester 1. We were unable to configure 4byte ASN. 2. We were able to configure BGP as PE-CE protocol but it never came up. ALU network expert have found an internal reference that BGP as PE-CE will be available on 2010Q3 starting with new major release of the TiMOS. 3. IOM2 issue was achieved with disarranged full-view from N2X to the 7750SR and making random withdrawal and re-announcement for set of prefixes under the test. Possibly ALU have fixed IOM issue with the new hardware on IOM3 card but we haven't tested this due to the limited lab environment. > Not to say they do not have their own set of issues along with Juniper and > Cisco... > > Phil > > > > > [dd] > > > >> > >> How unfortunate. I wonder of Alca-Lu can do better. Lord knows Cisco > >> could care less about code quality. surely some networking vendor must > >> give a sh*t. > > > > Small brief from our ALU equipment evaluation: > > BGP:4-byte ASN unsupported, BGP:PE-CE protocol unsupported, IOM2 can forward > > traffic for detached neighbour for 30 min > > > > Do you still wonder they can do better? -- ZA-RIPE||ZA1-UANIC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
When were you evaulating it? I think both of those two features have been available for some time now, almost 2 years. Not to say they do not have their own set of issues along with Juniper and Cisco... Phil On Jun 30, 2010, at 4:26 AM, Andrey Zarechansky wrote: > On Tue, Jun 29, 2010 at 06:50:49PM -0700, Derick Winkworth wrote: > > [dd] > >> >> How unfortunate. I wonder of Alca-Lu can do better. Lord knows Cisco could >> care less about code quality. surely some networking vendor must give a >> sh*t. > > Small brief from our ALU equipment evaluation: > BGP:4-byte ASN unsupported, BGP:PE-CE protocol unsupported, IOM2 can forward > traffic for detached neighbour for 30 min > > Do you still wonder they can do better? > > -- > ZA-RIPE||ZA1-UANIC > ___ > 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 and MX Trio cards
Is there any way that someone could tell me how to reproduce the stalled route issue? How do I see if is happening etc? We are about to purchase some mx's to replace our m series and would love to nail this. On Jun 30, 2010 7:35 AM, "Derick Winkworth" wrote: hahahaha nice! From: Andrey Zarechansky To: juniper-nsp@puck.nether.net Sent: Wed, June 30, 2010 3:26:50 AM Subject: Re: [j-nsp] JUNOS and MX Trio cards On Tue, Jun 29, 2010 at 06:50:49PM -0700, Derick Winkworth wrote: [dd] > > How unfortunate. I wo... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stripping off BGP Prepends
Thanks for the replies I follow what you're saying Phil but that's "ugly".. no offense ;) We're going to fire this back to the customer and tell them there's nothing we can do I think we try our best to be "hands off" when it comes to customer traffic involving BGP (except for typical filters etc of course). There are some other uses though for this feature - I'm figuring if RAS hasn't gotten this from Juniper in 10 years I'm wasting time even thinking about it...;) Paul -Original Message- From: phill.jolli...@gmail.com [mailto:phill.jolli...@gmail.com] On Behalf Of Phill Jolliffe Sent: Wednesday, June 30, 2010 9:37 AM To: Richard A Steenbergen Cc: Paul Stewart; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Stripping off BGP Prepends How about bloking their bgp route and instead redist'ing an aggregate with a configured AS-Path. Not exactly the same but similar in the end On Wed, Jun 30, 2010 at 8:17 AM, Richard A Steenbergen wrote: > On Tue, Jun 29, 2010 at 10:19:06PM -0400, Paul Stewart wrote: >> Hi there.. >> >> Some of you might get a chuckle out of this... Have a customer who >> called and wants us to strip off their prepends they are padding in >> their BGP session with us. They are padding their AS number 6 times >> and now the traffic levels are getting too large with their other >> upstream provider. >> >> Obviously I asked - umm... why don't *you* change it? Their answer >> was that a consultant set this up for them and he's on holidays this >> week yikes... >> >> Anyways, JunOS on MX series - Do this in an import policy? I'm >> looking for something that says "AS numbers in path only allowed once" >> for simplicity sake I think > > There is absolutely no way to implement anything like this in JUNOS, not > even with hidden commands, despite about 10 years of asking for a secret > way to manipulate the as-path. > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Phill Jolliffe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stripping off BGP Prepends
Not the first time I've been told my proposition is technically possible but to to ugly to execute ;-) Phill ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stripping off BGP Prepends
How about bloking their bgp route and instead redist'ing an aggregate with a configured AS-Path. Not exactly the same but similar in the end On Wed, Jun 30, 2010 at 8:17 AM, Richard A Steenbergen wrote: > On Tue, Jun 29, 2010 at 10:19:06PM -0400, Paul Stewart wrote: >> Hi there.. >> >> Some of you might get a chuckle out of this... Have a customer who >> called and wants us to strip off their prepends they are padding in >> their BGP session with us. They are padding their AS number 6 times >> and now the traffic levels are getting too large with their other >> upstream provider. >> >> Obviously I asked - umm... why don't *you* change it? Their answer >> was that a consultant set this up for them and he's on holidays this >> week yikes... >> >> Anyways, JunOS on MX series - Do this in an import policy? I'm >> looking for something that says "AS numbers in path only allowed once" >> for simplicity sake I think > > There is absolutely no way to implement anything like this in JUNOS, not > even with hidden commands, despite about 10 years of asking for a secret > way to manipulate the as-path. > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Phill Jolliffe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] P2MP LSP
Hey Mark well , here is what I think, I have not got extensive experience in NG MVPN , I may be wrong so feel free to contradict me, (just do it kindly ;-) I think it depends on the size of your network ,to see which is more appropriate, and the setup of the network. The larger your network, the better to use selective P tunnels, the smaller then better to use inclusive trees The reason is, using inclusive trees on large size network means keeping ressources and state accross all PE, where some of PE's potentially will be used very few times . In Selective , you only use the ressources of the PE's that are involved in the MVPN. I personally think Selective P tunnels is more scalable as it gives you more control , especially if you have large requirement for IP multicast bandwith , you decide where packets are needed, and the states are only accross these PE routers. This is confirms by what you wrote in your previous mail, describing the difference between the 2 method. But the real question is how much more state does it create , in proportion, between inclusive P tunnels and selective , and is it worth the processing on all PE routers compared to a slightly higher burden on few PE routers ? I don't know how much more burden it create but I doubt it would be a massive difference as you say. But then of course, it is a balance of what is acceptable or not based on one's opinions. For me, in essence , in selective , you replace a type 1 routes by a type 3 & 4 routes. Both use BGP to exchange information between,and if you use RSVP P2MP, then both use the same tunnel type, only For Selective,it just add an additional routes into the PMSI attribute during the Exchange. Now true that selective , do also an extra distribution/mapping of C,S-C,G between PE-PE, and has an extra policy for the type 4 but even then I am not sure, how much more all this creates. I am not sure in terms of forwarding state , how does inclusive and slective compared to each other , and if it is much more for one or the other . If anyone know, please let me know Well that's what I think, and it might actually be worth only 2 cents , but that's my 2 cents ;-) On 30 June 2010 11:08, Mark Tinka wrote: > On Wednesday 30 June 2010 03:38:45 am Humair Ali wrote: > > > i think most implementation use inclusive P-tunnels, as > > it easier to manage but I personnaly think it add more > > burden on the network. > > I'm positive you're already familiar with all this, but just > for the archives: > > Inclusive trees eliminate the need for too much state in the > core, but requires that all Receiver PE routers are aware > about the Multicast infrastructure regardless of whether > they have downstream listeners or not. > > Selective trees are the exact opposite. You can choose which > Receiver PE routers will handle Multicast information so > only interested receivers attract traffic to the right > Receiver PE routers, but it increases the amount of state in > the core. > > I would really like to see how mLDP plays into this whole > mix. > > Cheers, > > Mark. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
hahahaha nice! From: Andrey Zarechansky To: juniper-nsp@puck.nether.net Sent: Wed, June 30, 2010 3:26:50 AM Subject: Re: [j-nsp] JUNOS and MX Trio cards On Tue, Jun 29, 2010 at 06:50:49PM -0700, Derick Winkworth wrote: [dd] > > How unfortunate. I wonder of Alca-Lu can do better. Lord knows Cisco could > care less about code quality. surely some networking vendor must give a > sh*t. Small brief from our ALU equipment evaluation: BGP:4-byte ASN unsupported, BGP:PE-CE protocol unsupported, IOM2 can forward traffic for detached neighbour for 30 min Do you still wonder they can do better? -- ZA-RIPE||ZA1-UANIC ___ 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] M7i crash with strage log entry
If you could give me a hint where to find it I would be really glad! Tom Am 30.06.2010 12:43, schrieb Jared Mauch: > Have you disabled adaptive standby? I can look up the configuration in a few > if you don't have it. > > Sent from my iThing > > On Jun 30, 2010, at 5:46 AM, Thomas Eichhorn wrote: > >> Thanks for all your help, >> I cannot simply remove the disk nor the cf card, >> the box is to far away. >> >> I now tried to remove the disk from the boot list, >> so it does not get initialized and the box completely runs >> from CF - If that doesn't work I will try the other way (disabling >> cf and enabling disk). >> >> If this works I will give feedback here so that people also >> running into that problem will find it. >> >> Tom >> >> Am 30.06.2010 10:51, schrieb Marcin Kucharczyk: >>> On Wednesday 30 of June 2010 10:10:24 Akhmedd Aly wrote: Hi Marcin, we have the same problems with M7Is in the may: *M7i> panic: ad_ioctl:1275539168: ad1: Standby not armed but state is in valid: state="ARMED"* And all of this problems come after installing (we never did not use internal CF in its before) Compact Flash 1GB (not from official Juniper upgrade kit), its also rebooted every 3-4 hours with the same PANIC message. After removing CFs we do not have this problems. So I think that it was not problems with internal disks... >>> >>> Hi, >>> >>> our router had rebooted every 4 hours and 21 minutes (exactly). As I wrote >>> to >>> Thomas we had removed HDD, and now router runs on CF only. Our CF isn't >>> from >>> official Juniper upgrade kit, it's regular Kingston Standard 4GB CF Type 1. >>> >>> It's a pity that CF and HDD can't run together. >>> >>> Regards, >>> Marcin >>> 2010/6/22 Marcin Kucharczyk > Hello, > > tonight one of ours M7i crashed with strange log entry: > > savecore: reboot after panic: ad_ioctl:1277186066: ad1: Standby not armed > but > state is invalid: state="ARMED" > > Disk was replaced 2 weeks ago. Yesterday we inserted new compact flash > card (there wasn't any before). We upgraded Junos to 10.0R3.10 also. Do > you have any idea what could happened? > > Regards, > Marcin Kucharczyk >>> ___ >>> 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] M7i crash with strage log entry
Have you disabled adaptive standby? I can look up the configuration in a few if you don't have it. Sent from my iThing On Jun 30, 2010, at 5:46 AM, Thomas Eichhorn wrote: > Thanks for all your help, > I cannot simply remove the disk nor the cf card, > the box is to far away. > > I now tried to remove the disk from the boot list, > so it does not get initialized and the box completely runs > from CF - If that doesn't work I will try the other way (disabling > cf and enabling disk). > > If this works I will give feedback here so that people also > running into that problem will find it. > > Tom > > Am 30.06.2010 10:51, schrieb Marcin Kucharczyk: >> On Wednesday 30 of June 2010 10:10:24 Akhmedd Aly wrote: >>> Hi Marcin, >>> >>> we have the same problems with M7Is in the may: >>> *M7i> panic: ad_ioctl:1275539168: ad1: Standby not armed but state is in >>> valid: state="ARMED"* >>> >>> And all of this problems come after installing (we never did not use >>> internal CF in its before) Compact Flash 1GB (not from official Juniper >>> upgrade kit), its also rebooted every 3-4 hours with the same PANIC >>> message. >>> >>> After removing CFs we do not have this problems. So I think that it was not >>> problems with internal disks... >>> >> >> Hi, >> >> our router had rebooted every 4 hours and 21 minutes (exactly). As I wrote >> to >> Thomas we had removed HDD, and now router runs on CF only. Our CF isn't from >> official Juniper upgrade kit, it's regular Kingston Standard 4GB CF Type 1. >> >> It's a pity that CF and HDD can't run together. >> >> Regards, >> Marcin >> >>> >>> >>> 2010/6/22 Marcin Kucharczyk >>> Hello, tonight one of ours M7i crashed with strange log entry: savecore: reboot after panic: ad_ioctl:1277186066: ad1: Standby not armed but state is invalid: state="ARMED" Disk was replaced 2 weeks ago. Yesterday we inserted new compact flash card (there wasn't any before). We upgraded Junos to 10.0R3.10 also. Do you have any idea what could happened? Regards, Marcin Kucharczyk >> ___ >> 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] P2MP LSP
On Wednesday 30 June 2010 03:38:45 am Humair Ali wrote: > i think most implementation use inclusive P-tunnels, as > it easier to manage but I personnaly think it add more > burden on the network. I'm positive you're already familiar with all this, but just for the archives: Inclusive trees eliminate the need for too much state in the core, but requires that all Receiver PE routers are aware about the Multicast infrastructure regardless of whether they have downstream listeners or not. Selective trees are the exact opposite. You can choose which Receiver PE routers will handle Multicast information so only interested receivers attract traffic to the right Receiver PE routers, but it increases the amount of state in the core. I would really like to see how mLDP plays into this whole mix. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M7i crash with strage log entry
Thanks for all your help, I cannot simply remove the disk nor the cf card, the box is to far away. I now tried to remove the disk from the boot list, so it does not get initialized and the box completely runs from CF - If that doesn't work I will try the other way (disabling cf and enabling disk). If this works I will give feedback here so that people also running into that problem will find it. Tom Am 30.06.2010 10:51, schrieb Marcin Kucharczyk: > On Wednesday 30 of June 2010 10:10:24 Akhmedd Aly wrote: >> Hi Marcin, >> >> we have the same problems with M7Is in the may: >> *M7i> panic: ad_ioctl:1275539168: ad1: Standby not armed but state is in >> valid: state="ARMED"* >> >> And all of this problems come after installing (we never did not use >> internal CF in its before) Compact Flash 1GB (not from official Juniper >> upgrade kit), its also rebooted every 3-4 hours with the same PANIC >> message. >> >> After removing CFs we do not have this problems. So I think that it was not >> problems with internal disks... >> > > Hi, > > our router had rebooted every 4 hours and 21 minutes (exactly). As I wrote to > Thomas we had removed HDD, and now router runs on CF only. Our CF isn't from > official Juniper upgrade kit, it's regular Kingston Standard 4GB CF Type 1. > > It's a pity that CF and HDD can't run together. > > Regards, > Marcin > >> >> >> 2010/6/22 Marcin Kucharczyk >> >>> Hello, >>> >>> tonight one of ours M7i crashed with strange log entry: >>> >>> savecore: reboot after panic: ad_ioctl:1277186066: ad1: Standby not armed >>> but >>> state is invalid: state="ARMED" >>> >>> Disk was replaced 2 weeks ago. Yesterday we inserted new compact flash >>> card (there wasn't any before). We upgraded Junos to 10.0R3.10 also. Do >>> you have any idea what could happened? >>> >>> Regards, >>> Marcin Kucharczyk > ___ > 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 and MX Trio cards
# 6 years by my count. The weird thing is I'm constantly running into plenty of really smart competent people at Juniper who do want to help, they just have no idea that things are really this broken, or they aren't empowered to do anything about it. I guess you could call that "they don't care" at a corporate level. ## Yeah, let me just say I work with a number of supremely competent people at Juniper who care immensely about the customer and the product. I can't emphasize that enough. I think Juniper does care, actually, I think that there is "paradigm" shift that is happening there with respect to how code is produced. I understand things will get much, much better in 10.3 thru 10.5. In the meantime, 10.0r3 / r4 will likely be our production code releases. Knock on wood, these will do at the moment... The folks we are working with at Juniper are putting some effort into making sure these are solid releases for us. ## Does anyone in systest actually do anything any more? ## I have actually heard there is some frustration there. See comment above about paradigm-shift. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
On Tue, Jun 29, 2010 at 06:50:49PM -0700, Derick Winkworth wrote: [dd] > > How unfortunate. I wonder of Alca-Lu can do better. Lord knows Cisco could > care less about code quality. surely some networking vendor must give a > sh*t. Small brief from our ALU equipment evaluation: BGP:4-byte ASN unsupported, BGP:PE-CE protocol unsupported, IOM2 can forward traffic for detached neighbour for 30 min Do you still wonder they can do better? -- ZA-RIPE||ZA1-UANIC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
On Wednesday 30 of June 2010 03:50:49 Derick Winkworth wrote: > I wonder what their official line is. Might be similar to their official > line with respect to the manufacturing issue with the EX series, where so > many ASICs are just bad... I think they have some code in JUNOS now that > detects the bad ASICs and just resets them when the failure detected. Do you have some more information about broken ASICs in EX series? We have few EX switches and we have some problems with them (strange behavior with STP, some link UP/DOWN issues). Thanks and regards, Marcin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M7i crash with strage log entry
On Wednesday 30 of June 2010 10:10:24 Akhmedd Aly wrote: > Hi Marcin, > > we have the same problems with M7Is in the may: > *M7i> panic: ad_ioctl:1275539168: ad1: Standby not armed but state is in > valid: state="ARMED"* > > And all of this problems come after installing (we never did not use > internal CF in its before) Compact Flash 1GB (not from official Juniper > upgrade kit), its also rebooted every 3-4 hours with the same PANIC > message. > > After removing CFs we do not have this problems. So I think that it was not > problems with internal disks... > Hi, our router had rebooted every 4 hours and 21 minutes (exactly). As I wrote to Thomas we had removed HDD, and now router runs on CF only. Our CF isn't from official Juniper upgrade kit, it's regular Kingston Standard 4GB CF Type 1. It's a pity that CF and HDD can't run together. Regards, Marcin > > > 2010/6/22 Marcin Kucharczyk > > > Hello, > > > > tonight one of ours M7i crashed with strange log entry: > > > > savecore: reboot after panic: ad_ioctl:1277186066: ad1: Standby not armed > > but > > state is invalid: state="ARMED" > > > > Disk was replaced 2 weeks ago. Yesterday we inserted new compact flash > > card (there wasn't any before). We upgraded Junos to 10.0R3.10 also. Do > > you have any idea what could happened? > > > > Regards, > > Marcin Kucharczyk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] P2MP LSP
On Wednesday 30 June 2010 03:18:34 am David water wrote: > Using those route types we can communicate about the > source and destinations in MVPN. Source information is learned by the Sender PE router. This can either be through the VPN C-RP infrastructure or MSDP. Receiver PE routers would then use this information to generate Type 5 Source Active AD (Auto-discovery) routes. These routes allow the Receiver PE routers to identify active Multicast sources. Ideally (I say ideally because we had some nasty bugs in our case), this would then lead to the generation of Type 7 Source Tree Join routes on the Receiver PE routers, assuming the router learns of C-join information, e.g., static IGMP configuration, or has a Type 6 Shared Tree Join route and receives a Type 5 route. You can reference this entire process in the documents I sent you earlier. > Now as we know how to > discover the source and receiver its time for RSVP to > take care of building the P2MP right? It doesn't necessarily happen in this sequence. P-tunnel setup, i.e., association of a p2mp LSP with the RSI carrying MCAST-VPN NLRI would be part of your standard configuration when implementing BGP/MPLS NG-MVPN's. The PMSI attribute allows the P-tunnel to be announced in the network via BGP. When the Receiver PE routers receive this information, they bind the P-tunnel to the correct RSI that imported it. Once the P-tunnel is bound to the right RSI, the Receiver PE router can forward the Multicast traffic into the local VRF, using MPLS. Again, see those documents I sent. They get into very good detail about the process. > So RSVP does use > the the BGP discovered information to establish LSP, > correct? So this way LSPs are totally dynamic. Not quite - the p2mp LSP's are setup by hand. BGP is just used to distribute control plane information about Multicast routing data. Once the control plane provides sufficient information, traffic is forwarded down the pre-setup p2mp LSP's (MPLS data plane). If you're looking at dynamic p2mp LSP setup, consider mLDP (Multicast LDP). Like in regular LDP for unicast applications, it's dynamic. I don't have any solid details yet on Juniper's plans re: mLDP, but I know Cisco are pushing this very heavily, along with some other options to using BGP as a replacement for PIM. Good times ahead between Juniper and Cisco, in this space :-). Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
On Tue, Jun 29, 2010 at 06:50:49PM -0700, Derick Winkworth wrote: > So basically, this stalled route issue has been going on for so long, > that its truthful to say that Juniper probably doesn't think its > important to fix? or they don't care? 6 years by my count. The weird thing is I'm constantly running into plenty of really smart competent people at Juniper who do want to help, they just have no idea that things are really this broken, or they aren't empowered to do anything about it. I guess you could call that "they don't care" at a corporate level. Oh and btw, they also broke subinterface counters in 10.2R1 too: IF-MIB::ifDescr.539 = STRING: xe-1/0/1 IF-MIB::ifDescr.583 = STRING: xe-1/0/1.0 IF-MIB::ifHCInOctets.539 = Counter64: 3917358216 IF-MIB::ifHCInOctets.583 = Counter64: 0 IF-MIB::ifHCOutOctets.539 = Counter64: 20928565080777 IF-MIB::ifHCOutOctets.583 = Counter64: 8643351 The really scary part is I can name a lot of big networks who are critically under-provisioned right now, because they've been holding off on new DPC purchases for their MX's pending shipment of Trio cards. I think Juniper is about to find themselves in a world of hurt when these guys go to deploy the new cards and discover what a disaster modern JUNOS has become. Seriously, how the hell do you manage to ship production code that has broken subinterface counters? Does anyone in systest actually do anything any more? -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Crashing M5 with some log regarding the hard drive
Hi guys, we have the same problems with M7Is in the may: *M7i> panic: ad_ioctl:1275539168: ad1: Standby not armed but state is in valid: state="ARMED"* And all of this problems come after installing (we never did not use internal CF in its before) Compact Flash 1GB (not from official Juniper upgrade kit), its also rebooted every 3-4 hours with the same PANIC message. After removing CFs we do not have this problems. So I think that it was not problems with internal disks... -- AA 2010/6/29 Marcin Kucharczyk > On Tuesday 29 of June 2010 10:48:30 Thomas Eichhorn wrote: > > Hi all, > > > > I have a M5 which is currently rebooting almost exactly all 4 hours with > > the following log: > > > > Jun 29 08:39:45 r1 savecore: reboot after panic: ad_ioctl:1277800528: > ad1: > > Standby not armed but state is invalid: state="ARMED" Jun 29 08:39:45 r1 > > /kernel: savecore: reboot after panic: ad_ioctl:1277800528: ad1: Standby > > not armed but state is invalid: state="ARMED" > > > > I know that somebody has seen this on M7i some time ago - but did not got > > an anwser.. > > > > I run that box with 9.3R4.4 and have updated also the CF-card - but the > > harddrive is the one which has been where for almost ever and never made > > such problems.. > > > > Any clue? > > > Hi, > we got answer from Aditya mahale: > "This looks like a issue with adaptive standby for hard drive. Please open > a > JTAC case" > > Unfortunately our support for this router has finished. We replaced > problematic HDD but it didn't help. Finally we removed HDD and currently > router > runs on CF only. > > We have another M7i where CF was replaced and software was upgraded but > there > are no problems. > > Regards, > Marcin Kucharczyk > -- > Marcin Kucharczyk Dział Sieciowy ICM, Uniwersytet Warszawski > m.kucharc...@net.icm.edu.pl (+48-22) 5520527, 8268009, fax. 8284195 >http://www.net.icm.edu.pl/ > > ___ > 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] M7i crash with strage log entry
Hi Marcin, we have the same problems with M7Is in the may: *M7i> panic: ad_ioctl:1275539168: ad1: Standby not armed but state is in valid: state="ARMED"* And all of this problems come after installing (we never did not use internal CF in its before) Compact Flash 1GB (not from official Juniper upgrade kit), its also rebooted every 3-4 hours with the same PANIC message. After removing CFs we do not have this problems. So I think that it was not problems with internal disks... -- AA 2010/6/22 Marcin Kucharczyk > Hello, > > tonight one of ours M7i crashed with strange log entry: > > savecore: reboot after panic: ad_ioctl:1277186066: ad1: Standby not armed > but > state is invalid: state="ARMED" > > Disk was replaced 2 weeks ago. Yesterday we inserted new compact flash card > (there wasn't any before). We upgraded Junos to 10.0R3.10 also. Do you have > any idea what could happened? > > Regards, > Marcin Kucharczyk > > ___ > 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] Stripping off BGP Prepends
On Tue, Jun 29, 2010 at 10:19:06PM -0400, Paul Stewart wrote: > Hi there.. > > Some of you might get a chuckle out of this... Have a customer who > called and wants us to strip off their prepends they are padding in > their BGP session with us. They are padding their AS number 6 times > and now the traffic levels are getting too large with their other > upstream provider. > > Obviously I asked - umm... why don't *you* change it? Their answer > was that a consultant set this up for them and he's on holidays this > week yikes... > > Anyways, JunOS on MX series - Do this in an import policy? I'm > looking for something that says "AS numbers in path only allowed once" > for simplicity sake I think There is absolutely no way to implement anything like this in JUNOS, not even with hidden commands, despite about 10 years of asking for a secret way to manipulate the as-path. -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
