Re: [j-nsp] MX80 upgrade path 18.4R
On 15/Jun/20 16:20, Richard McGovern via juniper-nsp wrote: > Better approach to whole subject is to not fall so far behind on Code > upgrades. I know, easier said then done. I'd say more than 2 or 3 behind > current is a risk, and I am all for "if it's not broken, why change". So > today's code stream is 20.x based. You should at least be on some 17.x, or > better yet in many cases 18.x. You better be able to find a stable release > in some version of these code streams. On our MX480's, we are on 17. On our MX204's, we are on 19. We generally try to upgrade every 1.5 years. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 upgrade path 18.4R
--- Begin Message --- I believe Juniper has at least slightly modified their view on upgrades. The old "no more than 2 release jumps" was based upon when EEOL type releases existed; these do not really exist anymore. AFAIK, the major issue with BIG SW jumps is with the config. New SW may have depreciated old commands which might be in your config. From my experience (primarily with QFX not MX) the SW upgrade works, but if new SW does not recognize some lines in the config, box will likely re-boot into a default config. My suggestion is to test basic config upgrade from whatever code you are on to the new code. If there is a config situation, you can then troubleshoot it prior to major multiple device upgrades. IMHO, if you are going to run into a situation with an upgrade from SW 'X' to SW 'Z' you are very likely to find this same situation somewhere along the upgrade path of 'X' -> 'Y' -> 'Z', no matter how many 'Y' releases you use. Better approach to whole subject is to not fall so far behind on Code upgrades. I know, easier said then done. I'd say more than 2 or 3 behind current is a risk, and I am all for "if it's not broken, why change". So today's code stream is 20.x based. You should at least be on some 17.x, or better yet in many cases 18.x. You better be able to find a stable release in some version of these code streams. My 2 cents worth. Richard McGovern Sr Sales Engineer, Juniper Networks 978-618-3342 I’d rather be lucky than good, as I know I am not good I don’t make the news, I just report it On 6/15/20, 5:01 AM, "nikosi...@gmail.com" wrote: Needless to mention here that if you do an upgrade directly to 18.4 ignoring Juniper recommendations as someone has suggested if something goes wrong you are on your own. So I would never suggest this for a massive deployment. -Original Message- From: juniper-nsp On Behalf Of Mark Tinka Sent: Monday, June 15, 2020 9:28 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX80 upgrade path 18.4R On 14/Jun/20 19:16, nikosi...@gmail.com wrote: > It is true that the official path will tell you that you should follow > from > 15 to 16 then 17 then 18 but I did around 30+ upgrades from 16 to 18 > without any problems. > >From 10 to 15 I guess you should go to 14 first but from 16 you can > >safely > move to 18 without any issues. The ones I am talking about are > non-issue upgrades. If I have to ring up 2014 again, I think you can go from 10 to 14, then to 16. Once at 16, you should be able to skip all the way to current. But yoh, that MX80 will be slow! Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!VKUfiZ-UmWKaa3h03qaJHoRhCnBhJvbODKqMYyKkAFK8ijlWp8zvgq4VNAbVmNH3aQ$ Juniper Business Use Only --- End Message --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] what do do with bug reports
--- Begin Message --- For 100% sure you should open a JTAC Case, like P3, as you have a current workaround. JTAC should then reproduce your issue, at which time they will create a PR for Engg to work on. PR will be scheduled to be fixed in some future release. JTAC should be able to provide that feedback to you once Engg has updated the PR. Do NOT let JTAC close your case, until you get at least this far. Also make sure that JTAC ties your Case to the PR. Customer logged (CL) PRs have priority over Internal logged (IL) PRs. You should also now be able to view PR via external PR tool. You can then keep case open until you actually get a fix, or allow JTAC to close the case while you wait for the fix. Case would be 100% in monitor during this time. Case closure time is a top metric for TAC. If you do nothing, Juniper will also do nothing, as no one outside of you knows about this. If situation is known by Juniper (PR already open) your case can be tied to that PR, or new PR can be marked as a duplicate of older PR. FYI only, Rich Richard McGovern Sr Sales Engineer, Juniper Networks 978-618-3342 I’d rather be lucky than good, as I know I am not good I don’t make the news, I just report it On 6/15/20, 9:28 AM, "Jeffrey Haas" wrote: > On Jun 15, 2020, at 2:15 AM, Baldur Norddahl wrote: > > > What am I supposed to do with glaring bugs? Are Juniper interested in > knowing those or don't they care? Treat the following as "I do not speak for official Juniper support policy". It is to your benefit to open JTAC tickets on issues found. This means that when it becomes a Problem Report (PR) in the internal bug system, it's tagged with the impacted customers. Customers reporting issues will often change prioritization of how issues are dealt with vs. some random developer filing the PR. And it absolutely doesn't hurt if you note any PR# that's associated with an issue, if one gets back to you. It means that devs that are watching things with some knowledge of the issue may be able to add it to the report. -- Jeff Juniper Business Use Only --- End Message --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] what do do with bug reports
--- Begin Message --- > On Jun 15, 2020, at 2:15 AM, Baldur Norddahl wrote: > > > What am I supposed to do with glaring bugs? Are Juniper interested in > knowing those or don't they care? Treat the following as "I do not speak for official Juniper support policy". It is to your benefit to open JTAC tickets on issues found. This means that when it becomes a Problem Report (PR) in the internal bug system, it's tagged with the impacted customers. Customers reporting issues will often change prioritization of how issues are dealt with vs. some random developer filing the PR. And it absolutely doesn't hurt if you note any PR# that's associated with an issue, if one gets back to you. It means that devs that are watching things with some knowledge of the issue may be able to add it to the report. -- Jeff --- End Message --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 upgrade path 18.4R
Needless to mention here that if you do an upgrade directly to 18.4 ignoring Juniper recommendations as someone has suggested if something goes wrong you are on your own. So I would never suggest this for a massive deployment. -Original Message- From: juniper-nsp On Behalf Of Mark Tinka Sent: Monday, June 15, 2020 9:28 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX80 upgrade path 18.4R On 14/Jun/20 19:16, nikosi...@gmail.com wrote: > It is true that the official path will tell you that you should follow > from > 15 to 16 then 17 then 18 but I did around 30+ upgrades from 16 to 18 > without any problems. > >From 10 to 15 I guess you should go to 14 first but from 16 you can > >safely > move to 18 without any issues. The ones I am talking about are > non-issue upgrades. If I have to ring up 2014 again, I think you can go from 10 to 14, then to 16. Once at 16, you should be able to skip all the way to current. But yoh, that MX80 will be slow! Mark. ___ 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 upgrade path 18.4R
On 14/Jun/20 19:16, nikosi...@gmail.com wrote: > It is true that the official path will tell you that you should follow from > 15 to 16 then 17 then 18 but I did around 30+ upgrades from 16 to 18 without > any problems. > >From 10 to 15 I guess you should go to 14 first but from 16 you can safely > move to 18 without any issues. The ones I am talking about are non-issue > upgrades. If I have to ring up 2014 again, I think you can go from 10 to 14, then to 16. Once at 16, you should be able to skip all the way to current. But yoh, that MX80 will be slow! Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] what do do with bug reports
Hi, File a JTAC problem report, either yourself via a Juniper Partner (where you should have support for your devices). Rgds. Ola Thoresen On 15.06.2020 08:15, Baldur Norddahl wrote: Hello What am I supposed to do with glaring bugs? Are Juniper interested in knowing those or don't they care? In this case I found out that 19.1 behaves badly if you set [system services subscriber-management overrides interfaces family inet receive-gratuitous-arp]. The setting is supposed to enable updating the ARP table when receiving gratuitous ARP from clients. Instead it makes the router reply to those ARP packets, which causes the clients to reject the address. Packet monitor (somewhat shortened): 07:41:05.677882 bpf_flags 0x03, In Juniper PCAP Flags [no-L2, In] -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto: UDP (17), length: 319) 185.24.168.248.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:xx:xx:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto: UDP (17), length: 319) 185.24.168.248.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid 0x1b632c2a, Flags [Broadcast] (0x8000) Your-IP 212.237.x.237 DHCP-Message Option 53, length 1: ACK -original packet- 34:21:09:x:x:e1 > Broadcast, ethertype 802.1Q (0x8100), length 4294967292: vlan 301, p 0, ethertype 802.1Q, vlan 545, p 0, ethertype ARP, arp who-has 212.237.x.237 tell 212.237.x.237 07:41:05.686691 bpf_flags 0x00, Out -original packet- e6:5d:37:84:53:17 > 34:21:09:x:x:e1, ethertype ARP (0x0806), length 4294967292: arp reply 212.237.x.237 is-at e6:5d:37:84:53:17 07:41:05.689680 bpf_flags 0x03, In -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) DHCP-Message Option 53, length 1: Decline ^C 8 packets received by filter The part that is plain wrong is "arp reply 212.237.x.237 is-at e6:5d:37:84:53:17". NO! 212.237.x.237 is actually at 34:21:09:x:x:e1 and by responding to this, the router causes the client to believe something else is using the address. Therefore the client sends Decline back to the DHCP server. Proxy-arp settings makes no difference at all. Doesn't matter if you have it entirely disabled or set to proxy-arp restricted. However disabling receive-gratuitous-arp makes the router stop doing this. If I made a case for this I am sure they will just tell me to disable receive-gratuitous-arp which is exactly what I did. I am just curious if there is any way to report bugs that I will live with as is. It is still clearly something that should get fixed. Regards, Baldur ___ 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] what do do with bug reports
Hi Baldur, You should not give up and just report the bug. JTAC may ask you to disable feature that is causing an impact, but in the meantime they will work on resolving it. Mind that it might take some time to replicate the problem, prepare the fix and implement it in the next official software release. Regards, pon., 15 cze 2020, 08:23 użytkownik Baldur Norddahl napisał: > Hello > > What am I supposed to do with glaring bugs? Are Juniper interested in > knowing those or don't they care? > > In this case I found out that 19.1 behaves badly if you set [system > services subscriber-management overrides interfaces family inet > receive-gratuitous-arp]. The setting is supposed to enable updating the > ARP table when receiving gratuitous ARP from clients. Instead it makes > the router reply to those ARP packets, which causes the clients to > reject the address. > > Packet monitor (somewhat shortened): > > 07:41:05.677882 bpf_flags 0x03, In > Juniper PCAP Flags [no-L2, In] > -original packet- > PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags > [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from > 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) > -original packet- > PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags > [none], proto: UDP (17), length: 319) 185.24.168.248.bootps > > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid > 0x1b632c2a, Flags [Broadcast] (0x8000) > -original packet- > PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags > [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from > 34:21:09:xx:xx:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) > -original packet- > PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags > [none], proto: UDP (17), length: 319) 185.24.168.248.bootps > > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid > 0x1b632c2a, Flags [Broadcast] (0x8000) >Your-IP 212.237.x.237 > DHCP-Message Option 53, length 1: ACK > -original packet- > 34:21:09:x:x:e1 > Broadcast, ethertype 802.1Q (0x8100), length > 4294967292: vlan 301, p 0, ethertype 802.1Q, vlan 545, p 0, ethertype > ARP, arp who-has 212.237.x.237 tell 212.237.x.237 > 07:41:05.686691 bpf_flags 0x00, Out > -original packet- > e6:5d:37:84:53:17 > 34:21:09:x:x:e1, ethertype ARP (0x0806), length > 4294967292: arp reply 212.237.x.237 is-at e6:5d:37:84:53:17 > 07:41:05.689680 bpf_flags 0x03, In > -original packet- > PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags > [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from > 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) > DHCP-Message Option 53, length 1: Decline > ^C > 8 packets received by filter > > The part that is plain wrong is "arp reply 212.237.x.237 is-at > e6:5d:37:84:53:17". NO! 212.237.x.237 is actually at 34:21:09:x:x:e1 and > by responding to this, the router causes the client to believe something > else is using the address. Therefore the client sends Decline back to > the DHCP server. > > Proxy-arp settings makes no difference at all. Doesn't matter if you > have it entirely disabled or set to proxy-arp restricted. However > disabling receive-gratuitous-arp makes the router stop doing this. > > If I made a case for this I am sure they will just tell me to disable > receive-gratuitous-arp which is exactly what I did. I am just curious if > there is any way to report bugs that I will live with as is. It is still > clearly something that should get fixed. > > Regards, > > Baldur > > > > ___ > 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] what do do with bug reports
Hello What am I supposed to do with glaring bugs? Are Juniper interested in knowing those or don't they care? In this case I found out that 19.1 behaves badly if you set [system services subscriber-management overrides interfaces family inet receive-gratuitous-arp]. The setting is supposed to enable updating the ARP table when receiving gratuitous ARP from clients. Instead it makes the router reply to those ARP packets, which causes the clients to reject the address. Packet monitor (somewhat shortened): 07:41:05.677882 bpf_flags 0x03, In Juniper PCAP Flags [no-L2, In] -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto: UDP (17), length: 319) 185.24.168.248.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:xx:xx:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto: UDP (17), length: 319) 185.24.168.248.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid 0x1b632c2a, Flags [Broadcast] (0x8000) Your-IP 212.237.x.237 DHCP-Message Option 53, length 1: ACK -original packet- 34:21:09:x:x:e1 > Broadcast, ethertype 802.1Q (0x8100), length 4294967292: vlan 301, p 0, ethertype 802.1Q, vlan 545, p 0, ethertype ARP, arp who-has 212.237.x.237 tell 212.237.x.237 07:41:05.686691 bpf_flags 0x00, Out -original packet- e6:5d:37:84:53:17 > 34:21:09:x:x:e1, ethertype ARP (0x0806), length 4294967292: arp reply 212.237.x.237 is-at e6:5d:37:84:53:17 07:41:05.689680 bpf_flags 0x03, In -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) DHCP-Message Option 53, length 1: Decline ^C 8 packets received by filter The part that is plain wrong is "arp reply 212.237.x.237 is-at e6:5d:37:84:53:17". NO! 212.237.x.237 is actually at 34:21:09:x:x:e1 and by responding to this, the router causes the client to believe something else is using the address. Therefore the client sends Decline back to the DHCP server. Proxy-arp settings makes no difference at all. Doesn't matter if you have it entirely disabled or set to proxy-arp restricted. However disabling receive-gratuitous-arp makes the router stop doing this. If I made a case for this I am sure they will just tell me to disable receive-gratuitous-arp which is exactly what I did. I am just curious if there is any way to report bugs that I will live with as is. It is still clearly something that should get fixed. Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
