[prev in list] [next in list] [prev in thread] [next in thread]
List: quagga-dev
Subject: [quagga-dev 589] Route Server patch for Quagga-0.96.4
From: "Jose Luis Rubio" <jrubio () dit ! upm ! es>
Date: 2003-12-27 22:01:55
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hello, I've been working on a patch for adding Route Server functionalities to Quagga.
The work is not yet complete, but the main features are ready, and I'm releasing a first
version so that anybody can test it and find possible bugs, make suggestions, etc.
The main idea is the following:
- For each peer configured as Route Server client (rsclient from now on) a separated
RIB (struct bgp_table) is mantained.
- For each announce the following is done:
IF (announcing neighbor is not a rsclient)
* Apply all 'IN' filters/route-maps/etc and (if not denied) insert it
into the 'NORMAL' table.
* FOR (each rsclient)
* Apply rsclient's 'IMPORT' policy (route-map) and (if not denied)
insert the announce into rsclient's table
ELSE // Announcing neighbor is a rsclient
* Apply all 'IN' filters/route-maps/etc and (if not denied) insert it
into the 'NORMAL' table.
* FOR (each rsclient)
* Apply announcer's 'EXPORT' policy (route-map).
If not denied then apply receiver's 'IMPORT' policy (route-map).
If not denied insert the announce into receiver rsclient's table.
The result is that the 'NORMAL' table contains the same routes that it would contain
without any peer configured as rsclient. And each of the rsclient's tables should
contain the same routes than the 'NORMAL' table of the corresponding rsclient would
contain in a full-mesh topology, where the 'IN' and 'OUT' policies of each rsclient
were the same as the 'IMPORT' and 'EXPORT' (respectively) policies for that peer in
the Route Server topology.
- Peers configured as rsclients receive announces only from their corresponding table, and
not from the 'NORMAL' table.
- To make possible that a single 'IMPORT' or 'EXPORT' route-map represents all the
separated 'IN' or 'OUT' (respectively) route-maps from the full-mesh topology, the
following statements have been added to the usual route-map sintaxis:
* 'match peer (A.B.C.D|X:X::X:X)' => This has a different behaviour depending on
the kind of route-map it appears in. For 'IMPORT'
route-maps it matches with the peer announcing the route.
For 'EXPORT' route-maps it matches with the peer into whose
table the announcement is being considered for insertion.
* 'call WORD' => Jumps to the route-map specified by WORD.
A sample configuration could be the following:
router bgp 65000
!
neighbor 1.1.1.1 remote-as 65001
neighbor 1.1.1.1 route-map PEER1-IMPORT import
neighbor 1.1.1.1 route-map PEER1-EXPORT export
neighbor 1.1.1.1 route-server-client
neighbor 1.1.1.1 soft-reconfiguration inbound
neighbor 1.1.1.1 activate
!
neighbor 2.2.2.2 remote-as 65002
neighbor 2.2.2.2 route-map PEER1-IMPORT import
neighbor 2.2.2.2 route-map PEER1-EXPORT export
neighbor 2.2.2.2 route-server-client
neighbor 2.2.2.2 soft-reconfiguration inbound
neighbor 2.2.2.2 activate
!
neighbor 3.3.3.3 remote-as 65003
neighbor 3.3.3.3 route-map PEER1-IMPORT import
neighbor 3.3.3.3 route-map PEER1-EXPORT export
neighbor 3.3.3.3 route-server-client
neighbor 3.3.3.3 soft-reconfiguration inbound
neighbor 3.3.3.3 activate
!
route-map PEER1-IMPORT permit 10
match 2.2.2.2
call PEER1-FROM-PEER2
route-map PEER1-IMPORT permit 20
match 3.3.3.3
call PEER1-FROM-PEER3
route-map PEER1-IMPORT deny 30
!
route-map PEER1-EXPORT permit 10
match peer2
call PEER1-TO-PEER2
route-map PEER1-EXPORT permit 20
match peer3
call PEER1-TO-PEER3
route-map PEER1-EXPORT deny 30
!
route-map PEER1-FROM-PEER2 ...
.
.
.
(and so on)
Other useful commands that I have added to Quagga are the following:
- 'show bgp rsclient summary' (and similarly for other address families)
This command shows a table resuming all the rsclients configured for the
cooresponding address family.
- 'show bgp rsclient (A.B.C.D|X:X::X:X)'
This commans show the RIB for the specified rsclient.
- 'clear bgp (A.B.C.D|X:X::X:X) rsclient'
This command can be used after changing some peer's policy for reconsidering
all announces from other peers with 'soft-reconfiguration' enabled (and also
'network ...' routes). I.E. If we change IMPORT policy for peer1, then we can
use the command "clear bgp peer1 rsclient" for reconsidering all the announces
from other peers (at least from other peers with 'soft-reconfiguration' enabled)
for insertion into peer1's table.
I hope I've explained myself quite clearly. Probably I've forgotten to talk about some
important issues, but this email is getting too long... :-)
Please ask/make any question/suggestion you have.
Any feedback is welcome!
Regards,
Jose
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1276" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hello, I've been working on a patch for adding
Route Server functionalities to Quagga.<BR>The work is not yet complete, but the
main features are ready, and I'm releasing a first </FONT></DIV>
<DIV><FONT face=Arial size=2>version so that anybody can test it and find
possible bugs, make suggestions, etc.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>The main idea is the following:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> - For each peer configured as Route Server
client (rsclient from now on) a separated<BR> RIB (struct
bgp_table) is mantained.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> - For each announce the following is
done:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> IF (announcing
neighbor is not a rsclient)</FONT></DIV>
<DIV><FONT face=Arial size=2> * Apply all
'IN' filters/route-maps/etc and (if not denied) insert
it <BR> into the
'NORMAL' table.<BR> * FOR (each
rsclient)<BR> * Apply
rsclient's 'IMPORT' policy (route-map) and (if not
denied) <BR>
insert the announce into rsclient's
table</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> ELSE // Announcing
neighbor is a rsclient<BR> * Apply all 'IN'
filters/route-maps/etc and (if not denied) insert it <BR>
into the 'NORMAL' table.<BR>
* FOR (each rsclient)<BR>
* Apply announcer's 'EXPORT' policy
(route-map). <BR>
If not denied then apply receiver's 'IMPORT'
policy (route-map).<BR>
If not denied insert the announce into receiver
rsclient's table.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> The result is that the 'NORMAL'
table contains the same routes that it would contain<BR>
without any peer configured as rsclient. And each of the rsclient's tables
should <BR> contain the same routes than the 'NORMAL' table of
the corresponding rsclient would <BR> contain in a full-mesh
topology, where the 'IN' and 'OUT' policies of each
rsclient<BR> were the same as the 'IMPORT' and 'EXPORT'
(respectively) policies for that peer in<BR> the Route Server
topology.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> - Peers configured as rsclients receive
announces only from their corresponding table, and<BR> not
from the 'NORMAL' table.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> - To make possible that a single 'IMPORT' or
'EXPORT' route-map represents all the <BR> separated 'IN' or
'OUT' (respectively) route-maps from the full-mesh topology,
the<BR> following statements have been added to the usual
route-map sintaxis:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> * 'match peer
(A.B.C.D|X:X::X:X)' => This has a different behaviour depending
on <BR> the kind of route-map it
appears in. For 'IMPORT' <BR>
route-maps it matches with the peer announcing the route.<BR>
For 'EXPORT' route-maps it matches with the peer into
whose<BR> table the announcement is being
considered for insertion.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> * 'call WORD' =>
Jumps to the route-map specified by WORD.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>A sample configuration could be the
following:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>router bgp 65000<BR>!<BR>neighbor 1.1.1.1 remote-as
65001<BR>neighbor 1.1.1.1 route-map PEER1-IMPORT import<BR>neighbor 1.1.1.1
route-map PEER1-EXPORT export<BR>neighbor 1.1.1.1
route-server-client<BR>neighbor 1.1.1.1 soft-reconfiguration inbound<BR>neighbor
1.1.1.1 activate<BR>!<BR>neighbor 2.2.2.2 remote-as 65002<BR>neighbor 2.2.2.2
route-map PEER1-IMPORT import<BR>neighbor 2.2.2.2 route-map PEER1-EXPORT
export<BR>neighbor 2.2.2.2 route-server-client<BR>neighbor 2.2.2.2
soft-reconfiguration inbound<BR>neighbor 2.2.2.2 activate<BR>!<BR>neighbor
3.3.3.3 remote-as 65003<BR>neighbor 3.3.3.3 route-map PEER1-IMPORT
import<BR>neighbor 3.3.3.3 route-map PEER1-EXPORT export<BR>neighbor 3.3.3.3
route-server-client<BR>neighbor 3.3.3.3 soft-reconfiguration inbound<BR>neighbor
3.3.3.3 activate<BR>!<BR>route-map PEER1-IMPORT permit 10<BR> match
2.2.2.2<BR> call PEER1-FROM-PEER2<BR>route-map PEER1-IMPORT permit
20<BR> match 3.3.3.3<BR> call PEER1-FROM-PEER3<BR>route-map
PEER1-IMPORT deny 30<BR>!<BR>route-map PEER1-EXPORT permit 10<BR> match
peer2<BR> call PEER1-TO-PEER2<BR>route-map PEER1-EXPORT permit
20<BR> match peer3<BR> call PEER1-TO-PEER3<BR>route-map PEER1-EXPORT
deny 30<BR>!<BR>route-map PEER1-FROM-PEER2 ...<BR>.<BR>.<BR>.<BR>(and so
on)</FONT></DIV>
<DIV> </DIV><FONT face=Arial size=2>
<DIV><BR>Other useful commands that I have added to Quagga are the
following:</DIV>
<DIV> </DIV>
<DIV> - 'show bgp rsclient summary' (and similarly for other address
families)<BR> This command shows a table resuming all the rsclients
configured for the <BR> cooresponding address family.</DIV>
<DIV> </DIV>
<DIV> - 'show bgp rsclient (A.B.C.D|X:X::X:X)' <BR> This commans
show the RIB for the specified rsclient.</DIV>
<DIV> </DIV>
<DIV> - 'clear bgp (A.B.C.D|X:X::X:X) rsclient'<BR> This command
can be used after changing some peer's policy for
reconsidering<BR> all announces from other peers with
'soft-reconfiguration' enabled (and also<BR> 'network ...' routes).
I.E. If we change IMPORT policy for peer1, then we can<BR> use the
command "clear bgp peer1 rsclient" for reconsidering all the
announces<BR> from other peers (at least from other peers with
'soft-reconfiguration' enabled)<BR> for insertion into peer1's
table.</DIV>
<DIV> </DIV>
<DIV>I hope I've explained myself quite clearly. Probably I've forgotten to talk
about some </DIV>
<DIV>important issues, but this email is getting too long... :-)<BR>Please
ask/make any question/suggestion you have.</DIV>
<DIV> </DIV>
<DIV>Any feedback is welcome!</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV> </DIV>
<DIV> Jose</FONT></DIV></BODY></HTML>
["quagga-route-server_0.1.patch.gz" (application/x-gzip)]
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic