Re: [j-nsp] punting base address packets to RE
All- I realize I may have made some mistakes in my claim based on a misunderstanding of output. My normal final term in my lo0.0 input filter is 'then count $X; then discard'. I added a 'then log' while doing a root cause analysis of why I was seeing a large increase in counter $X. I made the assumption packets were actually hitting the RE because of the log, but this is likely false. I have since found KB9262 [http://kb.juniper.net/InfoCenter/index?page=content&id=KB9262], and from the router in question I derived the following statistics.. [...] $-re0> show pfe statistics traffic [...] Packet Forwarding Engine hardware discard statistics: Timeout:0 Truncated key :0 Bits to test :0 Data error :0 Stack underflow:0 Stack overflow :0 Normal discard :674569675 <-- Extended discard :0 <-- Invalid interface :0 Info cell drops:0 Fabric drops :0 >From the KB: " The normal discard counter, in the show pfe statistics traffic output, reports the number of packets (notifications) that are silently discarded at packet forwarding engine level, without being further processed by the host (CPU on the System Board or on the Routing Engine) ... The extended discard counter, in the show pfe statistics traffic output, reports the number of packets (notifications) that are silently discarded but that also need to be sent to the host (Routing Engine) in order to be further processed. " So trying again, I would expect a non zero 'extended discard' counter if these base address packets were actually being punted. Also recall I noted I didn't see these in my time series ddos-protection collections, which should have been a red flag I was making the wrong assumption. I'll verify in the lab at some point by blasting several Ks of base packets at the RE. Saku, thanks for your second set of eyes, -Michael > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Saku Ytti > Sent: Wednesday, August 26, 2015 10:11 AM > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] punting base address packets to RE > > On (2015-08-25 08:46 -0400), Frank Sweetser wrote: > > Hey, > > > > > If I recall correctly, the base address of a subnet was originally used as > > an alternative broadcast address by some ancient equipment. While it's not > > a behavior I'd expect to see actively used in modern equipment, seeing it > > handled as a special case as a receiver doesn't surprise me. > > > > Based on this, it looks like it's handled as a directed broadcast: > > > > https://www.juniper.net/techpubs/en_US/junose10.3/information- > products/topic-collections/swconfig-ip-ipv6/id-25742.html > > OP said they were punted, not forwarded to LAN. If they behaved by default as > if 'directed-broadcast' is enabled, it would be rather serious amplification > problem. > > Directed-broadcast toggle permits the behaviour of flooding WAN arriving > packet as L2 bcast to LAN. > Typical use case is sending WOL packets over routed internet to LAN. > > -- > ++ytti > ___ > 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] punting base address packets to RE
On (2015-08-25 08:46 -0400), Frank Sweetser wrote: Hey, > > If I recall correctly, the base address of a subnet was originally used as > an alternative broadcast address by some ancient equipment. While it's not > a behavior I'd expect to see actively used in modern equipment, seeing it > handled as a special case as a receiver doesn't surprise me. > > Based on this, it looks like it's handled as a directed broadcast: > > https://www.juniper.net/techpubs/en_US/junose10.3/information-products/topic-collections/swconfig-ip-ipv6/id-25742.html OP said they were punted, not forwarded to LAN. If they behaved by default as if 'directed-broadcast' is enabled, it would be rather serious amplification problem. Directed-broadcast toggle permits the behaviour of flooding WAN arriving packet as L2 bcast to LAN. Typical use case is sending WOL packets over routed internet to LAN. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] punting base address packets to RE
If I recall correctly, the base address of a subnet was originally used as an alternative broadcast address by some ancient equipment. While it's not a behavior I'd expect to see actively used in modern equipment, seeing it handled as a special case as a receiver doesn't surprise me. Based on this, it looks like it's handled as a directed broadcast: https://www.juniper.net/techpubs/en_US/junose10.3/information-products/topic-collections/swconfig-ip-ipv6/id-25742.html Frank Sweetser fs at wpi.edu| For every problem, there is a solution that Manager of Network Operations | is simple, elegant, and wrong. Worcester Polytechnic Institute | - HL Mencken On 08/25/2015 05:45 AM, Saku Ytti wrote: On (2015-08-24 18:38 +), Michael Hare wrote: Hey, Sorry if this is remedial, but are packets sent to the base address of a directly connected subnet always punted to RE and if so, why? Historic compatibility? I couldn't determine any bucket under the ddos-protection protocol statistics such traffic ends up in, either. I haven't seen any negative side effects of this, only noticing this after I followed up on a high pps drop rate for one of our routing engines. This seems to happen regardless of what I have 'targeted-broadcast' configured with [absent, forward-only]. Terrific question, I don't know, I don't think there is any real reason why those need to be punted. It's probably something people have done in their IP implementation and it has just carried over in fear of changing the behaviour might break something, and almost certainly someone now relies on this behaviour for what ever strange reasons. Pretty sure you'll see them in ddos-protection in what ever protocol the traffic is, ddos-protection would not care about your DADDR, because decision to punt was done before ddos-protection got the frame. For what it's worth, the above is an MX104, but I also see this on other MX MPC hardware. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] punting base address packets to RE
On (2015-08-24 18:38 +), Michael Hare wrote: Hey, > Sorry if this is remedial, but are packets sent to the base address of a > directly connected subnet always punted to RE and if so, why? Historic > compatibility? I couldn't determine any bucket under the ddos-protection > protocol statistics such traffic ends up in, either. I haven't seen any > negative side effects of this, only noticing this after I followed up on a > high pps drop rate for one of our routing engines. This seems to happen > regardless of what I have 'targeted-broadcast' configured with [absent, > forward-only]. Terrific question, I don't know, I don't think there is any real reason why those need to be punted. It's probably something people have done in their IP implementation and it has just carried over in fear of changing the behaviour might break something, and almost certainly someone now relies on this behaviour for what ever strange reasons. Pretty sure you'll see them in ddos-protection in what ever protocol the traffic is, ddos-protection would not care about your DADDR, because decision to punt was done before ddos-protection got the frame. > For what it's worth, the above is an MX104, but I also see this on other MX > MPC hardware. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] punting base address packets to RE
Hello- Sorry if this is remedial, but are packets sent to the base address of a directly connected subnet always punted to RE and if so, why? Historic compatibility? I couldn't determine any bucket under the ddos-protection protocol statistics such traffic ends up in, either. I haven't seen any negative side effects of this, only noticing this after I followed up on a high pps drop rate for one of our routing engines. This seems to happen regardless of what I have 'targeted-broadcast' configured with [absent, forward-only]. For example, in below I ran "telnet X.Y.0.0 16888" and "telnet X.Y.0.0 5" from A.B.254.29, resulting in the firewall logs as follows. Time of Log: 2015-08-24 12:53:38 CDT, Filter: pfe, Filter action: discard, Name of interface: ae1.3416 Name of protocol: TCP, Packet Length: 52, Source address: A.B.254.29:34776, Destination address: X.Y.0.0:16888 Time of Log: 2015-08-24 12:57:17 CDT, Filter: pfe, Filter action: discard, Name of interface: ae1.3416 Name of protocol: TCP, Packet Length: 52, Source address: A.B.254.29:31968, Destination address: X.Y.0.0:5 I have a 'then log' at the bottom of my protect-re filter in lo0.0 family inet. As you can see X.Y.0.0/21 is directly connected on the given chassis, but the local address is not the X.Y.0.0/32 address. # run show route X.Y.0.0 table inet.0 inet.0: 396 destinations, 417 routes (395 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both X.Y.0.0/21 *[Direct/0] 39w3d 18:24:03 > via irb.157 For what it's worth, the above is an MX104, but I also see this on other MX MPC hardware. -Michael ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
