Saturday 29 December 2007

Headless BSD Quagga Router

Objective Get an old box running as a bgp router for lab exercises.

Install a minimum installation of FreeBSD. See previous post for installation media.
Of note, My "Hard Drive" I am using for installation, is a 1gb Compact Flash Card, so to reduce "writes" to this I have not partitioned a "swap" space.

Also regards a headless install don't forget when asked if there are any last configurations you need to preform choose yes and navigate to the "TTYs" menu item. From here you need to edit thr /etc/ttys file.

scroll down to serial terminals section and edit so you can log on via the first serial console:
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyd0 "/usr/libexec/getty std.9600" xterm on secure

so on reboot we should be at a login prompt.

Quagga Installation:
FreeBSD2# pkg_add -r quagga
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/quagga.tbz... Done.
Added group "quagga".
Added user "quagga".
FreeBSD2#

Quagga is installed but we need two config files written to operate as a BGP router.
These go in /usr/local/etc/quagga/ and are "zebra.conf"
!
! Zebra configuration saved from vty
! 2007/12/22 22:25:59
!
hostname zebraBSD1
password zebra
enable password zebra
log stdout
!
debug zebra events
!
interface fxp0
ip address 10.2.2.2/24
ipv6 nd suppress-ra
!
interface fxp1
ipv6 nd suppress-ra
!
interface fxp2
ipv6 nd suppress-ra
!
interface lo0
!
interface plip0
ipv6 nd suppress-ra
!
!
line vty
password zebra
!

and "bgpd.conf"
!
!zebra BGP conf file
!
router bgp 65001
!
line vty
password zebra
!

now run zebra and bgpd as daemons.
freebsd1# zebra -d
2007/12/29 19:12:39 ZEBRA: MESSAGE: ZEBRA_INTERFACE_ADDRESS_ADD 10.2.2.2/24 on fxp0
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
2007/12/29 19:12:39 ZEBRA: rib_queue_add_qnode: work queue added
freebsd1# bgpd -d
freebsd1#

To access Quagga/zebra:
freebsd1# telnet localhost 2601
Trying ::1...
Connected to localhost.
Escape character is '^]'.

