Hey, > And there don't seem to be a way in Junos how to restrict management-plane > protocols only to certain interfaces no matter what RE filter says. > In XR it's as easy as specifying a list of OOB or in-band interfaces against > a list of management protocols,
In practical life IOS-XR control-plane is better protected than JunOS, as configuring JunOS securely is very involved, considering that MX book gets it wrong, offering horrible lo0 filter as does Cymru, what chance the rest of us have? But IOS-XR also cannot be configured very securely, JunOS can. Main problems in IOS-XR: a) Policers are per protocol, one BGP customer having L2 loop, and all BGP customers in NPU suffer (excessive flow trap may alleviate, but it's not turn-key and it can be configured perfectly) b) LPTS packets are not subject to MQC, so you cannot complement LPTS with MQC. Imagine one customer congesting specific LPTS policer, and you want to add MQC policer to interface, to relieve the LPTS policer from trash generated by this customer, not possible c) IOS-XR does not guarantee that packets not dropped by LPTS are not dropped later, JunOS technically does not, but in practice it's extremely rare to drop packets once punted from NPU. After LPTS punt, TCP packets are hashed to 8 TCP workers, in lab situation single TCP worker can handle lot more than what single NPU LPTS protocol policer can admit, but in production environment TCP worker performance may degrade so much that your XIPC workers are dropping before there are any LPTS drops, meaning you'll lose 1/8th of your BGP sessions. Both A and C are being fixed, thanks CSCO. But I'm not very happy how they chose to fix it. I think best compromise would be, that JNPR would offer good filter, dynamically built based on data available in config and referring to empty prefix-lists when not possible to infer and customer can fill those prefix-lists if needed. And also have functional ddos-protection configuration out-of-the-box. People who want and can could override and configure themselves. Of course this cannot happen, because you can't just randomly kill people new breaking default configs. Which is another issue I think vendors should address, so that they could evolve out-of-the-box defaults over time. I think this would be quite easily solvable, if in configurations you could declare which standards version you want to use, and if nothing is declared, it'll use what ever standard the image defaults to. This way Juniper could keep introducing new standard config versions, and people could choose to stay in any specific standard version as long as they want. Keeping backward compatibility while allowing more sensible defaults. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp