BrazilFW 2.27.4 Released [INACTIVE]

News and Announcements.

BrazilFW 2.27.4 Released

Mensagempor Claudio » Qui Abr 20, 2006 8:08 pm

BrazilFW 2.27.4 is available to download here:
http://www.brazilfw.com.br/downloads

Windows Wizard - Fixed incompatibility with Symantec antivirus
Improvement - New checking for inconsistent INTERNET/LAN/DMZ IP addresses.
Não dou suporte via mensagem privada e e-mail.
Por favor, não insista.
Avatar do usuário
Claudio
BFW Founder
BFW Beneméritos
 
Mensagens: 7553
Registrado em: Qui Ago 25, 2005 9:10 am
Localização: Vitória - ES - Brasil
BrazilFW Box:

Mensagempor Hamski » Sex Abr 21, 2006 7:08 am

http://klan.xa.pl/br.jpg

BUG ? Program is not creating my bfw disk
Hamski
 

Mensagempor Claudio » Sex Abr 21, 2006 1:48 pm

I detected a problem with windows 98, please try this one:

http://www.brazilfw.com.br/downloads/test/BrazilFW.exe




(ps: Nice wallpaper!!!)
Não dou suporte via mensagem privada e e-mail.
Por favor, não insista.
Avatar do usuário
Claudio
BFW Founder
BFW Beneméritos
 
Mensagens: 7553
Registrado em: Qui Ago 25, 2005 9:10 am
Localização: Vitória - ES - Brasil
BrazilFW Box:

Mensagempor Hamski » Sex Abr 21, 2006 2:11 pm

Thanks!

If you want i may send you this wallaper :]
Hamski
 

Mensagempor Hamski » Sex Abr 21, 2006 3:34 pm

IP Addresses ERROR [ Test ]

A push test buton

Checking if you are connected to the Internet [OK]
Checking if your Gateway is responding [OK]
Checking if your DNS is working [OK]
Checking if Gateway Address is in Internet network [OK]
Checking if Local IP is not in Internet network [OK]
Checking if Internet IP is not in Local network [OK]
Checking if Local IP follows Internal IP Standards [FAIL]

Hmmmmmm ? :]
Hamski
 

Mensagempor Claudio » Sex Abr 21, 2006 4:05 pm

According to the IP standards your internal network addresses should be 10.x.x.x, 172.x.x.x or 192.168.x.x.
What is your internal ip address?
Não dou suporte via mensagem privada e e-mail.
Por favor, não insista.
Avatar do usuário
Claudio
BFW Founder
BFW Beneméritos
 
Mensagens: 7553
Registrado em: Qui Ago 25, 2005 9:10 am
Localização: Vitória - ES - Brasil
BrazilFW Box:

Mensagempor Claudio » Sex Abr 21, 2006 6:25 pm

I posted the file again due the problems with Windows 98.

It's now called brazilfw-2.27.4b-windows.zip

This is not a release, the system is just the same only the wizard was changed.
Não dou suporte via mensagem privada e e-mail.
Por favor, não insista.
Avatar do usuário
Claudio
BFW Founder
BFW Beneméritos
 
Mensagens: 7553
Registrado em: Qui Ago 25, 2005 9:10 am
Localização: Vitória - ES - Brasil
BrazilFW Box:

Mensagempor lambition » Sex Abr 21, 2006 8:53 pm

This fixed my problem :aplause:

Thanks~ :D
lambition
 

Mensagempor nachazo » Sáb Abr 22, 2006 1:29 am

what improvement did you do to brazilfw 2.27.4?

thanks.
nachazo
 

Mensagempor Claudio » Sáb Abr 22, 2006 10:25 am

Just a few bug fixes. Mainly the windows wizard.

2.27 is almost stable right now. I guess this would be the last testing release before we launch it as 2.28.
If you have a working 2.27.x you do not need to upgrade.

Surely we need a lot of improvements in several resources (ebtables, wireless, connlimit, load balancing) but they will be treated by the 2.29.x series.
Não dou suporte via mensagem privada e e-mail.
Por favor, não insista.
Avatar do usuário
Claudio
BFW Founder
BFW Beneméritos
 
Mensagens: 7553
Registrado em: Qui Ago 25, 2005 9:10 am
Localização: Vitória - ES - Brasil
BrazilFW Box:

Mensagempor Hamski » Sáb Abr 22, 2006 11:16 am

Claudio escreveu:According to the IP standards your internal network addresses should be 10.x.x.x, 172.x.x.x or 192.168.x.x.
What is your internal ip address?


Local IP Address 11.11.11.252
Netmask 255.255.255.0
Broadcast 11.11.11.255
Hamski
 

Mensagempor Claudio » Sáb Abr 22, 2006 11:35 am

That's it.
An ip started by 11.x.x.x should not be used as an internal ip as it could be used for someone out there.
Não dou suporte via mensagem privada e e-mail.
Por favor, não insista.
Avatar do usuário
Claudio
BFW Founder
BFW Beneméritos
 
Mensagens: 7553
Registrado em: Qui Ago 25, 2005 9:10 am
Localização: Vitória - ES - Brasil
BrazilFW Box:

Mensagempor nachazo » Sáb Abr 22, 2006 6:42 pm

Claudio escreveu:Just a few bug fixes. Mainly the windows wizard.

2.27 is almost stable right now. I guess this would be the last testing release before we launch it as 2.28.
If you have a working 2.27.x you do not need to upgrade.

Surely we need a lot of improvements in several resources (ebtables, wireless, connlimit, load balancing) but they will be treated by the 2.29.x series.


claudio have a question... right now don´t know how can i take the package conlimit....

because i think that it will be very useful if i mix conlimit with a qos script...

if i leave alone conlimit it will be restricted to a tiny area... but if i mix with qos it´s become in a very powerful script...

what can you suggest to me?


please don´t tell me that you don´t know, just say to me what do you will do if conlimit if was your package not mine...

the qos script is in beta... but has this features:

simple classes an filtered classes...

l7filter support

configurable priorities of classes and sub classes.

configurable speeds of subclasses...

configurable subclasses with global and individual options on ports or l7filter...

conlimit and TOS featured incorporated...

regards..






regards.
nachazo
 

brazil 2.27.4 ERROR??????????????????????

Mensagempor gamer » Seg Abr 24, 2006 6:23 am

http://www.gamer123.atw.hu

What is ERROR????????????????????????????????????????????????????????????????????????????????????????
gamer
 

Re: brazil 2.27.4 ERROR??????????????????????

Mensagempor Hamski » Seg Abr 24, 2006 10:47 am

gamer escreveu:http://www.gamer123.atw.hu

What is ERROR????????????????????????????????????????????????????????????????????????????????????????


Claudio escreveu:That's it.
An ip started by 11.x.x.x should not be used as an internal ip as it could be used for someone out there.


I got this same problem but everything works fine
Hamski
 

Mensagempor Claudio » Ter Abr 25, 2006 8:30 am

What is ERROR????????????????????????????????????????????????????????????????????????????????????????


To see the error you should click the "test" link.
Não dou suporte via mensagem privada e e-mail.
Por favor, não insista.
Avatar do usuário
Claudio
BFW Founder
BFW Beneméritos
 
Mensagens: 7553
Registrado em: Qui Ago 25, 2005 9:10 am
Localização: Vitória - ES - Brasil
BrazilFW Box:

Mensagempor Ebi » Ter Abr 25, 2006 9:37 am

My brazil says error too, but all works fine.

Checking if you are connected to the Internet [OK]
Checking if your Gateway is responding [FAIL]
Checking if your DNS is working [OK]
ipcalc: bad IP address: Error
Checking if Local IP is not in Internet network [FAIL]
Checking if Internet IP is not in Local network [OK]
Checking if Local IP follows Internal IP Standards [OK]
ipcalc: bad IP address: Error
Checking if DMZ IP is not in Internet network [FAIL]
Checking if Internet IP is not in DMZ network [OK]
Checking if DMZ IP is not in Local network [OK]
Checking if Local IP is not in DMZ network [OK]
Checking if DMZ IP follows Internal IP Standards [OK]


Lan IP: 192.168.0.1
Netmask: 255.255.255.0
Broadcast: 192.168.0.255

DMZ IP: 192.168.1.1
Netmask: 255.255.255.0
Broadcast: 192.168.1.255

WAN IP: 217.227.231.xxx

Whats wrong??
Ebi
 

Mensagempor Claudio » Ter Abr 25, 2006 1:35 pm

Nothing.
Some of these tests should be disabled for pppoe users. I'm going to fix them.
Não dou suporte via mensagem privada e e-mail.
Por favor, não insista.
Avatar do usuário
Claudio
BFW Founder
BFW Beneméritos
 
Mensagens: 7553
Registrado em: Qui Ago 25, 2005 9:10 am
Localização: Vitória - ES - Brasil
BrazilFW Box:

Mensagempor Taag Man » Qua Abr 26, 2006 5:45 pm

Claudio escreveu:According to the IP standards your internal network addresses should be 10.x.x.x, 172.x.x.x or 192.168.x.x.
What is your internal ip address?


Nope, that ain't true. In IPv4 all of these are reserved for private networking:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

I have a Cisco CCNA1 Certificat, so i should know :lol:
Taag Man
 

Mensagempor kania » Qua Abr 26, 2006 8:12 pm

Taag Man escreveu:I have a Cisco CCNA1 Certificat, so i should know


You should know and you remember it properly ;)

http://www.ietf.org/rfc/rfc1918.txt
kania
 

Mensagempor Marcelo - Brazil » Qui Abr 27, 2006 4:14 pm

Full txt from http://www.ietf.org/rfc/rfc1918.txt

Network Working Group Y. Rekhter
Request for Comments: 1918 Cisco Systems
Obsoletes: 1627, 1597 B. Moskowitz
BCP: 5 Chrysler Corp.
Category: Best Current Practice D. Karrenberg
RIPE NCC
G. J. de Groot
RIPE NCC
E. Lear
Silicon Graphics, Inc.
February 1996


Address Allocation for Private Internets

Status of this Memo

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.

1. Introduction

For the purposes of this document, an enterprise is an entity
autonomously operating a network using TCP/IP and in particular
determining the addressing plan and address assignments within that
network.

This document describes address allocation for private internets. The
allocation permits full network layer connectivity among all hosts
inside an enterprise as well as among all public hosts of different
enterprises. The cost of using private internet address space is the
potentially costly effort to renumber hosts and networks between
public and private.

2. Motivation

With the proliferation of TCP/IP technology worldwide, including
outside the Internet itself, an increasing number of non-connected
enterprises use this technology and its addressing capabilities for
sole intra-enterprise communications, without any intention to ever
directly connect to other enterprises or the Internet itself.

The Internet has grown beyond anyone's expectations. Sustained
exponential growth continues to introduce new challenges. One
challenge is a concern within the community that globally unique
address space will be exhausted. A separate and far more pressing
concern is that the amount of routing overhead will grow beyond the



Rekhter, et al Best Current Practice [Page 1]

RFC 1918 Address Allocation for Private Internets February 1996


capabilities of Internet Service Providers. Efforts are in progress
within the community to find long term solutions to both of these
problems. Meanwhile it is necessary to revisit address allocation
procedures, and their impact on the Internet routing system.

To contain growth of routing overhead, an Internet Provider obtains a
block of address space from an address registry, and then assigns to
its customers addresses from within that block based on each customer
requirement. The result of this process is that routes to many
customers will be aggregated together, and will appear to other
providers as a single route [RFC1518], [RFC1519]. In order for route
aggregation to be effective, Internet providers encourage customers
joining their network to use the provider's block, and thus renumber
their computers. Such encouragement may become a requirement in the
future.

With the current size of the Internet and its growth rate it is no
longer realistic to assume that by virtue of acquiring globally
unique IP addresses out of an Internet registry an organization that
acquires such addresses would have Internet-wide IP connectivity once
the organization gets connected to the Internet. To the contrary, it
is quite likely that when the organization would connect to the
Internet to achieve Internet-wide IP connectivity the organization
would need to change IP addresses (renumber) all of its public hosts
(hosts that require Internet-wide IP connectivity), regardless of
whether the addresses used by the organization initially were
globally unique or not.

It has been typical to assign globally unique addresses to all hosts
that use TCP/IP. In order to extend the life of the IPv4 address
space, address registries are requiring more justification than ever
before, making it harder for organizations to acquire additional
address space [RFC1466].

Hosts within enterprises that use IP can be partitioned into three
categories:

