Friday 29 February 2008

Forming the Aggregate Based on a subset of specific routes

In this example we create an aggregate on a limited set of prefixes. This is not to be confused with the "aggregate plus a subset of more-specific prefixes" as shown with suppress maps in a previous post.

Set up the aggregate map to select only 192.68.10.0.24 via a route-map

RTA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RTA(config)#no route-map SET_ATTRIBUTE
RTA(config)#route-map SELECT_MORE_SPECIFIC_ROUTES permit 10
RTA(config-route-map)#match ip add 1
RTA(config-route-map)#acces 1 permit 192.68.10.0 0.0.0.255
RTA(config)#router bgp 3
RTA(config-router)#$0.0 255.255.0.0 as-set adv SELECT_MORE_SPECIFIC_ROUTES
RTA(config-router)#end
RTA#


In the above config:
RTA(config-router)#$0.0 255.255.0.0 as-set adv SELECT_MORE_SPECIFIC_ROUTES

has been trunctuated and the full command is:
aggregate-address 192.68.0.0 255.255.0.0 as-set adv SELECT_MORE_SPECIFIC_ROUTES

Below you will see BGP shows the aggregates path as only 2, where previously we were aggregating addresses also for AS 1.

RTA#sh ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0/16, version 16
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.16.1.2 172.16.20.1 172.16.220.2
2, (aggregated by 3 172.16.2.254)
0.0.0.0 from 0.0.0.0 (172.16.2.254)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
RTA#


This means that the aggregate can now be advertised to AS 1 because the AS_PATH does not include AS 1. AS 2 will not be able to receive the aggregate.

Saturday 23 February 2008

Changing the aggregates attributes

In some situations, changing the aggregate's attributes is required. The example in this post shows one scenario in which this could be useful.

As you have already seen, the aggregate can carry information about the individual elements if configured with the AS_SET option. If one or more of the routes forming the AS_SET aggregate are configured with no-export community attribute, the aggregate itself will carry the same attribute. his will prevent the aggregate from being exported. To remedy this situation, you can modify the community attribute of the aggregate by using what Cisco calls an attribute map, another form of a route map that applies only to aggregates.

Setup: As Figure 11-13 in Chapter 11 of Internet Routing Architectures.

First we configure RTC to send the Community: no-export attribute

RTC(config)#router bgp 1
RTC(config-router)#no neighb 192.68.6.1 send-comm
RTC(config-router)#neighb 172.16.20.2 send-comm
RTC(config-router)#neighb 172.16.20.2 route-map SETCOMMUNITY out
RTC(config-router)#exit
RTC(config)#acces
RTC(config)#access-list 1 permit 192.68.11.0 0.0.0.255
RTC(config)#route-map SETCOMMUNITY
RTC(config-route-map)#route-map SETCOMMUNITY permit 10
RTC(config-route-map)#match ip add 1
RTC(config-route-map)#set community no-export
RTC(config-route-map)#route-map SETCOMMUNITY permit 20
RTC(config-route-map)#


Before we go any futher, make sure RTA is picking up this attribute.

RTA>sh ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0/16, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Flag: 0x880
Advertised to non peer-group peers:
172.16.1.2
{2,1}, (aggregated by 3 172.16.2.254)
0.0.0.0 from 0.0.0.0 (172.16.2.254)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
Community: no-export



"Community: no-export" confirms that it is, but this is not what we want so configure RTA to set up a attribute-map to specify the attribute to send ie; "community: none".

RTA# conf t
Enter configuration commands, one per line. End with CNTL/Z.
RTA(config)#route-map SET_ATTRIBUTE permit 10
RTA(config-route-map)#set community none
RTA(config-route-map)#router bgp 3
RTA(config-router)#agg 192.68.0.0 255.255.0.0 as-set attribute-map SET_ATTRIBUTE
RTA(config-router)#end
RTA#


Have a look now on RTA!


RTA#sh ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0/16, version 15
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.16.1.2 172.16.20.1 172.16.220.2
{2,1}, (aggregated by 3 172.16.2.254)
0.0.0.0 from 0.0.0.0 (172.16.2.254)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
RTA#


No longer do we have the "community: no export" attribute.

Wednesday 20 February 2008

Loss of information inside aggregates

When an Aggregate is sent we lose the finer granularity of the actual AS Paths to the Aggregated prefixes.

