Sorry for the top post... Seems phone vendors haven't figured out how to create a decent email editor on a phone yet.
When I worked at Arbor, we always recommended that customers would front end anything maintaining state (i.e. a SFW) with something that didn't (i.e. a Router) and to use Stateless ACLs to allow through only that which was absolutely required in order to allow stateful devices further downstream to perform their duties more efficiently. Then customers buy something like a Juniper SRX in an attempt to collapse their network (routing & firewalling) and believe that they are now back to front ending everything with a stateful device. The beauty of the SRX device is that while it is a stateful device, traffic arriving on interfaces can still be processed by stateless FFs which get processed before handing it off to the the stateful FW module and consuming precious recources on the SPCs. So by all means, collapse your network if you need to, use a single box for routing and firewall if your design warrants it, but make sure you still use common sense and deploy it in a manner that is consistent with best current practices and will safeguard your network without itself becoming a bottleneck. Stefan Fouant GPG Key ID: 0xB4C956EC Sent from my HTC EVO. ----- Reply message ----- From: "joel jaeggli" <[email protected]> Date: Sat, Jun 23, 2012 12:39 am Subject: [j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere. To: "Morgan Mclean" <[email protected]> Cc: "[email protected]" <[email protected]> On 6/22/12 9:49 AM, Morgan Mclean wrote: > This is exactly what happened. The session table filled up. One of our > security guys took down our edge 650 cluster from a single unix box out on > the net. This is what happens when you use a stateful box for an internet router. a router with a covering aggreate and some knowledge of the more specifc on the interior would inexpensively discard traffic bound for unreachable destinations. > > Sent from my iPhone > > On Jun 22, 2012, at 4:39 AM, "Scott T. Cameron" <[email protected]> wrote: > >> On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean <[email protected]> wrote: >> >>> I have a /24 I want to announce, but I don't actually have it anywhere on >>> the network. I NAT some of its IP's on the SRX that has the BGP session >>> with our providers. >>> >>> I've been using static routes with the discard flag, but I don't really >>> like the way the SRX handles traffic. It still creates sessions for traffic >>> destined to IP's not used anywhere (hitting the static route) and can be >>> easily dos'd because of this. >>> >>> Is there a better way to just tell our providers hey, we have this range? >>> >>> >> It sounds like you're using the SRX as an edge router with a BGP session >> upstream? >> >> I don't have this architecture here, but I had the same problem. I had my >> edge router announce the /24 to the BGP upstreams, and my SRX announce the >> /24 via OSPF to the MX. >> >> Unfortunately, one of my IPs was hammered, and filled up the session table >> with invalid sessions. That's the real issue, at least in my case, was >> that even invalid sessions were taking a session, and prohibiting >> legitimate traffic from flowing. >> >> The solution was only to announce from SRX to MX (edge router) the /32s >> that were actually in use. >> >> I suppose that a firewall filter may help on your ingress ports to only >> permit the traffic to the /32s that are actually in use, but I can't say >> from experience if this will happen before a session is created, even in >> invalid state. >> >> Scott >> _______________________________________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