Category 1: hosts that do not require access to hosts in other
enterprises or the Internet at large; hosts within
this category may use IP addresses that are
unambiguous within an enterprise, but may be
ambiguous between enterprises.

Category 2: hosts that need access to a limited set of outside
services (e.g., E-mail, FTP, netnews, remote login)
which can be handled by mediating gateways (e.g.,
application layer gateways). For many hosts in this
category an unrestricted external access (provided



Rekhter, et al Best Current Practice [Page 2]

RFC 1918 Address Allocation for Private Internets February 1996


via IP connectivity) may be unnecessary and even
undesirable for privacy/security reasons. Just like
hosts within the first category, such hosts may use
IP addresses that are unambiguous within an
enterprise, but may be ambiguous between
enterprises.

Category 3: hosts that need network layer access outside the
enterprise (provided via IP connectivity); hosts in
the last category require IP addresses that are
globally unambiguous.

We will refer to the hosts in the first and second categories as
"private". We will refer to the hosts in the third category as
"public".

Many applications require connectivity only within one enterprise and
do not need external (outside the enterprise) connectivity for the
majority of internal hosts. In larger enterprises it is often easy to
identify a substantial number of hosts using TCP/IP that do not need
network layer connectivity outside the enterprise.

Some examples, where external connectivity might not be required,
are:

- A large airport which has its arrival/departure displays
individually addressable via TCP/IP. It is very unlikely
that these displays need to be directly accessible from
other networks.

- Large organizations like banks and retail chains are
switching to TCP/IP for their internal communication. Large
numbers of local workstations like cash registers, money
machines, and equipment at clerical positions rarely need
to have such connectivity.

- For security reasons, many enterprises use application
layer gateways to connect their internal network to the
Internet. The internal network usually does not have
direct access to the Internet, thus only one or more
gateways are visible from the Internet. In this case, the
internal network can use non-unique IP network numbers.

- Interfaces of routers on an internal network usually do not
need to be directly accessible from outside the enterprise.






Rekhter, et al Best Current Practice [Page 3]

RFC 1918 Address Allocation for Private Internets February 1996


3. Private Address Space

The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

We will refer to the first block as "24-bit block", the second as
"20-bit block", and to the third as "16-bit" block. Note that (in
pre-CIDR notation) the first block is nothing but a single class A
network number, while the second block is a set of 16 contiguous
class B network numbers, and third block is a set of 256 contiguous
class C network numbers.

An enterprise that decides to use IP addresses out of the address
space defined in this document can do so without any coordination
with IANA or an Internet registry. The address space can thus be used
by many enterprises. Addresses within this private address space will
only be unique within the enterprise, or the set of enterprises which
choose to cooperate over this space so they may communicate with each
other in their own private internet.

As before, any enterprise that needs globally unique address space is
required to obtain such addresses from an Internet registry. An
enterprise that requests IP addresses for its external connectivity
will never be assigned addresses from the blocks defined above.

In order to use private address space, an enterprise needs to
determine which hosts do not need to have network layer connectivity
outside the enterprise in the foreseeable future and thus could be
classified as private. Such hosts will use the private address space
defined above. Private hosts can communicate with all other hosts
inside the enterprise, both public and private. However, they cannot
have IP connectivity to any host outside of the enterprise. While not
having external (outside of the enterprise) IP connectivity private
hosts can still have access to external services via mediating
gateways (e.g., application layer gateways).

All other hosts will be public and will use globally unique address
space assigned by an Internet Registry. Public hosts can communicate
with other hosts inside the enterprise both public and private and
can have IP connectivity to public hosts outside the enterprise.
Public hosts do not have connectivity to private hosts of other
enterprises.





Rekhter, et al Best Current Practice [Page 4]

RFC 1918 Address Allocation for Private Internets February 1996


Moving a host from private to public or vice versa involves a change
of IP address, changes to the appropriate DNS entries, and changes to
configuration files on other hosts that reference the host by IP
address.

Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses
should not be forwarded across such links. Routers in networks not
using private address space, especially those of Internet service
providers, are expected to be configured to reject (filter out)
routing information about private networks. If such a router receives
such information the rejection shall not be treated as a routing
protocol error.

Indirect references to such addresses should be contained within the
enterprise. Prominent examples of such references are DNS Resource
Records and other information referring to internal private
addresses. In particular, Internet service providers should take
measures to prevent such leakage.

4. Advantages and Disadvantages of Using Private Address Space

The obvious advantage of using private address space for the Internet
at large is to conserve the globally unique address space by not
using it where global uniqueness is not required.

Enterprises themselves also enjoy a number of benefits from their
usage of private address space: They gain a lot of flexibility in
network design by having more address space at their disposal than
they could obtain from the globally unique pool. This enables
operationally and administratively convenient addressing schemes as
well as easier growth paths.

For a variety of reasons the Internet has already encountered
situations where an enterprise that has not been connected to the
Internet had used IP address space for its hosts without getting this
space assigned from the IANA. In some cases this address space had
been already assigned to other enterprises. If such an enterprise
would later connects to the Internet, this could potentially create
very serious problems, as IP routing cannot provide correct
operations in presence of ambiguous addressing. Although in principle
Internet Service Providers should guard against such mistakes through
the use of route filters, this does not always happen in practice.
Using private address space provides a safe choice for such
enterprises, avoiding clashes once outside connectivity is needed.





Rekhter, et al Best Current Practice [Page 5]

RFC 1918 Address Allocation for Private Internets February 1996


A major drawback to the use of private address space is that it may
actually reduce an enterprise's flexibility to access the Internet.
Once one commits to using a private address, one is committing to
renumber part or all of an enterprise, should one decide to provide
IP connectivity between that part (or all of the enterprise) and the
Internet. Usually the cost of renumbering can be measured by
counting the number of hosts that have to transition from private to
public. As was discussed earlier, however, even if a network uses
globally unique addresses, it may still have to renumber in order to
acquire Internet-wide IP connectivity.

Another drawback to the use of private address space is that it may
require renumbering when merging several private internets into a
single private internet. If we review the examples we list in Section
2, we note that companies tend to merge. If such companies prior to
the merge maintained their uncoordinated internets using private
address space, then if after the merge these private internets would
be combined into a single private internet, some addresses within the
combined private internet may not be unique. As a result, hosts with
these addresses would need to be renumbered.

The cost of renumbering may well be mitigated by development and
deployment of tools that facilitate renumbering (e.g. Dynamic Host
Configuration Protocol (DHCP)). When deciding whether to use private
addresses, we recommend to inquire computer and software vendors
about availability of such tools. A sep
arate IETF effort (PIER
Working Group) is pursuing full documentation of the requirements and
procedures for renumbering.

5. Operational Considerations

One possible strategy is to design the private part of the network
first and use private address space for all internal links. Then plan
public subnets at the locations needed and design the external
connectivity.

This design does not need to be fixed permanently. If a group of one
or more hosts requires to change their status (from private to public
or vice versa) later, this can be accomplished by renumbering only
the hosts involved, and changing physical connectivity, if needed. In
locations where such changes can be foreseen (machine rooms, etc.),
it is advisable to configure separate physical media for public and
private subnets to facilitate such changes. In order to avoid major
network disruptions, it is advisable to group hosts with similar
connectivity needs on their own subnets.






Rekhter, et al Best Current Practice [Page 6]

RFC 1918 Address Allocation for Private Internets February 1996


If a suitable subnetting scheme can be designed and is supported by
the equipment concerned, it is advisable to use the 24-bit block
(class A network) of private address space and make an addressing
plan with a good growth path. If subnetting is a problem, the 16-bit
block (class C networks), or the 20-bit block (class B networks) of
private address space can be used.

One might be tempted to have both public and private addresses on the
same physical medium. While this is possible, there are pitfalls to
such a design (note that the pitfalls have nothing to do with the use
of private addresses, but are due to the presence of multiple IP
subnets on a common Data Link subnetwork). We advise caution when
proceeding in this area.

It is strongly recommended that routers which connect enterprises to
external networks are set up with appropriate packet and routing
filters at both ends of the link in order to prevent packet and
routing information leakage. An enterprise should also filter any
private networks from inbound routing information in order to protect
itself from ambiguous routing situations which can occur if routes to
the private address space point outside the enterprise.

It is possible for two sites, who both coordinate their private
address space, to communicate with each other over a public network.
To do so they must use some method of encapsulation at their borders
to a public network, thus keeping their private addresses private.

If two (or more) organizations follow the address allocation
specified in this document and then later wish to establish IP
connectivity with each other, then there is a risk that address
uniqueness would be violated. To minimize the risk it is strongly
recommended that an organization using private IP addresses choose
randomly from the reserved pool of private addresses, when allocating
sub-blocks for its internal allocation.

If an enterprise uses the private address space, or a mix of private
and public address spaces, then DNS clients outside of the enterprise
should not see addresses in the private address space used by the
enterprise, since these addresses would be ambiguous. One way to
ensure this is to run two authority servers for each DNS zone
containing both publically and privately addressed hosts. One server
would be visible from the public address space and would contain only
the subset of the enterprise's addresses which were reachable using
public addresses. The other server would be reachable only from the
private network and would contain the full set of data, including the
private addresses and whatever public addresses are reachable the
private network. In order to ensure consistency, both servers should
be configured from the same data of which the publically visible zone



Rekhter, et al Best Current Practice [Page 7]

RFC 1918 Address Allocation for Private Internets February 1996


only contains a filtered version. There is certain degree of
additional complexity associated with providing these capabilities.

6. Security Considerations

Security issues are not addressed in this memo.

7. Conclusion

With the described scheme many large enterprises will need only a
relatively small block of addresses from the globally unique IP
address space. The Internet at large benefits through conservation of
globally unique address space which will effectively lengthen the
lifetime of the IP address space. The enterprises benefit from the
increased flexibility provided by a relatively large private address
space. However, use of private addressing requires that an
organization renumber part or all of its enterprise network, as its
connectivity requirements change over time.

8. Acknowledgments

We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans-
Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN
Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne
Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks),
Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute),
Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush
(PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg
Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence),
Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet
Software Consortium) for their review and constructive comments.

9. References

[RFC1466] Gerich, E., "Guidelines for Management of IP Address
Space", RFC 1466, Merit Network, Inc., May 1993.

[RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.

[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.








Rekhter, et al Best Current Practice [Page 8]

RFC 1918 Address Allocation for Private Internets February 1996


10. Authors' Addresses

Yakov Rekhter
Cisco systems
170 West Tasman Drive
San Jose, CA, USA
Phone: +1 914 528 0090
Fax: +1 408 526-4952
EMail: yakov@cisco.com


Robert G Moskowitz
Chrysler Corporation
CIMS: 424-73-00
25999 Lawrence Ave
Center Line, MI 48015
Phone: +1 810 758 8212
Fax: +1 810 758 8173
EMail: rgm3@is.chrysler.com


Daniel Karrenberg
RIPE Network Coordination Centre
Kruislaan 409
1098 SJ Amsterdam, the Netherlands
Phone: +31 20 592 5065
Fax: +31 20 592 5090
EMail: Daniel.Karrenberg@ripe.net


Geert Jan de Groot
RIPE Network Coordination Centre
Kruislaan 409
1098 SJ Amsterdam, the Netherlands
Phone: +31 20 592 5065
Fax: +31 20 592 5090
EMail: GeertJan.deGroot@ripe.net


Eliot Lear
Mail Stop 15-730
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA 94043-1389
Phone: +1 415 960 1980
Fax: +1 415 961 9584
EMail: lear@sgi.com




Rekhter, et al Best Current Practice [Page 9]
BFW não é meu hobby, é meu router !
Não dou suporte.

"Nem sim, nem não, mas muito pelo contrário, não sou contra nem à favor,
porque em matéria de certas coisas o mais importante é o principalmente,
aliás inclusive, não resta a menor dúvida".
De algum politico brasileiro...
Avatar do usuário
Marcelo - Brazil
BFW Founder
BFW Manager
BFW Beneméritos
 
Mensagens: 3185
Registrado em: Qua Ago 24, 2005 10:40 pm
Localização: Campinas - São Paulo
BrazilFW Box: Hp Proliant ML30 Gen 9, Intel® Xeon® E3-1200 v5 3,0 Ghz, 8 Gb ram DDR4, 1 Tb HD, Links 120x12 mb/s cabo + 100x100 mb/s fibra. Addon: Unifi, 50 clientes lan + 50 cliente wireless.


Voltar para BrazilFW News (English)

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron