At 10:30 AM -0500 5/6/02, Tarek Sabry wrote: >Howard > >I did look at GateD from NextHop before, but they are prohibitively >expensive. That's why I was leaning more towards IPInfusion. Now the problem >with the latter is that I don't know how dependable or field-proven they >are.
Well, I can't speak to direct experience with IPinfusion, only Zebra. We ran our BGP convergence tester on Zebra running on Linux, and it certainly interoperated with Cisco routers. We were using it as a load generator, a load receiver, and sometimes as a router under test. We were able to make some modifications fairly easily to be able to tie its timestamps to a precision hardware clock. There were some oddities in the way in which it would handle BGP updates when we'd want to send a more- and -less specific version of an address block. Sometimes it would just send one rather than both. You may get performance difference in convergence, which again is something we are actively defining in the IETF work. Specifically, different router implementations differ in the order they send out a BGP update. Some will send out the least specific and then all more specifics under it in that order, where others will send all /8, then all /9, etc. Depending on the internal Loc-RIB and RIB storage models of the receiving implementation, convergence time can vary significantly based on the order of sending. There is no standard way of doing this. > >I totally agree with you about butting BGP on a firewall. There are many >reason why one should not use a combination firewall/router. However, I am >not doing any tunnels in this case. I am in a situation where I need to >terminate eBGP sessions for MPLS VPN endpoints in numerous locations around >the world. > >I'm not sure I understand your statement about "having an external router >gives [you] better hardware protection against DoS attacks, and also avoids >conduit problems for >encrypted protocols not supported on the firewall". Assume someone is smurfing, doing an ICMP flood, or other fairly low-level attacks. A router can filter or otherwise stop these using much more specialized hardware than the firewall platform, so it's cheaper per attack packet to stop it only on the firewall. >Yes I thought it would only run on BSD. In fact I did use GateD in a >manufactruing environment over FreeBSD. However, to my surprise, ZebOS runs >on Sun Solaris too. As mentioned, we ran it on LINUX. >I am running a demo license right now on Solaris with >CheckPoint as a firewall. Things seem good, except for the fact that I have >a problem with performance testing. Any ideas for testing firewalls? Any >good tools? Here's the standardization work at least on terminology: http://www.ietf.org/rfc/rfc2647.txt > >I also agree with you that maybe we shouldn't expect using the object code >right out of the box and that having a CLI that looks like IOS is no >guarantee for 100% compatibility. But again for the past week I was >surprised about the high degree of compatibility and resemblence to Cisco to >the extent that I started forgetting that I'm configuring a Unix box!! My current use is a little different -- I'm using both Zebra and BGPsim to generate test routes, including routes with deliberate errors, or that are flapping. > >Thank you very much for your insightful thoughts. >Tarek > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of >Howard C. Berkowitz >Sent: Monday, May 06, 2002 5:27 AM >To: [EMAIL PROTECTED] >Subject: Re: Dynamic Routing on Firewalls - ZebOS [7:43373] > > >At 1:22 AM -0400 5/6/02, Tarek Sabry wrote: >>Hi everyone >> >>I was wondering if anyone here ever had experience/expoure to a situation >>where you needed to run something like BGP on a firewall (PIX or > >CheckPoint). Are there any alternatives in addition to Zebra? I know >there's >>some shareware and freeware but I'm interested in commercial, field-proven >>and supported products. >> >>If not then can anyone evaluate ZebOS for me or tell me if they know any >>organizations using it? The real nice thing about it is that it has a Cisco >>IOS interface, which is AWESOME! But my boss still needs some vendor >>verification before we include Zebra in any MPLS/VPN designs. >> >>Thanks a lot >>Tarek > >First, to answer your question directly, the same people that >developed Zebra also have a commercial, supported version called >IPinfusion (www.ipinfusion.com). > >The other alternative is commercial GateD from NextHop Technologies >(www.nexthop.com). Native GateD command language is more Juniper- >than Cisco-like, but there are ways to get much more Cisco like. >Check with NextHop for details; I honestly don't remember which of >the details are under NDA. There's a good deal more operational >experience with GateD than IPinfusion. > >That being said, butting BGP on a firewall, IMNSHO, is a BAD idea. >One of the basic ideas of firewalls is to put the minimal >functionality on them that is necessary for the security function. >Best practice is to front-end the firewall with routers, even >splitting them into BGP and router-based security functions. >Performance optimizations are different for routing and firewall >platforms. Also, having an external router gives you better hardware >protection against DoS attacks, and also avoids conduit problems for >encrypted protocols not supported on the firewall. > >It's perfectly plausible, depending on your requirements, to have an >external BGP router function that feeds a stateful firewall, an SSH >or IPsec proxy, and another router function that passes encrypted >tunnels. Three or four distinct functions, depending on whether you >separate the router functions into different boxes. Some firewalls >also may include an SSH or IPsec proxy. > >Neither IPinfusion nor GateD actually do the forwarding; they are >routing protocol and RIB implementations. They rely on the underlying >operating system and hardware for forwarding, generally expecting >some flavor of UNIX (most commonly NetBSD, FreeBSD, and lately >Linux). Having actually worked with these packages, I don't think >you'd have a hope of integrating them unless you had access to the >source code of the firewall. > >These routing software packages are really meant for manufacturers, >not end users. I've worked with both in that context. > >Incidentally, don't take the assertion that a non-IOS routing package >that claims to have CLI is fully compatible. Think about it. If it's >not just a front end to IOS but an independent package, how can it >have features that depend on Cisco software and hardware >implementation? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=43402&t=43373 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
