Re: Multiple routing tables in action...

2008-05-11 Thread Igor Sysoev
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-v.
 Linux behaves a little bit differently as you have to make an 'ip rule' 
 entry for it but it doesn't use the firewall.
 
 for now this code asks you to use a firewall to classify incoming 
 packets..
 
 e.g.
 100 setfib 2 ip from any to any in recv em0

Is is possible to extend ifconfig to classify incoming packets ?


-- 
Igor Sysoev
http://sysoev.ru/en/
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-05-11 Thread Julian Elischer

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 instance and v-v.
Linux behaves a little bit differently as you have to make an 'ip rule' 
entry for it but it doesn't use the firewall.
for now this code asks you to use a firewall to classify incoming 
packets..


e.g.
100 setfib 2 ip from any to any in recv em0


Is is possible to extend ifconfig to classify incoming packets ?




You could assign a default fib for all packets received by an
interface and that is on my list of things to look at doing later.


In the meantime you can use ipfw and pf to assign fibs to incoming 
packets depending on the receive interface.


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-29 Thread Paul
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 :)
Mainly to use with BGP , having multiple BGP routing tables.   I would 
like it to be similar to Cisco's VRF or Juniper's routing instance, but 
maybe that's asking too much.  
We use it on our hardware routers for implementations such as having 
multiple bgp route tables and having customer bandwidth pricing change 
based on which routing table their traffic gets , say.. value customers, 
premium customers, customers who want only certain carriers in their 
bandwidth mix, etc.   
Would be fun to have support for FBSD with quagga/openbgpd etc.. and be 
able to use dscp for marking or any other policy based rule (source ip 
for instance).


Thanks Julian.. This is a step forward in the right direction :)


Julian Elischer wrote:

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 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 via one link and
all other traffic via the other.

You have 3 ISPs and want all traffic from the accounting department
to go via a particular path (that is encrypted) but regular office
chatter to go via another.

I have other more complex examples in my work.

I'm sure others have more solid examples as well.

google for policy routing.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-29 Thread Julian Elischer

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 :)
Mainly to use with BGP , having multiple BGP routing tables.   I would 
like it to be similar to Cisco's VRF or Juniper's routing instance, but 
maybe that's asking too much.  We use it on our hardware routers for 
implementations such as having multiple bgp route tables and having 
customer bandwidth pricing change based on which routing table their 
traffic gets , say.. value customers, premium customers, customers who 
want only certain carriers in their bandwidth mix, etc.   Would be fun 
to have support for FBSD with quagga/openbgpd etc.. and be able to use 
dscp for marking or any other policy based rule (source ip for instance).


Thanks Julian.. This is a step forward in the right direction :)


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.

I think it is possible that events from a particular FIB should only 
be reported to routing sockets that are associated with that FIB.

but I'm not sure about this.

This would mean running a separate instance of the routing daemon for
each FIB (VRF?).  Does this sound right to people?





Julian Elischer wrote:

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 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 via one link and
all other traffic via the other.

You have 3 ISPs and want all traffic from the accounting department
to go via a particular path (that is encrypted) but regular office
chatter to go via another.

I have other more complex examples in my work.

I'm sure others have more solid examples as well.

google for policy routing.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-29 Thread Max Laier
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 :) Mainly to use with BGP , having multiple BGP routing tables.  
  I would like it to be similar to Cisco's VRF or Juniper's routing
  instance, but maybe that's asking too much.  We use it on our
  hardware routers for implementations such as having multiple bgp
  route tables and having customer bandwidth pricing change based on
  which routing table their traffic gets , say.. value customers,
  premium customers, customers who want only certain carriers in their
  bandwidth mix, etc.   Would be fun to have support for FBSD with
  quagga/openbgpd etc.. and be able to use dscp for marking or any
  other policy based rule (source ip for instance).
 
  Thanks Julian.. This is a step forward in the right direction :)

 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.

 I think it is possible that events from a particular FIB should only
 be reported to routing sockets that are associated with that FIB.
 but I'm not sure about this.

 This would mean running a separate instance of the routing daemon for
 each FIB (VRF?).  Does this sound right to people?