Using AS_SET we can advertise the AS path information that would normally not be sent in an aggregate advertisement.

We setup our network as shown in Figure 11-13 of Internet Routing architectures in chapter 11.

The only new command we encounter is an option appended to the aggregate-address command under Router BGP configuration.

RTA(config)#aggregate-address 192.68.0.0 255.255.0.0 as-set


Cleaning up we run the following commands on routers RTA & RTF:

RTA(config)#no route-map SUPPRESS/ALLOW
RTA(config)#no access-list 1
RTA(config)#no aggregate-address 172.16.0.0 255.255.0.0


Before we use the as_set option, just add the aggregate-address command and view the BGP table on router RTK.

RTA(config)#aggregate-address 192.68.0.0 255.255.0.0

RTK>sh ip bgp
BGP table version is 18, local router ID is 172.16.220.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 172.16.220.1 0 0 3 i
*> 172.16.20.0/24 172.16.220.1 0 0 3 i
*> 172.16.65.0/26 172.16.220.1 0 3 i
* 172.16.220.0/24 172.16.220.1 0 0 3 i
*> 0.0.0.0 0 32768 i
*> 192.68.0.0/16 172.16.220.1 0 0 3 i
*> 192.68.5.0 172.16.220.1 0 3 i
*> 192.68.10.0 172.16.220.1 0 3 2 i
*> 192.68.11.0 172.16.220.1 0 3 1 i



Notice, the 192.68.0.0 aggregate address only shows AS 3 in the path, when in fact the more specific 192.68.0.0 networks reach into AS 1 & AS 2.

Apply the as_set option and review the changes.

RTA(config)#aggregate-address 192.68.0.0 255.255.0.0 as-set

RTK>sh ip bgp
BGP table version is 19, local router ID is 172.16.220.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 172.16.220.1 0 0 3 i
*> 172.16.20.0/24 172.16.220.1 0 0 3 i
*> 172.16.65.0/26 172.16.220.1 0 3 i
* 172.16.220.0/24 172.16.220.1 0 0 3 i
*> 0.0.0.0 0 32768 i
*> 192.68.0.0/16 172.16.220.1 0 0 3 {2,1} i
*> 192.68.5.0 172.16.220.1 0 3 i
*> 192.68.10.0 172.16.220.1 0 3 2 i
*> 192.68.11.0 172.16.220.1 0 3 1 i
RTK>

You will notice how the aggregate 192.68.0.0/16 changes to include a SET{2,1} within its path information.This indicates that the aggregate actually summarizes routes that have passed via ASs 1 or 2. The AS_SET information becomes important in avoiding routing loops because it keeps an indication of where the route has been.

Given that the aggregate with the AS_SET contains information about each individual route, that is summarized, changes in the individual route will cause the aggregate to be updated. In the example if 192.68.11.0/24 goes down, the path information of the aggregate will change from 3{3,1} to 3 2, and the aggregate will be updated. It the aggregate summarizes 100's or 1000's of routes , the aggregate will constantly be oscillating if the rotes forming the aggregate are unstable.

Friday 15 February 2008

Aggregate with a subset of more specific routes

Unlike in the Aggregate plus more specific routes post, we will limit the prefixes that are leaked as opposed to leaking all the prefixes covered by that specific aggregate.

We use a special type of route-map here called “suppress-maps” to permit or deny more specific routes of an aggregate to be sent.

Setup: Again this is based on the examples in Chapter 11 of Internet Routing Architectures.

Let's clean up from the previous post by stripping the route-map SETNOEXPORT route-map on RTA & RTF

RTA(config)#no route-map SETNOEXPORT out
RTA(config)#no access-list 101
RTA(config-router)#no neighbor 172.16.20.1 send-community
RTA(config-router)#no neighbor 172.16.20.1 route-map SETNOEXPORT out


Next, RTF needs to advertise RTA’s 172.16.220.0 route in BGP & RTA needs to advertise RTF’s 172.16.65.0 route in BGP. In AS 3’s IBGP, these will be suppressed via the bgp suppress-map so they need to be originated from the routers IGP, in this instance OSPF.

Create our suppress-map and access-lists. Adjust our aggregate-address commands:

On RTA:

Aggregate-address 172.16.0.0 255.255.0.0 suppress-map SUPPRESS

access-list 1 permit 172.16.220.0 0.0.0.255
access-list 1 deny any

route-map SUPPRESS permit 10
match ip address 1

On RTF:
Aggregate-address 172.16.0.0 255.255.0.0 suppress-map ALLOW

access-list 1 deny 172.16.220.0 0.0.0.255
access-list 1 permit any

route-map ALLOW permit 10
match ip address 1


You'll see we can easily control updates for network 172.16.220.0 with SUPPRESS & ALLOW route-maps. In RTA we "PERMIT network 172.16.220.0 to be SUPPRESSED", this means this route will not be advertised. Vis-à-vis RTF will "DENY 172.16.220.0 to be SUPPRESSED" , this means the route will be advertised.

Below is output from Show ip bgp on RTA, note how route 172.16.220.0 is marked with "s for Suppressed".

RTA#sh ip bgp
BGP table version is 16, local router ID is 172.16.2.254
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i172.16.0.0 172.16.1.2 0 100 0 i
*> 0.0.0.0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.20.0/24 0.0.0.0 0 32768 i
s i172.16.220.0/24 172.16.1.2 74 100 0 i
s> 0.0.0.0 0 32768 i
*>i192.68.5.0 172.16.1.2 0 100 0 i
* 172.16.20.1 0 1 i
* i192.68.6.0 172.16.1.2 0 100 0 1 i
*> 172.16.20.1 0 0 1 i
RTA#


A traceroute from RTC, as setup in the Internet Routing Architectures example will reveal the route to 172.16.220.0

RTC>traceroute 172.16.220.1

Type escape sequence to abort.
Tracing the route to 172.16.220.1

1 192.68.6.1 12 msec 16 msec 12 msec
2 192.68.5.1 28 msec 28 msec 28 msec
3 172.16.1.1 [AS 3] 28 msec * 24 msec
RTC>

Tuesday 12 February 2008

Aggregate plus more specific routes

In some cases, more-specific routes, in addition to the aggregate, need to be passed (leaked) to a neighbouring AS. This is usually done in a Customer AS multihomed to a single provider. The Provider AS that gets the more-specific routes from the Customer AS would be able to make a better decision about which way to reach the route within the Customer AS.

Setup: Network Topology & configuration as in Chapter 11 - Internet Routing Architectures. I will cover basics of configuration & theory of this example.

Our starting configuration will list the networks we wish to advertise via BGP. This is determined with the network command under BGP configuration.
Next, on each of the Customer AS EBGP routers, configure BGP to send the aggregate network.

Aggregate-address 172.16.0.0 255.255.0.0


Note that we have not included the "summary-only" option, so both the aggregate and more-specific will be advertised.

We have seen on the Aggregate only, suppressing more specific routes post, what we would expect to see in the neighbours BGP table, however, we would also now see the more specific routes.

What is important now is that these more-specific routes do not leak further into the Internet, upstream of the Provider AS. We will do this with the Community attribute.

With the "community: no-export" attribute the Customer AS Routers can instruct the Provider AS Routers to export only the aggregate and not the more-specific routes upstream. This reduces the Internet BGP Table as the Provider AS will only advertise aggregates for all the networks under its control.

Community No-Export Configuration:

Under our Customer AS BGP Configuration we first need to establish our Provider AS neighbours to receive community attribute advertisements.
By default, BGP community attributes are not advertised to peers. The "neighbour send-community" command enables the sending of BGP community attributes to BGP peers.

Neighbour 192.68.5.2 send-community

Then, we set up an access list to catch the addresses we are interested in.

access-list 101 permit ip 172.16.0.0 0.0.255.255 host 255.255.0.0

The host 255.255.0.0 makes sure nothing more-specific than 172.16.0.0 is let through.

Next, we set up a route-map to tag the more-specific routes with the community no-export attribute.

Route-map SETNOEXPORT permit 10
Match ip address 101
Route-map SETNOEXPORT permit 20
Set community no-export

Finally in our Customer AS BGP configuration we apply the route-map

Neighbour 192.68.5.2 route-map SETNOEXPORT out


All seems good and well and if you even run "show ip bgp" on an upstream (from the provider) router you might even get a nicely aggregated route to the 172.16.0.0 networks or you might not.

The reason routes could be leaking into the Internet is because the nature of the community attribute is that of an optional transitive attribute. This means we have to decide on each router whether we will pass the community attribute. As it stands, one of our multihomed routers in the Provider AS is passing on the routes to the Provider AS EBGP neighbor via IBGP and then if these are the best routes to the specific networks BGP will propagate these upstream.

Though my working example (yours may differ), the route being propagated upstream has the community attribute set. This is because that route so happens to be deemed as the best. However, the backup routes community is not set. If this alternative route were to become the best route, the more-specific route it describes would be propagated upstream. Bad!

I garnered this information by the command "sh ip bgp 172.16.20.0.0" ( a network in the aggregate I am advertising).

RTD>sh ip bgp 172.16.20.0
BGP routing table entry for 172.16.20.0/24, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Advertised to non peer-group peers:
192.68.6.2
3
192.68.5.1 from 192.68.5.1 (192.68.5.1)
Origin IGP, localpref 100, valid, external, best
Community: no-export
3
172.16.20.2 from 192.68.6.2 (192.68.11.1)
Origin IGP, metric 0, localpref 100, valid, internal

See! The back up route does not have the community set. Bad!

On our BGP Neighbors in the Provider AS we need to propagate the community attribute to the Provider AS EBGP neighbour.

Neighbour 192.68.6.1 send-community


RTD>sh ip bgp 172.16.20.0
BGP routing table entry for 172.16.20.0/24, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Advertised to non peer-group peers:
192.68.6.2
3
192.68.5.1 from 192.68.5.1 (192.68.5.1)
Origin IGP, localpref 100, valid, external, best
Community: no-export
3
172.16.20.2 from 192.68.6.2 (192.68.11.1)
Origin IGP, metric 0, localpref 100, valid, internal
Community: no-export
RTD>

See! Both routes are now part of the community. Good!

Monday 11 February 2008

Aggregate only, suppressing more specific routes

Setup: This example network is based on the topology outlined on page 343 of Internet Routing Architectures.

First we look at the BGP Table without aggregates or any summary.

RTC>sh ip bgp
BGP table version is 27, local router ID is 192.68.11.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 192.68.6.1 0 2 3 i
*> 172.16.65.0/26 192.68.6.1 0 2 3 i
*> 172.16.220.0/24 192.68.6.1 0 2 3 i
*> 192.68.10.0 192.68.6.1 0 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i


In our example we have three "172.16.0.0" networks that we will aggregate with the command:

aggregate-address 172.16.0.0 255.255.0.0 summary-only


The "summary only" option makes sure no more-specific routes than the aggregate will be advertised.

You do not need to "clear ip bgp address soft out" for this to take effect as you would with a route-map.

Let’s have a look at the new BGP table on our BGP neighbour.

RTC>sh ip bgp
BGP table version is 30, local router ID is 192.68.11.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* 172.16.0.0 192.68.6.1 0 2 3 i
*> 172.16.20.2 0 0 3 i
*> 192.68.10.0 192.68.6.1 0 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i


As we expected, a reduced BGP table. We can discover further information about our aggregate network with the "show ip bgp address" command.

RTC>sh ip bgp 172.16.0.0
BGP routing table entry for 172.16.0.0/16, version 15
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.68.6.1
2 3, (aggregated by 3 192.68.5.1)
192.68.6.1 from 192.68.6.1 (192.68.10.1)
Origin IGP, localpref 100, valid, external, atomic-aggregate
3, (aggregated by 3 172.16.2.254)
172.16.20.2 from 172.16.20.2 (172.16.2.254)
Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best
RTC>


This gives us details of the "atomic-aggregate" attribute and which AS and Router it was set by.

Static Routes into BGP

Rather than the above example which relied on dynamic routing with each network defined in the routers BGP configuration a static route can be set.

With the following commands we will remove the aggregate configuration & networks.

RTF#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RTF(config)#router bgp 3
RTF(config-router)#no aggregate-address 172.16.0.0 255.255.0.0 summary-only
RTF(config-router)#no network 172.16.1.0 255.255.255.0
RTF(config-router)#no network 172.16.65.0 255.255.255.192
RTF(config-router)#no network 172.16.220.0 255.255.255.0


Then install a network that advertises the aggregate address.

RTF(config-router)#network 172.16.0.0
RTF(config-router)#exit


Along with a static address.

RTF(config)#ip route 172.16.0.0 255.255.0.0 null0
RTF(config)#end


Remember with BGP, the process will only advertise a network that is in the ip routing table so we need to add the static ip route so it appears in the said routing table. The null0 interface ensures that if the 172.16.0.0 network router has no knowledge of more-specific routes than the traffic is sent to the "bit bucket" rather than possibly creating a routing loop.

We can run the show ip bgp commands from our neighbour router to verify our configurations. The basic "show ip bgp" will give us the same table as our aggregated table, however if we "show ip bgp 172.16.0.0" you will notice the lack of atomic-aggregate attributes.

You can auto-magically aggregate address with the "auto-summary" command under Cisco BGP configuration but not in Zebra/Quagga so it’s probably better not to. Plus I find it more re-assuring to have the aggregate looking back at me when I’m scanning through the runn/start conf.

Sunday 10 February 2008

BGP-4 Aggregation

A route aggregate is a route advertisement that has consolidated contiguous networks.

For instance;

Networks: (192.168.1.0/24, 192.168.2.0/24, …192.168.254.0/24, 192.168.255.0/24)

Aggregate: 192.168.0.0/16

Rather then processing 256 networks, a single aggregate network address that covers all the networks can be advertised. Aggregates vastly reduce the Internet Routing Table size.

The following posts are taken from the book “Internet Routing Architectures”. These examples demonstrate different methods of aggregation that are seen on the Internet. The way aggregates are formed and advertised and whether they carry with them more specific routes will influence traffic patterns and sizes of BGP routing tables. Remember that aggregation applies to routes that exist in the BGP routing table. An aggregate can be sent if at least one more-specific route of that aggregate exists in the BGP table.

Aggregate only, suppressing more specific routes:

Aggregate plus more specific routes:

Aggregate with a subset of more specific routes:

Loss of information inside aggregates:

Changing the aggregates attributes:

Forming the Aggregate Based on a subset of specific routes

Thursday 31 January 2008

Multi Router Looking Glass

Objective: create a web interface for viewing routing tables and other routing commands.

I have chosen John Fraizer's Multi Router Looking Glass (a working example can be seen at RIPE's Routing Information Service page). The latest version of the software can be downloaded at: http://www.op-sec.us/mrlg/source/CURRENT/ .
Basically the software consists of a cgi script to place in your apache server cgi-bin and a couple of perl & bash scripts. There is also code to make fastping, an alternative to ping. I just used plain old ping in my setup.

CPAN Perl Module: First thing we need is the Perl "Network::Telent::Cisco" module to allow the main script to communicate via telnet to our network equipment. SSH is available via the "Network::SSH::Perl" module, however I will not cover this here.

Access your CPAN shell:

$ perl -MCPAN -e shell
cpan>


Note: If this is the first time you have run this command you will have to configure CPAN.

Now install "Network::Telnet::Cisco" module.

cpan> install Net::Telnet::Cisco



With this done all we need is a little file keeping to get our program into place. From our downloaded and extracted tar.gz folder issue the following commands:

cp index.cgi /usr/local/www/apache22/cgi-bin/
chmod +x /usr/local/www/apache22/cgi-bin/index.cgi
cp fping1 ztr ztraceroute /usr/local/bin
chmod +x /usr/local/bin/fping1 /usr/local/bin/ztr /usr/local/bin/ztraceroute
cp mrlg.conf.sample /etc/mrlg.conf


Note: These are for FreeBSD, your directory structure may vary.
Now, we need to edit fping1, ztr & ztraceroute to make sure all paths within these files are correct for your system. For FreeBSD I had to edit paths to bash & traceroute, also exchange fastping for ping and its's correct path.

mrlg.conf set up:
To get anything out of your index.cgi, ie. MRLG, you need to config /etc/mrlg.conf.
First, we have to tell MRLG the host details we will be running MRLG on.

## Set the URL for the location of the looking-glass....
$::url="http://10.1.1.3/cgi-bin/index.cgi";


Secondly, we can amend a router to the details of one of our local routers.


$::Routers{'Folkestone-AS2'} = {
comment => 'Cisco 2600 Series',
server => '10.1.1.2',
use_port => '23',
login_pass => 'cisco',
full_tables => '1',
cisco => '1',
debug => "0",
};



That is all we need to get an interface into our routers as demonstrated below.



The conf file has lots of settings not discussed here but which can be very useful so I would advise this be your first point of call if you decide to install MRLG.
Phil

Tuesday 29 January 2008

pman - generate man pages in pdf format on OSX

Generate PDF man files in OSX

Drop the following code in your profile, log out & log back in and man your favourite manpage but use 'pman' this time.

pman()
{
man -t "${1}" | open -f -a /Applications/Preview.app/
}


You'll be presented a PDF document of your man page when you can refer to anytime, complete with search, zoom and anything else you can do with a pdf.

..

comserv for OS X - Leopard


comserv for leopard
About a year ago I was using comserv on a BSD box hooked up to a Xyplex terminal access server. This gave me native access to the serial ports on the terminal server, so I could do a simple "cu -l /usr/local/comserv/dev/xport01" to connect to a router or switch or what have you.

I have been considering a MacBook, and one of the programs I would love to have would be comserv. I had a look around the pkg repositories but no luck! It was a case of rolling my own.

After a little bit of compiling and package hacking I have got a fully working OSX package: comserv.pkg

After a simple double click install, all that is needed is to:

sudo cp /usr/local/etc/comservd.conf.sample /usr/local/etc/comservd.conf

sudo vi /usr/local/etc/comservd.conf
ammend to your liking:

sudo vi /etc/hostconfig
append: COMSERVD=-YES-


and that is it, comservd starts up on reboot and gives you access to all those ports.
If you can't wait to reboot.
sudo SystemStarter start COMSERVD


comservd conf help is available under the installed man page. Even better 'pman' comservd. Also, it is complete with an uninstall.sh script.

enjoy

Saturday 12 January 2008

md5 checksums in solaris

md5sum = digest -v -a md5

example:
# digest -v -a md5 /export/home/philip/Desktop/sol-nv-b70b-x86-dvd-iso-b
md5 (/export/home/philip/Desktop/sol-nv-b70b-x86-dvd-iso-b) = 5218cdcd46c023a0f074c6696403a722
#


alias alleviates the aggravation of transcendence:

# alias md5sum='digest -v -a md5'
# md5sum /export/home/philip/Desktop/sol-nv-b70b-x86-dvd-iso-b
md5 (/export/home/philip/Desktop/sol-nv-b70b-x86-dvd-iso-b) = 5218cdcd46c023a0f074c6696403a722
#

Monday 7 January 2008

BGP Peer Groups on Quagga

Objective: To set up a "peer-group" on our Quagga router to limit advertisements within an Autonomous System.

Setup: Refer to previous post "Headless BSD Quagga Router" to get you started.

Under the running config on the quagga router I have formed the peer group 'localAS' for AS3 with the following command:

neighbor localAS remote-as 3


next I include the neighbors I wish to be in the peer-group:

neighbor 172.16.1.2 peer-group localAS
neighbor 192.68.1.1 peer-group localAS


It is the same as declaring a normal neighbor however I use the 'peer-group' option. The 'remote-as' option is not needed, as in the preceding command 'neighbor localAS remote-as 3' confirms which remote the peer-group is in.

Excerpt on BGP Technology from Cisco Systems:

The major benefit you achieve when you specify a BGP peer group is that a BGP peer group reduces the amount of system resources (CPU and memory) necessary in an update generation. A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. Based on the number of peer group members, the number of prefixes in the table, and the number of prefixes advertised, this can significantly reduce the load.

BGP peer groups also simplifies the BGP configuration. Instead of configuring each neighbor with the same policy individually, a peer group allows you to group the policies which can be applied to individual peers thus making efficient update calculation along with simplified configuration.

..

Tuesday 1 January 2008

grep trick

Small hint shown to me many years ago when enabling things in rc.conf.
If I want to startup ipfilter for example (trimmed to avoid wrapping).

bash-2.05b# cat /etc/defaults/rc.conf | grep ^ipfilter

Returns the following,
ipfilter_enable="NO" # Set to YES to enable ipfilter
ipfilter_program="/sbin/ipf" # where the ipfilter program lives
ipfilter_rules="/etc/ipf.rules" # rules definition file for ipfilter,
ipfilter_flags="" # additional flags for ipfilter

If it looks like what you want then write it into your running rc.conf,

cat /etc/defaults/rc.conf | grep ^ipfilter >> /etc/rc.conf

Then you can edit to enable, add flags, etc. Cures the typos.

DAve
http://lists.freebsd.org/pipermail/freebsd-questions/2007-December/165704.html