Considered j-nsp, but this just feels more nanog appropriate. I'm told by one of my NSPs that I'm connected to a juniper. We were dealing with a DOS, and for some reason remote triggered DOS prevention via BGP wasn't working. The NOC said they had to enable multihop to my peering to make it work, otherwise it wouldn't accept the route. This seems strange to me. Any idea why a route would be rejected unless multihop was enabled? Also, any idea why a Juniper couldn't handle a simple 750mbit/s, 1.5Mpps DOS? Don't get me wrong, it could have been more than that. I was just receiving that much of the DOS and my lower end m120 didn't seem to think it an issue, so I'm curious why I was dropping packets on the link to begin with. Interestingly, I have an OC-12 to another NSP who was also dropping after around 1.2Mpps (last time I asked, they said the oc-12 hit a cisco 7600). Jack
Enabling BGP multi-hop is a very common approach with DDoS Mitigation services and also variations of Remote-Triggered Black Holes where the discard route isn't localized on the edge router. This is not because the customer router will be greater than one hop away, but because enabling multi-hop has an additional side effect of disabling next-hop validation. Without this enabled, the edge router will invalidate the “mitigate” routes received from the customer because the next-hop is not directly reachable via the neighbor. Not sure about the PPS limitations... The PFE ASICs should be able to handle a 750Mbps / 1.5 Mpps DoS pretty easy... HTHs. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Oct 22, 2011, at 9:38 PM, Jack Bates <jbates@brightok.net> wrote:
Considered j-nsp, but this just feels more nanog appropriate.
I'm told by one of my NSPs that I'm connected to a juniper. We were dealing with a DOS, and for some reason remote triggered DOS prevention via BGP wasn't working. The NOC said they had to enable multihop to my peering to make it work, otherwise it wouldn't accept the route. This seems strange to me. Any idea why a route would be rejected unless multihop was enabled?
Also, any idea why a Juniper couldn't handle a simple 750mbit/s, 1.5Mpps DOS? Don't get me wrong, it could have been more than that. I was just receiving that much of the DOS and my lower end m120 didn't seem to think it an issue, so I'm curious why I was dropping packets on the link to begin with. Interestingly, I have an OC-12 to another NSP who was also dropping after around 1.2Mpps (last time I asked, they said the oc-12 hit a cisco 7600).
Jack
On 10/22/2011 10:14 PM, Stefan Fouant wrote:
Enabling BGP multi-hop is a very common approach with DDoS Mitigation services and also variations of Remote-Triggered Black Holes where the discard route isn't localized on the edge router. This is not because the customer router will be greater than one hop away, but because enabling multi-hop has an additional side effect of disabling next-hop validation. Without this enabled, the edge router will invalidate the “mitigate” routes received from the customer because the next-hop is not directly reachable via the neighbor. yeah, I didn't think of that side effect, probably because I don't modify next-hops myself.
Not sure about the PPS limitations... The PFE ASICs should be able to handle a 750Mbps / 1.5 Mpps DoS pretty easy...
That's what I'm thinking. My m120 shows 0 problems with the load, but 2 of my transits dropped packets to me without saturating their respective links. I expected more out of NSPs. Jack
On Sat, Oct 22, 2011 at 11:26 PM, Jack Bates <jbates@brightok.net> wrote:
On 10/22/2011 10:14 PM, Stefan Fouant wrote:
Not sure about the PPS limitations... The PFE ASICs should be able to handle a 750Mbps / 1.5 Mpps DoS pretty easy...
That's what I'm thinking. My m120 shows 0 problems with the load, but 2 of my transits dropped packets to me without saturating their respective links. I expected more out of NSPs.
if someone has you on an older oc-12 LC ... say the 4x oc12 ... that doesnt like high pps rates :(
On (2011-10-22 20:38 -0500), Jack Bates wrote:
the route. This seems strange to me. Any idea why a route would be rejected unless multihop was enabled?
RFC4271 states: -- - By default (if none of the above conditions apply), the BGP speaker SHOULD use the IP address of the interface that the speaker uses to establish the BGP connection to peer X in the NEXT_HOP attribute. -- Your provider was rewriting the next-hop to some address they are blackholing inside their network. This caused above check to fail, and route was being considered invalid. EBGP multihop is kludge to kill this check, but also kludge to kill convergence of your BGP session, due to disabling fall over on linkdown. Proper way to disable this check is JunOS 'accept-remote-nexthop' or IOS 'disable-connected-check'. -- ++ytti
On 10/23/2011 2:18 AM, Saku Ytti wrote:
EBGP multihop is kludge to kill this check, but also kludge to kill convergence of your BGP session, due to disabling This is what I was worried about.
fall over on linkdown. Proper way to disable this check is JunOS 'accept-remote-nexthop' or IOS 'disable-connected-check'.
Thanks. I'll have them fix it proper then. Jack
participants (4)
-
Christopher Morrow -
Jack Bates -
Saku Ytti -
Stefan Fouant