OpenBSD added[1] a field to the rt_msghdr to indicate/select the 
source/destination table.  If we were to do the same at least OpenBGPB 
should work with fairly minimal changes.

I think it's a sensible approach, too.  A routing daemon wouldn't have to 
select over a dozen sockets to do what is needed and it will be much 
easier as well.  If easily done, a way to bind a route socket to a 
table id would also be nice as it would easily make things work with 
multi table oblivious daemons.

[1]http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/route.h.diff?r1=1.44r2=1.45f=h

  Julian Elischer wrote:
  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 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 via one link and
  all other traffic via the other.
 
  You have 3 ISPs and want all traffic from the accounting department
  to go via a particular path (that is encrypted) but regular office
  chatter to go via another.
 
  I have other more complex examples in my work.
 
  I'm sure others have more solid examples as well.
 
  google for policy routing.
  ___
  freebsd-net@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-net
  To unsubscribe, send any mail to
  [EMAIL PROTECTED]

 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to [EMAIL PROTECTED]



-- 
/\  Best regards,  | [EMAIL PROTECTED]
\ /  Max Laier  | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | [EMAIL PROTECTED]
/ \  ASCII Ribbon Campaign  | Against HTML Mail and News
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-29 Thread Julian Elischer

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 :) Mainly to use with BGP , having multiple BGP routing tables.  
I would like it to be similar to Cisco's VRF or Juniper's routing

instance, but maybe that's asking too much.  We use it on our
hardware routers for implementations such as having multiple bgp
route tables and having customer bandwidth pricing change based on
which routing table their traffic gets , say.. value customers,
premium customers, customers who want only certain carriers in their
bandwidth mix, etc.   Would be fun to have support for FBSD with
quagga/openbgpd etc.. and be able to use dscp for marking or any
other policy based rule (source ip for instance).

Thanks Julian.. This is a step forward in the right direction :)

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.

I think it is possible that events from a particular FIB should only
be reported to routing sockets that are associated with that FIB.
but I'm not sure about this.

This would mean running a separate instance of the routing daemon for
each FIB (VRF?).  Does this sound right to people?


OpenBSD added[1] a field to the rt_msghdr to indicate/select the 
source/destination table.  If we were to do the same at least OpenBGPB 
should work with fairly minimal changes.


I would like someone who knows routing daemons to add this
or tell me what needs to be done.



I think it's a sensible approach, too.  A routing daemon wouldn't have to 
select over a dozen sockets to do what is needed and it will be much 
easier as well.  If easily done, a way to bind a route socket to a 
table id would also be nice as it would easily make things work with 
multi table oblivious daemons.


I already have a socket option that works on routing sockets to bind 
them to a FIB.


and /usr/bin/setfib can be used to make a fib-unaware process bind by 
default to a set fib.

e.g. setfib -2 routed [args]









___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-29 Thread Julian Elischer

-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 em0.002 on routing instance 2 and 
without using any policies or firewall rules it would know that 
everything coming on em0.002 uses the #2 instance and routes 
accordingly.  Same with Juniper. 


that's coming.. have patience.. we will have vimage (check google)
plus multiple FIBS in each vimage..  for now use a firewall
classifier.



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-v.
Linux behaves a little bit differently as you have to make an 'ip rule' 
entry for it but it doesn't use the firewall.


for now this code asks you to use a firewall to classify incoming 
packets..


e.g.
100 setfib 2 ip from any to any in recv em0



I wish FreeBSD made a routing daemon that had total interactivity 
between the OS and daemon which would be great.. Quagga is good but the 
interaction is very annoying. Quagga has no idea what is going on on the 
kernel level and the kernel has no idea what is going on with quagga.   


I'm not a routing daemon expert..

Ex: if I add or remove a route from the kernel using 'route' command it 
does not remove it in quagga.   Would be great to have a BGP/OSPF combo 
integrated into the kernel somehow.


Sounds like Quagga needs to be made aware of routing events by 
listening for them on routing sockets. They are available.


[chop]


 I have need for
many many gigabit firewalls to put in front of many servers and the cost 
for the hardware firewall devices is way too much to deploy in the 
quantity that I need :/


Paul



If you have a roadmap, then get involved..  :-)
We need end user quidance on some of this stuff.


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-29 Thread Bruce M. Simpson

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 particular FIB should only 
be reported to routing sockets that are associated with that FIB.

but I'm not sure about this.


Please look at the Linux rtnetlink socket, they use a tag-length-value 
protocol for just this reason.


It seems reasonable that PF_ROUTE messages have some kind of filter 
applied to them until a more complete story can be realised for this.
   Most PF_ROUTE clients are savvy enough to ignore message types on 
the socket that they don't understand.
   If there is a need to announce route adds and deletes on the socket 
on a per-fib basis, it seems reasonable to stash it in one of the unused 
fields (if we've got any of those..urp) and change the rtm_type field 
for now.


However it does take us further down a route (no pun intended) of 
incremental growth which has real risk (lack of or insufficiently rich 
test cases, requirements drift etc) and seems to be incumbent with open 
source in general.




This would mean running a separate instance of the routing daemon for
each FIB (VRF?).  Does this sound right to people?


Sounds crap! You really, really don't want to be doing that if you can 
avoid it.


Of course a lot of what's out there is not geared up to deal with it 
(and why would it be?) so it's fine for the time being, but it really, 
really can't be considered a complete, production-quality solution until 
the missing parts exist.


cheers
BMS

P.S. I am impressed by the scope and ambition of your work even if I 
haven't had a chance to digest it fully yet, and I hope that my concern 
about production quality open source here is not misinterpreted as 
nay-saying or disapproval by anyone.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Multiple routing tables in action...

2008-04-26 Thread Julian Elischer

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.0.1  127.0.0.1  UH  0  379lo0
172.28.5/24172.28.14.1UGS 0   10   bce1
172.28.6.32/28 link#2 UC  00em0
172.28.6.3300:15:2b:46:56:90  UHLW10em0   1190
172.28.14/24   link#6 UC  00   bce1
172.28.14.100:04:23:b5:a9:2b  UHLW30   bce1   1117
wsa02:julian 10] setfib -1 netstat -rn
Routing tables

Internet:
DestinationGatewayFlagsRefs  Use  Netif Expire
default172.28.6.33UGS 00em0
1.1.1/28   172.28.6.33UGS 00em0
127.0.0.1  127.0.0.1  UH  01lo0
172.28.5/24172.28.6.33UGS 06em0
172.28.6.32/28 link#2 UC  00em0
172.28.6.3300:15:2b:46:56:90  UHLW46em0   1182
wsa02:rjulian 11]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-26 Thread Ivo Vachkov
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:
  DestinationGatewayFlagsRefs  Use  Netif Expire
  default172.28.14.1UGS 0  788   bce1
  127.0.0.1  127.0.0.1  UH  0  379lo0
  172.28.5/24172.28.14.1UGS 0   10   bce1
  172.28.6.32/28 link#2 UC  00em0
  172.28.6.3300:15:2b:46:56:90  UHLW10em0   1190
  172.28.14/24   link#6 UC  00   bce1
  172.28.14.100:04:23:b5:a9:2b  UHLW30   bce1   1117
  wsa02:julian 10] setfib -1 netstat -rn
  Routing tables

  Internet:
  DestinationGatewayFlagsRefs  Use  Netif Expire
  default172.28.6.33UGS 00em0
  1.1.1/28   172.28.6.33UGS 00em0
  127.0.0.1  127.0.0.1  UH  01lo0
  172.28.5/24172.28.6.33UGS 06em0
  172.28.6.32/28 link#2 UC  00em0
  172.28.6.3300:15:2b:46:56:90  UHLW46em0   1182
  wsa02:rjulian 11]

  ___
  freebsd-net@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-net
  To unsubscribe, send any mail to [EMAIL PROTECTED]




