Hey,
We've always advertised externally all our PAs. But the links were not
carried internally, so attack would be discarded at the edge.
However if customer demanded that their link can reach internet, we
would add /32 route for the CE end of the link. This would still not
add attack surface to
Do you mean the prefix that those PTP subnets were in was not advertised
globally?
So, those customers couldn’t use their side of the PTP link for internet’s?
My problem is I can easily iACL stuff for core interfaces and loopbacks
because I have moved that all to specific blocks but for PE-CE int
2018-03-09 15:48 GMT+01:00 :
>
> But I was actually referring to the very appealing idea you proposed in b) to
> not to even advertise the range -so the DDoS traffic would not even end up at
> your doorstep as simply the Internet would not have route for any of your p2p
> links.
this is really
> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Friday, March 09, 2018 2:39 PM
>
> On 9 March 2018 at 16:35, wrote:
>
>
> > Regarding point b)
> > That one might be cumbersome as IP for CE-PE links in the Internet VRF
> > are usually allocated from either your own public address space (so
> >
On 9 March 2018 at 16:35, wrote:
> Regarding point b)
> That one might be cumbersome as IP for CE-PE links in the Internet VRF are
> usually allocated from either your own public address space (so you'd have
> to fragment it and not advertising block used for PE-CE links -creating more
> state
> Of Roland Dobbins
> Sent: Friday, March 09, 2018 3:20 AM
>
>
> On 9 Mar 2018, at 3:35, Saku Ytti wrote:
>
> > a) have edgeACL which polices ICMP and UDP high ports to your links
> > and drops rest
> > b) don't advertise your links in IGP or iBGP
>
> This. iACL plus no link advertisement (ne
Hi,
On Fri, Mar 09, 2018 at 10:52:51AM +, James Bensley wrote:
> In addition to the above, try to avoid use public IPs on internal
> links if you can, they don't need to be reachable from the Internet
> and it saves on IPv4 address space :)
If you do so, ensure that ICMPs sent from these rout
On 8 March 2018 at 20:35, Saku Ytti wrote:
> Hey Daniel,
>
> Apologies for not answering your question, but generally this is not a
> problem, because:
>
> a) have edgeACL which polices ICMP and UDP high ports to your links
> and drops rest
> b) don't advertise your links in IGP or iBGP
>
>
>
> On
Hi,
yes - there's "advertise-inactive" option in BGP, which might help in
such case (in combination with FIB filters): "The advertise-inactive
statement causes Junos OS to advertise the best BGP route that is
inactive because of IGP preference."
You cannot modify preference of directly-connected n
On 9 Mar 2018, at 3:35, Saku Ytti wrote:
a) have edgeACL which polices ICMP and UDP high ports to your links
and drops rest
b) don't advertise your links in IGP or iBGP
This. iACL plus no link advertisement (need a sound addressing plan to
make both practical at scale).
Here's a link to a
Hey Daniel,
Apologies for not answering your question, but generally this is not a
problem, because:
a) have edgeACL which polices ICMP and UDP high ports to your links
and drops rest
b) don't advertise your links in IGP or iBGP
On 8 March 2018 at 22:17, Dan Římal wrote:
> Hi all,
>
> I would
Hi all,
I would like to discuss, how do you handle ddos attack pointing to IP address
of any router core interface, if your UPLINK/ISP support RTBH and you would
like to drop traffic at ISP level because of congested links.
I have tried to implement "classic" BGP signalized RTBH, via changing n
12 matches
Mail list logo