Hello, this is Quagga (version 0.99.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.


User Access Verification

Password:
zebraBSD1> exit
Connection closed by foreign host.

To access Quagga/bgpd:
freebsd1# telnet localhost 2605
Trying ::1...
Connected to localhost.
Escape character is '^]'.

Hello, this is Quagga (version 0.99.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.


User Access Verification

Password:
zebraBSD1> exit
Connection closed by foreign host.
freebsd1#


but you probably thinking this is going to be a hassle having to telnet into each daemon. Well the good news is quagga ships with a "vtysh". This enables one login for all daemons.
FreeBSD2# vtysh

Hello, this is Quagga (version 0.99.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

best of all you get your trace and ping commands back!
FreeBSD2.home# ping 172.16.1.2
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=253 time=25.635 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=253 time=25.425 ms
64 bytes from 172.16.1.2: icmp_seq=2 ttl=253 time=25.575 ms
64 by^C
--- 172.16.1.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 25.399/25.509/25.635/0.099 ms
FreeBSD2.home# trace 172.16.1.2
traceroute to 172.16.1.2 (172.16.1.2), 64 hops max, 40 byte packets
1 172.99.1.2 (172.99.1.2) 1.365 ms 1.306 ms 1.283 ms
2 172.16.20.2 (172.16.20.2) 15.764 ms 15.719 ms 15.741 ms
3 172.16.1.2 (172.16.1.2) 16.314 ms * 16.326 ms
FreeBSD2.home#


now, vi /etc/rc.conf to enable zebra & routing daemons on startup.
freebsd1# vi /etc/rc.conf

quagga_enable="YES"
quagga_daemons="zebra bgpd"


oh, and if you really want to forward packets, you will also have to add the following to /etc/rc.conf to enable FreeBSD as a router.

gateway_enable="YES"


bada bing!

Friday 28 December 2007

Headless FreeBSD Installation CD

Objective To create a bootable FreeBSD cd that will output to serial console. I had been previously creating headless BSD boot floppies however the preperarion & installation is quicker via cd.

on FreeBSD 5:
mdconfig -a -t vnode -f /path/to/image.iso -u 1

mount the device file.
mount -t cd9660 /dev/md1 /mnt/

on solaris:
mount 6.2-RELEASE-i386-bootonly.iso to a device file.
# lofiadm -a /export/home/philip/Desktop/6.2-RELEASE-i386-bootonly.iso /dev/lofi/1

mount the device file.
#mount -T hsfs /dev/lofi/1 /mnt

Once mounted: copy entire contents of cd to ~/Desktop/headlessBSD.
# cp -R /mnt /export/home/philip/Desktop/headlessBSD

edit loader.rc to output to serial port.
vi /export/home/philip/Desktop/headlessBSD/mnt/boot/loader.rc
"/export/home/philip/Desktop/headlessBSD/mnt/boot/loader.rc" [Read only] 17 lines, 389 characters
\ Loader.rc
\ $FreeBSD: src/sys/boot/i386/loader/loader.rc,v 1.4.2.1 2005/10/30 14:37:02 scottl Exp $
\
\ Set output to serial port
set console="comconsole"
\ Includes additional commands
include /boot/loader.4th

\ Reads and processes loader.conf variables
start

\ Tests for password -- executes autoboot first if a password was defined
check-password

\ Load in the boot menu
include /boot/beastie.4th

\ Start the boot menu
beastie-start

make an iso file from ammended headlessBSD folder. This will output headlessBSD.iso in home directory.
# mkisofs -U -no-emul-boot -b boot/cdboot -o /export/home/philip/headlessBSD.iso /export/home/philip/headlessBSD/mnt/
Warning: creating filesystem that does not conform to ISO-9660.
Size of boot image is 4 sectors -> No emulation
40.38% done, estimate finish Fri Dec 28 19:39:21 2007
80.77% done, estimate finish Fri Dec 28 19:39:22 2007
Total translation table size: 2048
Total rockridge attributes bytes: 0
Total directory bytes: 26624
Path table size(bytes): 68
Max brk space used 78000
12381 extents written (24 MB)


Burn ~/headlessBSD.iso to cd to create bootable headless BSD installation disc.

Sunday 23 December 2007

BGP Summarization and Path-Selection

Objective In the previous exercises we have set up an inter-network spanning several AS’s. BGP is routing advertisement for several networks as you will have verified in with different “show ip” commands. Although it is not a large amount of advertisements, we can slim down our routing table with “Route Aggregation”. In larger networks aggregation is imperative.


Download Equipment list, configuration files and network topology. ccnp-c9t1.zip

Setup
This exercise starts where "Configuring Full-Mesh IBGP" ended. Above is a link to the completed config files of the "Configuring Full-Mesh IBGP" exercise. You may have to bring up some interfaces. Run “show ip interface brief” to work out which.

In this exercise it is a matter of only running one command on the edge routers and then discovering how this affects the networks.

On the edge routers, summarize the pod network to 10.1.0.0/16 to the core AS’s using the “aggregate-address” command with the “summary-only” option. You do not need to include the loopback interfaces of the internal routers in the summary.
P1R1(config-router)#aggregate-address 10.1.0.0 255.255.0.0 summary-only
P1R1(config-router)#end

Telnet to either of the backbone routers. Now, have a look at the routing tables. Can you see where the aggregate address is for your pod?

The following output is from the BBR2 router.
BBR2>sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.31.0.0/16 is variably subnetted, 3 subnets, 2 masks
B 172.31.1.0/24 [20/0] via 10.254.0.1, 05:43:37
R 172.31.0.0/16 [120/1] via 10.254.0.1, 00:00:29, Ethernet0/0
C 172.31.11.0/24 is directly connected, Serial0/0.1
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.97.97.0/24 [20/0] via 10.254.0.3, 06:25:30
B 10.1.0.0/16 [20/0] via 172.31.11.1, 00:07:39
C 10.254.0.0/24 is directly connected, Ethernet0/0
BBR2>

Can you still ping the internal routers from the backbone?
BBR1#ping 10.1.3.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/50/52 ms
BBR1#

With the summary-only option, the more specific routes are suppressed. This is indicated in the BGP table with the “s” character at the start of the line.
P1R1>sh ip bgp
BGP table version is 18, local router ID is 10.200.200.11
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
s> 10.1.0.0/24 0.0.0.0 0 32768 i
* i10.1.0.0/16 10.1.0.2 0 100 0 i
*> 0.0.0.0 32768 i
s> 10.1.1.0/24 0.0.0.0 0 32768 i
s> 10.1.2.0/24 10.1.1.3 2 32768 i
s> 10.1.3.0/24 10.1.1.3 1 32768 i
* i10.97.97.0/24 172.31.11.4 0 100 0 64999 64997 i
* 172.31.11.4 0 64999 64997 i
*> 172.31.1.3 0 64998 64997 i
* i10.254.0.0/24 172.31.1.3 0 100 0 64998 i
* 172.31.11.4 0 64999 64998 i
*> 172.31.1.3 0 0 64998 i
r i172.31.1.0/24 172.31.1.3 0 100 0 64998 i
r 172.31.11.4 0 64999 64998 i
r> 172.31.1.3 0 0 64998 i
r i172.31.11.0/24 172.31.11.4 0 100 0 64999 i
r> 172.31.11.4 0 0 64999 i
Network Next Hop Metric LocPrf Weight Path
r 172.31.1.3 0 64998 64999 i
P1R1>

Path-Selection:

You’ll notice in the BGP Table there are 3 routes to the 10.97.97.0 network.
* i10.97.97.0/24 172.31.11.4 0 100 0 64999 64997 i
* 172.31.11.4 0 64999 64997 i
*> 172.31.1.3 0 64998 64997 i

I’ll use these routes as an opportunity to run over route selection briefly and introduce the “show ip bgp network” command.
P1R1>sh ip bgp 10.97.97.0
BGP routing table entry for 10.97.97.0/24, version 4
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.0.2 10.200.200.13 10.200.200.14 172.31.11.4
64999 64997
172.31.11.4 from 10.1.0.2 (10.200.200.12)
Origin IGP, metric 0, localpref 100, valid, internal
64999 64997
172.31.11.4 from 172.31.11.4 (172.31.22.4)
Origin IGP, localpref 100, valid, external
64998 64997
172.31.1.3 from 172.31.1.3 (172.31.2.3)
Origin IGP, localpref 100, valid, external, best
P1R1>

The weight & local preference are the same for all routes so this does not decide on route selection. Nor are any of the routes originated from the local router.
All the AS paths are the same length, as are the origin codes & the MED’s.

Therefore the path-selection process looks at EBGP vs IBGP with a preference to EBGP. Finally one of the candidates is eliminated as it has an “internal” reference. Two routes are left and at this stage the path-selection process chooses the router with the lowest neighbor BGP route-id. The route through 172.31.1.3 is preferred over the route through 172.31.11.4

Configuring Full-mesh IBGP

Configuring Full-Mesh IBGP

Objective In the previous exercise you will remember the internal routers of our pod did not learn of external routes, but used default routes to lead them towards the frame switch. In this exercise we will set up Full-Mesh IBGP so our pod learns routes via BGP.

Download Equipment list, configuration files and network topology. ccnp-c8t2.zip

Setup
This exercise starts where "a simple IBGP and EBGP network" ended. Above is a link to the completed config files of the "a simple IBGP and EBGP network" exercise.

The first thing we will do here is strip the default route advertisements down on the edge routers.
P1R1(config)#no ip route 0.0.0.0 0.0.0.0 172.31.11.4
P1R1(config)#router rip
P1R1(config-router)#no default-information originate
P1R1(config-router)#end
P1R1#

Once this is done we set up the full mesh for the pod. This requires adding 2 more sessions on the edge routers and 3 sessions on the internal routers. We use the loopback addresses for this example.
P1R1(config)#router bgp 65001
P1R1(config-router)#neighb 10.200.200.13 remote-as 65001
P1R1(config-router)#neighb 10.200.200.14 remote-as 65001
P1R1(config-router)#end
P1R1#

Loopbacks provide added stability in full-mesh networks as the interface does not go down, in comparison to a physical interface when their is a failure. For this reason we will configure the internal routers to send their IBGP updates from their loopback address.
The following shows an example of what is required:
P1R3(config)#router bgp 65001
P1R3(config-router)#neighb 10.200.200.11 update-source loopback0
P1R3(config-router)#neighb 10.200.200.12 update-source loopback0
P1R3(config-router)#neighb 10.200.200.14 update-source loopback0
P1R3(config-router)#end

You should immediately see IBGP sessions become established. You could also check with the "show ip bgp summary" command.
The edge routers should see 2 EBGP and 3 IBGP sessions. The internal routers should just see the 3 IBGP sessions.

Show ip bgp to determine next hop for the route to 10.254.0.0
P1R1#sh ip bgp
BGP table version is 13, local router ID is 10.200.200.11
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
* i10.1.0.0/24 10.1.0.2 0 100 0 i
*> 0.0.0.0 0 32768 i
* i10.1.1.0/24 10.1.2.4 2 100 0 i
*> 0.0.0.0 0 32768 i
*> 10.1.2.0/24 10.1.1.3 2 32768 i
* i 10.1.0.2 0 100 0 i
* i10.1.3.0/24 10.1.2.4 1 100 0 i
*> 10.1.1.3 1 32768 i
* i10.97.97.0/24 172.31.11.4 0 100 0 64999 64997 i
* 172.31.11.4 0 64999 64997 i
*> 172.31.1.3 0 64998 64997 i
* i10.254.0.0/24 172.31.1.3 0 100 0 64998 i
* 172.31.11.4 0 64999 64998 i
*> 172.31.1.3 0 0 64998 i
r i172.31.1.0/24 172.31.1.3 0 100 0 64998 i
r 172.31.11.4 0 64999 64998 i
r> 172.31.1.3 0 0 64998 i
Network Next Hop Metric LocPrf Weight Path
r i172.31.11.0/24 172.31.11.4 0 100 0 64999 i
r> 172.31.11.4 0 0 64999 i
r 172.31.1.3 0 64998 64999 i
P1R1#


It shows 172.31.1.3. (Backbone Router). You will also see these routes in the BGP table of the internal pod routers. Howerver, these routes are not in the ip route table because this route is unreachable.
P1R3#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
R 10.200.200.11/32 [120/1] via 10.1.1.1, 00:00:23, Ethernet0
R 10.200.200.14/32 [120/1] via 10.1.3.4, 00:00:16, Serial0
R 10.200.200.12/32 [120/2] via 10.1.3.4, 00:00:16, Serial0
C 10.200.200.13/32 is directly connected, Loopback0
C 10.1.3.0/24 is directly connected, Serial0
R 10.1.2.0/24 [120/1] via 10.1.3.4, 00:00:16, Serial0
C 10.1.1.0/24 is directly connected, Ethernet0
R 10.1.0.0/24 [120/1] via 10.1.1.1, 00:00:24, Ethernet0
P1R3#

Problem: EBGP distributes the next hop (remote address) into the IBGP, but the pod does not have a route, static or otherwise to the remote network.
Solution: The local EBGP speaker has to advertise to the pod , that it is the next hop for this remote network, as opposed to the Backbone router. Achieve this with the following commands on both edge routers.
P1R1(config-router)#neighbor 10.200.200.13 next-hop-self
P1R1(config-router)#neighbor 10.200.200.14 next-hop-self

Now “show ip route” on P1R3. There is still no route to the 10.254.0.0 prefix!

This is because synchronization is on. If you disable synchronization, BGP can use routes learned from IBGP neighbors that are not present in the local routing table.
On all pod routers issue the following command.
P1R1(config-router)#no synchronization

BGP Synchronization is on by default in current IOS releases.
The BGP Synchronization rule states that a bgp router should not use or advertise to a neighbour a route learned by IBGP, unless that route is local or learned from the IGP.
Because we are running full mesh IBGP we can turn off synchronization with the ‘no synchronization’ command on all pod routers.

Sh ip route on P1R3 and verify BGP has injected the route into the local routing table.
P1R3#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.31.0.0/24 is subnetted, 2 subnets
B 172.31.1.0 [200/0] via 10.200.200.11, 00:00:15
B 172.31.11.0 [200/0] via 10.200.200.11, 00:00:15
10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
R 10.200.200.11/32 [120/1] via 10.1.1.1, 00:00:26, Ethernet0
R 10.200.200.14/32 [120/1] via 10.1.3.4, 00:00:01, Serial0
R 10.200.200.12/32 [120/2] via 10.1.3.4, 00:00:01, Serial0
C 10.200.200.13/32 is directly connected, Loopback0
C 10.1.3.0/24 is directly connected, Serial0
R 10.1.2.0/24 [120/1] via 10.1.3.4, 00:00:02, Serial0
B 10.97.97.0/24 [200/0] via 10.200.200.11, 00:00:16
C 10.1.1.0/24 is directly connected, Ethernet0
R 10.1.0.0/24 [120/1] via 10.1.1.1, 00:00:27, Ethernet0
B 10.254.0.0/24 [200/0] via 10.200.200.11, 00:00:34
P1R3#

Finally ping 10.254.0.254
P1R3#ping 10.254.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.254.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
P1R3#


Wrapping Up
In this exercise we learnt about the "next-hop-self" command which is used to force BGP to use its own IP address as the next hop for eachnetwork it advertises to the neighbor, rather than letting the protocol choose the next-hop address to use.

We also learnt about Synchronization in the Cisco IOS. Sychronization is ON by default! If your AS is passing traffic from one AS to another, BGP should not advertise a route before all routers in your AS have learned about the route via IGP.
This behavior can be changed with the "no synchronization" command. Make sure you have a full mesh topology before disabling sychronization, otherwise you could end up with routing "black holes".

this post is based on an exercise from the book
CCNP Self Study:
Building Scalable Cisco Internetworks (BSCI)
Second Edition

Saturday 15 December 2007

a simple IBGP and EBGP network

Objective This post demonstrates how to configure a simple IBGP and EBGP network.

Download Equipment list, configuration files and network topology. ccnp-c8t1.zip

Setup
After successfully loading config files into your equipment we need to verify installation.

First let's make sure all our interfaces are up on each router that we would expect with "sho ip interface brief".

P1R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
Ethernet0 10.1.1.1 YES manual up up
Loopback0 10.200.200.11 YES manual up up
Serial0 unassigned YES manual up up
Serial0.1 172.31.1.1 YES manual up up
Serial0.2 172.31.11.1 YES manual up up
Serial1 10.1.0.1 YES manual up up

Next we wil ping through to the backbone routers to see that the Frame Switch is operational.
P1R1#ping 172.31.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/45/88 ms

BGP Configuration
Here we set up our pod as AS65001 with IBGP and EBGP sessions on both edge routers.

P1R1#conf t
P1R1(config)#router bgp 65001
P1R1(config-router)#neighbor 172.31.1.3 remote-as 64998
P1R1(config-router)#neighbor 172.31.11.4 remote-as 64999
P1R1(config-router)#neighbor 10.1.0.2 remote-as 65001
P1R1(config-router)#end

Following this we mannualy set up which networks BGP will advertise, again on the routers we configured as AS65001.
P1R1(config)#router bgp 65001
P1R1(config-router)#net 10.1.0.0 mask 255.255.255.0
P1R1(config-router)#net 10.1.1.0 mask 255.255.255.0
P1R1(config-router)#net 10.1.2.0 mask 255.255.255.0
P1R1(config-router)#net 10.1.3.0 mask 255.255.255.0
P1R1(config-router)#end
P1R1#

You will see notifications on the console as the sessions are established. You can verify you have the 3 expected bgp sessions with the "show ip bgp summary" command.

P1R1#sh ip bgp summ
BGP router identifier 10.200.200.11, local AS number 65001
BGP table version is 10, main routing table version 10
8 network entries using 776 bytes of memory
20 path entries using 720 bytes of memory
13 BGP path attribute entries using 780 bytes of memory
6 BGP AS-PATH entries using 144 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2420 total bytes of memory
BGP activity 8/0 prefixes, 20/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.0.2 4 65001 25 25 10 0 0 00:15:31 7
172.31.1.3 4 64998 27 26 10 0 0 00:18:55 4
172.31.11.4 4 64999 27 27 10 0 0 00:18:42 4

State/PfxRcd shows how many prefixes have been received from which peer

RIPv2 & IBGP
RIPv2 is running between PxR1 and PxR2, because the network statement for RIPv2 includes the entire 10.0.0.0 network. For this exercise, you only want to run IBGP between PxR1 and PxR2. We will need to configure int s0/1 on both edge routers as passive interfaces to suppress RIPv2 between the 2 edge routers.

P1R1(config)#router rip
P1R1(config-router)#passive-interface s0/1

Verify these commands with "show ip protocols". You will now see interfaces serial0/1 under the "Passive Interfaces" header.
Passive Interface(s):
Serial0/1

From the edge routers we have full connectivity with the 10.254.0.0 prefix however because we are not redistributing BGP into RIPv2, the internal routers do not know any routes outside their pod.
Use the "default-information originate" command on the edge routers to generate a default route to the internal routers.
P1R1(config)#router rip
P1R1(config-router)#default-information originate

Verify this with "show ip route" on the internal routers.You will see a new default route generated via RIPv2.
P1R3#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.1.1.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
R 10.200.200.11/32 [120/1] via 10.1.1.1, 00:00:22, Ethernet0
R 10.200.200.14/32 [120/1] via 10.1.3.4, 00:00:03, Serial0
C 10.200.200.13/32 is directly connected, Loopback0
C 10.1.3.0/24 is directly connected, Serial0
R 10.1.2.0/24 [120/1] via 10.1.3.4, 00:00:03, Serial0
C 10.1.1.0/24 is directly connected, Ethernet0
R 10.1.0.0/24 [120/1] via 10.1.1.1, 00:00:22, Ethernet0
R* 0.0.0.0/0 [120/1] via 10.1.1.1, 00:00:23, Ethernet0

and finally a ping to verify connectivity.
P1R3#ping 10.254.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.254.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
P1R3#



this post is based on an exercise from the book
CCNP Self Study:
Building Scalable Cisco Internetworks (BSCI)
Second Edition

Thursday 6 December 2007

opensolaris tftp server

According to the in.tftpd manpage, in.tftpd is being managed by smf(5), which is well, true. The problem is that it’s not there if you issue svcs|grep tftpd.
I don’t know the reason why it’s not configured (but disabled) but, because of compatibility with older versions of “add_install_client” and “setup_install_server”, tftp needs to be listed in /etc/inet/inetd.conf; so that’s where a fresh install should put the command.

Add this to /etc/inetd.conf to configure tftpd:
TFTPD - tftp server
tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot

Make your changes active:
root@opensolaris:/# inetconv
root@opensolaris:/# svcs | grep tftp
online 16:15:58 svc:/network/tftp/udp6:default
The tftp service is now enabled and available.
You can enable using inetadm -e svc:/network/tftp/udp6 and disable with inetadm -d svc:/network/tftp/udp6