-- 
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity. Dennis Ritchie
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-26 Thread Julian Elischer

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 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.0.1  127.0.0.1  UH  0  379lo0
 172.28.5/24172.28.14.1UGS 0   10   bce1
 172.28.6.32/28 link#2 UC  00em0
 172.28.6.3300:15:2b:46:56:90  UHLW10em0   1190
 172.28.14/24   link#6 UC  00   bce1
 172.28.14.100:04:23:b5:a9:2b  UHLW30   bce1   1117
 wsa02:julian 10] setfib -1 netstat -rn
 Routing tables

 Internet:
 DestinationGatewayFlagsRefs  Use  Netif Expire
 default172.28.6.33UGS 00em0
 1.1.1/28   172.28.6.33UGS 00em0
 127.0.0.1  127.0.0.1  UH  01lo0
 172.28.5/24172.28.6.33UGS 06em0
 172.28.6.32/28 link#2 UC  00em0
 172.28.6.3300:15:2b:46:56:90  UHLW46em0   1182
 wsa02:rjulian 11]

 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to [EMAIL PROTECTED]







___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-26 Thread Martes G Wigglesworth
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 different routing tables?

On Sat, 2008-04-26 at 21:09 +0300, Ivo Vachkov wrote:
 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:
   DestinationGatewayFlagsRefs  Use  Netif Expire
   default172.28.14.1UGS 0  788   bce1
   127.0.0.1  127.0.0.1  UH  0  379lo0
   172.28.5/24172.28.14.1UGS 0   10   bce1
   172.28.6.32/28 link#2 UC  00em0
   172.28.6.3300:15:2b:46:56:90  UHLW10em0   1190
   172.28.14/24   link#6 UC  00   bce1
   172.28.14.100:04:23:b5:a9:2b  UHLW30   bce1   1117
   wsa02:julian 10] setfib -1 netstat -rn
   Routing tables
 
   Internet:
   DestinationGatewayFlagsRefs  Use  Netif Expire
   default172.28.6.33UGS 00em0
   1.1.1/28   172.28.6.33UGS 00em0
   127.0.0.1  127.0.0.1  UH  01lo0
   172.28.5/24172.28.6.33UGS 06em0
   172.28.6.32/28 link#2 UC  00em0
   172.28.6.3300:15:2b:46:56:90  UHLW46em0   1182
   wsa02:rjulian 11]
 
   ___
   freebsd-net@freebsd.org mailing list
   http://lists.freebsd.org/mailman/listinfo/freebsd-net
   To unsubscribe, send any mail to [EMAIL PROTECTED]
 
 
 
 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Multiple routing tables in action...

2008-04-26 Thread Julian Elischer

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 able to see two
distinctly different routing tables?


setfib -1 .. (that is minus one) executes the following command with
the default routing table (fib) set to the second table (table 1).
setfib -0 (that's minus zero) runs the folling arguments as a
command with it's default routing table set to the first routing
table (table 0).

the setfib command is added as part of the patch.




On Sat, 2008-04-26 at 21:09 +0300, Ivo Vachkov wrote:

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:
 DestinationGatewayFlagsRefs  Use  Netif Expire
 default172.28.14.1UGS 0  788   bce1
 127.0.0.1  127.0.0.1  UH  0  379lo0
 172.28.5/24172.28.14.1UGS 0   10   bce1
 172.28.6.32/28 link#2 UC  00em0
 172.28.6.3300:15:2b:46:56:90  UHLW10em0   1190
 172.28.14/24   link#6 UC  00   bce1
 172.28.14.100:04:23:b5:a9:2b  UHLW30   bce1   1117
 wsa02:julian 10] setfib -1 netstat -rn
 Routing tables

 Internet:
 DestinationGatewayFlagsRefs  Use  Netif Expire
 default172.28.6.33UGS 00em0
 1.1.1/28   172.28.6.33UGS 00em0
 127.0.0.1  127.0.0.1  UH  01lo0
 172.28.5/24172.28.6.33UGS 06em0
 172.28.6.32/28 link#2 UC  00em0
 172.28.6.3300:15:2b:46:56:90  UHLW46em0   1182
 wsa02:rjulian 11]

 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to [EMAIL PROTECTED]






___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]