[j-nsp] what do do with bug reports

[Ola Thoresen]

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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp