Brandon Gooch wrote:
Are there plans to update the documentation regarding multiple routing tables?
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-routing.html
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org
Are there plans to update the documentation regarding multiple routing tables?
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-routing.html
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
check that ipv6 doesn't crash
with this patch too (ipv6 doesn't support Multiple routing tables
yet).
It took me some time to setup a test IPv6 network and it also works, no
crashes with v6 here.
--
Oleg
___
freebsd-net@freebsd.org mailing list
Oleg Sharoyko wrote:
Julian Elischer wrote:
I'll get that checked in!
Please, also take a look at
_syncache_add() in tcp_syncache.c
There is some code which looks strange, at least at first sight. Won't
bcopy() overwrite assigned value of sc->sc_inc.inc_fibnum ?
/* XXX-BZ this fi
Julian Elischer wrote:
I'll get that checked in!
Please, also take a look at
_syncache_add() in tcp_syncache.c
There is some code which looks strange, at least at first sight. Won't
bcopy() overwrite assigned value of sc->sc_inc.inc_fibnum ?
/* XXX-BZ this fib assignment is just u
my final patch.
This is taken against -current. so it may not patch exactly cleanly.
it's not quite minimal as I'm cleaning up something too, but
could you check it works?
if you have ipv6 it might be nice to check that ipv6 doesn't crash
with this patch too (ipv6 doesn't suppor
Oleg Sharoyko wrote:
On Mon, 2009-07-27 at 16:24 -0700, Julian Elischer wrote:
in addition to the patches already sent you might like to add the
following line to netinet/tcp_input.c
}
inc.inc_fport = th->th_sport;
inc.inc_lport = th->th_dport;
On Mon, 2009-07-27 at 16:24 -0700, Julian Elischer wrote:
> > in addition to the patches already sent you might like to add the
> > following line to netinet/tcp_input.c
> >
> > }
> > inc.inc_fport = th->th_sport;
> > inc.inc_lport = th->th_dport;
Julian Elischer wrote:
Oleg Sharoyko wrote:
Julian Elischer wrote:
great.. in your simple server, can you do the sockopt on the socket
AFTER you did the listen()?
(just as a test).
Doesn't help. I have also tried to add setsockopt() after accept()
(for a new socket) and in this case the o
Oleg Sharoyko wrote:
Julian Elischer wrote:
great.. in your simple server, can you do the sockopt on the socket
AFTER you did the listen()?
(just as a test).
Doesn't help. I have also tried to add setsockopt() after accept() (for
a new socket) and in this case the only packet that is being
Oleg Sharoyko wrote:
Julian Elischer wrote:
great.. in your simple server, can you do the sockopt on the socket
AFTER you did the listen()?
(just as a test).
Doesn't help. I have also tried to add setsockopt() after accept() (for
a new socket) and in this case the only packet that is being
Julian Elischer wrote:
So there are two possible ways a daemon might assign a fib to a socket
that it is accepting:
1/ the accept socket could take the FIB of the process.
2/ the accept socket could take the fib of the incoming SYN packet.
I chose #1, but it is possible something in changes
Julian Elischer wrote:
great.. in your simple server, can you do the sockopt on the socket
AFTER you did the listen()?
(just as a test).
Doesn't help. I have also tried to add setsockopt() after accept() (for
a new socket) and in this case the only packet that is being sent out
via wrong i
Oleg Sharoyko wrote:
Julian Elischer wrote:
does it still fail if you run it in foreground mode (no daemonizing)?
Yes. I actually test sshd in foreground mode (-D tells sshd to not go
into background). I have also checked a very simple client/server where
server called setsockopt(SO_SETFIB
So there are two possible ways a daemon might assign a fib to a socket
that it is accepting:
1/ the accept socket could take the FIB of the process.
2/ the accept socket could take the fib of the incoming SYN packet.
I chose #1, but it is possible something in changes between 6
and 7 broke th
Julian Elischer wrote:
does it still fail if you run it in foreground mode (no daemonizing)?
Yes. I actually test sshd in foreground mode (-D tells sshd to not go
into background). I have also checked a very simple client/server where
server called setsockopt(SO_SETFIB, 1) and got the same
Oleg Sharoyko wrote:
Julian Elischer wrote:
r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress
195.208.245.229:' -D
Are you running this from inetd?. (doesnt look like it)
No, I run this from shell merely for test purposes. First I tried to
start sshd in a usual way in a
Julian Elischer wrote:
r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress
195.208.245.229:' -D
Are you running this from inetd?. (doesnt look like it)
No, I run this from shell merely for test purposes. First I tried to
start sshd in a usual way in a jail, but came to thi
Oleg Sharoyko wrote:
Hello!
I'm having a trouble with multiple routing tables (FreeBSD 7.2 release).
Either I'm missing something in my setup or packets for daemons started
with setfib are being sent out via the wrong interface.
What I'd like to implement:
em0 - internal man
Hello!
I'm having a trouble with multiple routing tables (FreeBSD 7.2 release).
Either I'm missing something in my setup or packets for daemons started
with setfib are being sent out via the wrong interface.
What I'd like to implement:
em0 - internal management network with ip a
Hello,
I noticed this:
speed# netstat -rnfinet
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
127.0.0.1 link#4 UH 00lo0
192.168.1.0/24 link#6 U 1 193 wlan0
192.168.1.6
Hi,
I'me testing a network setup using multiple routing tables. I want to
use this to setup different gateways. Some basic design is this:
The system has two different uplinks (fast and slow for backup).
And somewhere on the internet a colo with a full internet address range.
I have setu
obviously you did some other commands here..
something generated 2 million packets..
Julian, its a production enviroment, firewall was up for a few
minutes. Thats the reason.
I was thinking of adding a 'reroute' ipfw keyword.. kind of like
'fwd {original dest} ip from any to any'
because 'fwd'
On Mon, Jan 19, 2009 at 2:24 PM, Luiz Otavio O Souza wrote:
>>> obviously you did some other commands here..
>>> something generated 2 million packets..
>>
>> Julian, its a production enviroment, firewall was up for a few
>> minutes. Thats the reason.
>>
>>> I was thinking of adding a 'reroute' ip
obviously you did some other commands here..
something generated 2 million packets..
Julian, its a production enviroment, firewall was up for a few
minutes. Thats the reason.
I was thinking of adding a 'reroute' ipfw keyword.. kind of like
'fwd {original dest} ip from any to any'
because 'fwd'
> obviously you did some other commands here..
> something generated 2 million packets..
Julian, its a production enviroment, firewall was up for a few
minutes. Thats the reason.
> I was thinking of adding a 'reroute' ipfw keyword.. kind of like
> 'fwd {original dest} ip from any to any'
> becaus
Eduardo Meyer wrote:
Hello,
I am trying the new FIB stuff on -STABLE with IPFW, I made many tests
and it did not work as I expected.
Quick testing:
# lynx -dump http://www.whatismyip.org
200.165.75.10
# setfib -1 lynx -dump http://www.whatismyip.org
189.52.141.2
# setfib -2 lynx -dump http:/
Hello,
I am trying the new FIB stuff on -STABLE with IPFW, I made many tests
and it did not work as I expected.
Quick testing:
# lynx -dump http://www.whatismyip.org
200.165.75.10
# setfib -1 lynx -dump http://www.whatismyip.org
189.52.141.2
# setfib -2 lynx -dump http://www.whatismyip.org
20
Hello,
I am trying the new FIB stuff on -STABLE with IPFW, I made many tests
and it did not work as I expected.
Quick testing:
# lynx -dump http://www.whatismyip.org
200.165.75.10
# setfib -1 lynx -dump http://www.whatismyip.org
189.52.141.2
# setfib -2 lynx -dump http://www.whatismyip.org
201
tion fails I have trouble connecting to my SSH server
(because DNS stops working)
So, after FreeBSD got multiple routing tables I tried this:
1) On boot I have default route to provider (1)
2) After MPD (PPTP) is up I do
2a) setfib 1 route add default PPTP_DEFAULT_GATEWAY
2b) setfib 1 /usr/local/etc
tion fails I have trouble connecting to my SSH server
(because DNS stops working)
So, after FreeBSD got multiple routing tables I tried this:
1) On boot I have default route to provider (1)
2) After MPD (PPTP) is up I do
2a) setfib 1 route add default PPTP_DEFAULT_GATEWAY
2b) setfib 1 /usr/local/etc
uble connecting to my SSH server
(because DNS stops working)
So, after FreeBSD got multiple routing tables I tried this:
1) On boot I have default route to provider (1)
2) After MPD (PPTP) is up I do
2a) setfib 1 route add default PPTP_DEFAULT_GATEWAY
2b) setfib 1 /usr/local/etc/rc.d/tranmissi
Igor Sysoev wrote:
On Tue, Apr 29, 2008 at 12:11:03PM -0700, Julian Elischer wrote:
Then you can export RIB entries , say
you have 5 BGP peers and you want to export 2 or 3 or all of them into
the 'main' routing instance you can set up a policy to add those learned
routes into the main instan
On Tue, Apr 29, 2008 at 12:11:03PM -0700, Julian Elischer wrote:
> >Then you can export RIB entries , say
> >you have 5 BGP peers and you want to export 2 or 3 or all of them into
> >the 'main' routing instance you can set up a policy to add those learned
> >routes into the main instance and v-
Bjoern A. Zeeb wrote:
On Tue, 6 May 2008, Julian Elischer wrote:
Hi,
Bjoern A. Zeeb wrote:
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken fr
On Tue, 6 May 2008, Julian Elischer wrote:
Hi,
Bjoern A. Zeeb wrote:
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot
Bjoern A. Zeeb wrote:
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot/user/julian/routing/src
So after looking at the
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot/user/julian/routing/src
So after looking at the patch a bit more again
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
a kernel needs to be created with the option ROUTETABLES=N
e.g.
+optionsROUTETABLES=2 # max 16. 1 is back
compatible.
leaving this out will result in just a single routing table as per normal.
the max is 16 but I hav
John Hay wrote:
You don't need to go to the kernel for this sort of thing unless you
specifically need to implement route policy based on which interface(s)
a packet came in on.
Yes I know that. But in the world of adhoc wireless mesh networking
there are very few non-linux people, so the
Julian Elischer wrote:
OLSR is an overlay network
Nope -- the express intention was that it could be used for basic IP
connectivity, for mobile devices. In OLSR, every node is a potential IP
forwarder unless it explicitly advertises itself as being unwilling to
forward.
and any machine th
done it.hav
Having been prodded to go look up OLSR i an say that this is exactly
the kind of thing that multiple routing tables are useful for.
OLSR is an overlay network and any machine that participated must have
a split personality. First it must be able to think in terms of the
basic loc
John Hay wrote:
This confuses me
The whole point of a FIB is to decide the *next* hop for a
given input packet. So questions.
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
which ever one you select, using t
On Fri, May 02, 2008 at 04:44:20PM +0100, Bruce M. Simpson wrote:
> John Hay wrote:
> >The linux guys seems to have multiple fibs (or whatever they call them)
> >which they can chain together by giving them different priorities. The
> >effect seems to be that a packet will be matched through the hi
John Hay wrote:
The linux guys seems to have multiple fibs (or whatever they call them)
which they can chain together by giving them different priorities. The
effect seems to be that a packet will be matched through the highest
priority fib to the lowest until a route match is found en then is us
> >This confuses me
> >
> >The whole point of a FIB is to decide the *next* hop for a
> >given input packet. So questions.
> >1) A packet arrives on an interface. If this interface is
> > associated with more than one FIB, which FIB does it get
> > given to?
> >
>
> which ever one you sel
> Date: Wed, 30 Apr 2008 10:25:51 -0700
> From: Julian Elischer <[EMAIL PROTECTED]>
>
> Bruce M Simpson wrote:
> > Julian Elischer wrote:
> >> An interface may however be present in entries from multiple FIBs
> >> in which case the INCOMING packets on that interface need to
> >> be disambiguated w
On Wed, 30 Apr 2008 18:56:07 BST "Bruce M. Simpson" <[EMAIL PROTECTED]> wrote:
> > 2) If that decision is taken by a a packet 'classifier',
> >isn't it in effect doing the job of a FIB (deciding the
> >next hop, which happens to be a local FIB)? Recall that
> >basically a packet passe
Bruce M Simpson wrote:
Julian Elischer wrote:
what's SSM?
Source-specific multicast, where multicast flows (channels) are
identified by both their original source address, and group address.
Multicast addresses have no meaning on their own beyond the scope of a
single link.
I haven't ch
Bruce M. Simpson wrote:
Bakul Shah wrote:
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
If you only have a single FIB, there is no issue here.
If you have multiple FIBs, the decision gets made by the class
Bakul Shah wrote:
On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]> wrote:
Interfaces are not however assigned to FIB instance. each FIB may
contain entries for each interface, and by default they do, but you
can delete teh entries associated with a particular interface from
Julian Elischer wrote:
what's SSM?
Source-specific multicast, where multicast flows (channels) are
identified by both their original source address, and group address.
Multicast addresses have no meaning on their own beyond the scope of a
single link.
I haven't changed any of that.. Basi
Bruce M. Simpson wrote:
Wouldn't it make sense to treat each alias as on a separate
logical interface? Then each logical interface belongs to
exactly one FIB. On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address. That reduces confusion quite
Bakul Shah wrote:
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
If you only have a single FIB, there is no issue here.
If you have multiple FIBs, the decision gets made by the classifier.
2) If that decis
On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> Interfaces are not however assigned to FIB instance. each FIB may
> contain entries for each interface, and by default they do, but you
> can delete teh entries associated with a particular interface from
> a particu
Bruce M Simpson wrote:
Julian Elischer wrote:
An interface may however be present in entries from multiple FIBs
in which case the INCOMING packets on that interface need to
be disambiguated with respect to which FIB they belong to.
Yes, there is no way the forwarding code alone can do this.
I
...)
> >
> > The RIBs exports data, as needed to a single FIB which is used by the
> > ASICs (hardware forwarding engines) to do the actual forwarding of the
> > packets. In a real router, the forwarding of almost all packets is done
> > in hardware with no real involve
processor that determines the
routes. (N.B. This is a gross simplification of what modern routers
do or can do, but I don't want to send a book to the list.)
A general purpose OS is a different beast as it has no physical
equivalent of the FIB. It may have multiple routing tables, though, to
Julian Elischer wrote:
An interface may however be present in entries from multiple FIBs
in which case the INCOMING packets on that interface need to
be disambiguated with respect to which FIB they belong to.
Yes, there is no way the forwarding code alone can do this.
It should not be expected
Bruce M. Simpson wrote:
Julian Elischer wrote:
A general purpose OS is a different beast as it has no physical
equivalent of the FIB. It may have multiple routing tables, though, to
I think setrib would be a term less likely to cause confusion then
setfib even though, in the case of your
Julian Elischer wrote:
A general purpose OS is a different beast as it has no physical
equivalent of the FIB. It may have multiple routing tables, though, to
I think setrib would be a term less likely to cause confusion then
setfib even though, in the case of your FreeBSD patches, it's r
Julian Elischer wrote:
The interaction with routing daemons is something I don't know
enough about. I need someone who knows routing daemons to tell
how to correctly tweek code that sends routing events.
As long as it doesn't break anything...
I think it is possible that events from a partic
, but I don't want to send a book to the list.)
A general purpose OS is a different beast as it has no physical
equivalent of the FIB. It may have multiple routing tables, though, to
I think setrib would be a term less likely to cause confusion then
setfib even though, in the case of your FreeB
-net added to broaden the conversation
Paul wrote:
The routing daemons run linked separate instances and create their own
RIB. Take a look at Cisco's VRF implementation. You can even have
interfaces assigned to the other routing instance so you could have
em0.001 on routing instance 1 and e
Max Laier wrote:
On Tuesday 29 April 2008 20:19:14 Julian Elischer wrote:
Paul wrote:
I've been waiting for something like this. Linux has done policy
routing for many many years and is very good at it. I prefer to use
FreeBSD for routing though and this is a feature I have been waiting
for :
gt;> 0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote:
> >>> >A little progress report
> >>> >From a recently installed (6.3) machine (plus patches)
> >>>
> >>> Ok, being ignorant to this, possibly a silly question:
&g
0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote:
>A little progress report
>From a recently installed (6.3) machine (plus patches)
Ok, being ignorant to this, possibly a silly question:
Why would i want or need multiple routing tables ?
any time you wnat to ba
possibly a silly question:
Why would i want or need multiple routing tables ?
any time you wnat to base a route upon something other than just
the destination address. It's basically called "Policy based
routing".
Trivial examples:
You have two ISPs and you want to send all SMTP v
Wilkinson, Alex wrote:
0n Sat, Apr 26, 2008 at 08:44:30AM -0700, Julian Elischer wrote:
>A little progress report
>From a recently installed (6.3) machine (plus patches)
Ok, being ignorant to this, possibly a silly question:
Why would i want or need multiple routing
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot/user/julian/routing/src
a kernel needs to be created with the option ROUTETABLES=N
e.g.
+optionsROUTETAB
Martes G Wigglesworth wrote:
Sorry for my late entry into this interesting subject, however, what
exactly was the original post displaying? I have 6.3-Stable running,
and I don't even have the first command listed as "setfib", on my
system.
What did the setfib -l command do, so that you were ab
Sorry for my late entry into this interesting subject, however, what
exactly was the original post displaying? I have 6.3-Stable running,
and I don't even have the first command listed as "setfib", on my
system.
What did the setfib -l command do, so that you were able to see two
distinctly differ
Ivo Vachkov wrote:
when do we get to see those patches ? :)
for -current: http://www.freebsd.org/~julian/mrt.diff
for releng_6: http://www.freebsd.org/~julian/mrt6.diff
On Sat, Apr 26, 2008 at 6:44 PM, Julian Elischer <[EMAIL PROTECTED]> wrote:
A little progress report
From a recently ins
when do we get to see those patches ? :)
On Sat, Apr 26, 2008 at 6:44 PM, Julian Elischer <[EMAIL PROTECTED]> wrote:
> A little progress report
>
> From a recently installed (6.3) machine (plus patches)
>
> wsa02:julian 9] setfib -0 netstat -rn
> Routing tables
>
> Internet:
> Destination
A little progress report
From a recently installed (6.3) machine (plus patches)
wsa02:julian 9] setfib -0 netstat -rn
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
default172.28.14.1UGS 0 788 bce1
127.0
Jeremie Le Hen wrote:
Julian,
On Tue, Feb 26, 2008 at 10:00:01AM -0800, Julian Elischer wrote:
IPV6 in vimage is suported I believe.. (super jails)
bz@ replied in another thread that the feature is coming forth.
What about your multiple routing tables patch? ISTR you said it would
be
Julian,
On Tue, Feb 26, 2008 at 10:00:01AM -0800, Julian Elischer wrote:
> IPV6 in vimage is suported I believe.. (super jails)
bz@ replied in another thread that the feature is coming forth.
What about your multiple routing tables patch? ISTR you said it would
be pretty orthogonal to vima
On thing where FreeBSD has been falling behind, and which by chance I
have some time to work on is "policy based routing", which allows different
packet streams to be routed by more than just the destination address.
Constraints:
I want to make some form of this available in the 6.x
ty to have
multiple choices for next-hops, not multiple routing tables -- that's
just how the next-hops might conceptually be presented to the user.]
I'm well aware of fact that i can do policy routing via pf/ipf/ipfw as well of
http://imunes.tel.fer.hr/virtnet/
Again, not entirely th
bsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
I'm on the verge of doing multiple routing tables.
I'm currently waiting for feedback from Andre who has some work
in this field planned also.
I need it for work..so I'll probably start this week.
tha
I would like to ask, whether there are any plans to implement multiple
route tables, like OpenBSD did:
http://archives.neohapsis.com/archives/openbsd/2006-10/2665.html
I'm well aware of fact that i can do policy routing via pf/ipf/ipfw as well of
http://imunes.tel.fer.hr/virtnet/
I'm afraid tha
Andre Oppermann wrote:
Why do you need two routing tables? Do you run different routing daemons
in the jails? Do you have different default gateways for the jails? Just
trying to understand your requirements and usage of this feature.
Well, I can tell you about our requirements, if you'r
On Tuesday 21 March 2006 10:22, Ragnar Lonn wrote:
> Julian Elischer wrote:
> > I'm looking at a problem where I want onemachine to really look like 2.
> > this means I want to have 2 separate routing tables if possible.
> >
> > I know I could do it with eas if I could user Marco Zec's vimage patch
Julian Elischer wrote:
I'm looking at a problem where I want onemachine to really look like 2.
this means I want to have 2 separate routing tables if possible.
I know I could do it with eas if I could user Marco Zec's vimage patches
but I need to have a path forward to 6.x and beyond
An answer
Julian Elischer wrote:
>
> I'm looking at a problem where I want onemachine to really look like 2.
> this means I want to have 2 separate routing tables if possible.
>
> I know I could do it with eas if I could user Marco Zec's vimage patches
> but I need to have a path forward to 6.x and beyond
Marco's Zec's work IHMO is pretty good to be ignored. It can be
adopted to 6.x pretty easily. I think having this in the base system
along with jails makes it even more sweater and makes us a step ahead
of zones (as in OpenSolaris).
I understand it's an overkill for your requirements, but it's the
I'm looking at a problem where I want onemachine to really look like 2.
this means I want to have 2 separate routing tables if possible.
I know I could do it with eas if I could user Marco Zec's vimage patches
but I need to have a path forward to 6.x and beyond
An answer would be to re-implement
Patrick Verkaik wrote [2003-07-02]:
>
> Does FreeBSD support multiple routing tables? If not, is any work being
> done in this area? From what I can find, it seems that Linux has this.
>
> The reason I'm asking is that I'd like to simulate a number of BGP routers
On Wed, Jul 02, 2003 at 01:11:01PM -0700, Patrick Verkaik wrote:
>
> Does FreeBSD support multiple routing tables? If not, is any work being
> done in this area? From what I can find, it seems that Linux has this.
>
> The reason I'm asking is that I'd like to simulat
Does FreeBSD support multiple routing tables? If not, is any work being
done in this area? From what I can find, it seems that Linux has this.
The reason I'm asking is that I'd like to simulate a number of BGP routers
on one box.
Thanks,
90 matches
Mail list logo
