Sunday, December 28, 2008

BGP Lab: Confederations and Route Reflectors

Hi all, here's my final lab for the BGP exam preparation:



There are 3 BGP Autonomous systems, the biggest one, AS 885 is divided into 2 confederations and has 4 Route Reflectors (RR).
In the first version of this lab, I've decided to put CON3 outside the confederation... but I had to modify it because it's impossible, every router in a confederated AS must be in a confederation itself.

Main goals for this lab are:

-configure OSPF as IGP for internal links and Loopbacks (loopbacks are like 1.1.1.1 for CON1, 2.2.2.2 for CON2)
-configure eBGP and iBGP for the 3 AS

-AS 885 must summarize customer's prefixes before propagate to other AS

As usual, the most relevant configuration's part will follow, stay tuned! ,-)

  • First I configured all point-to-point links and tested with a simple ping
  • Then, all IGP routing with OSPF. Note the virtual link in area 25, othervise it will be discontiguous... I decided to configure area 33 as stub no-summary, to reduce routing table size, so Provider Edge routers will have a smaller routing table. Note that on CON1 and CON4 the link between differents AS must be routed in ospf, so all AS855 routers can reach the next hop... Here my OSPF config:

CON1#sh run | beg router ospf[+/-]

CON1#sh run | beg router ospf

router ospf 1
router-id 1.1.1.1
log-adjacency-changes
area 25 virtual-link 13.13.13.13
passive-interface default
no passive-interface Vlan2
no passive-interface Vlan3
no passive-interface Vlan4
no passive-interface Vlan12
no passive-interface Vlan13
network 1.1.1.1 0.0.0.0 area 0
network 10.5.0.5 0.0.0.0 area 0
network 10.5.0.9 0.0.0.0 area 0
network 10.5.0.18 0.0.0.0 area 0
network 10.5.25.9 0.0.0.0 area 25
network 10.5.25.13 0.0.0.0 area 25
network 192.168.1.9 0.0.0.0 area 890


CON4#sh run | beg router ospf[+/-]

CON4#sh run | beg router ospf
router ospf 1
router-id 4.4.4.4
log-adjacency-changes
area 33 stub no-summary
passive-interface default
no passive-interface Vlan2
no passive-interface Vlan5
no passive-interface Vlan6
no passive-interface Vlan8
no passive-interface Vlan10
network 4.4.4.4 0.0.0.0 area 0
network 10.5.0.6 0.0.0.0 area 0
network 10.5.0.14 0.0.0.0 area 0
network 10.5.0.22 0.0.0.0 area 0
network 10.5.33.1 0.0.0.0 area 33
network 10.5.33.9 0.0.0.0 area 33
network 192.168.1.1 0.0.0.0 area 892
network 192.168.1.5 0.0.0.0 area 891

Here area 890/891/892 are used only to route point-to-point with other AS.
I used a different area to avoid suboptimal paths (first I tought to use area 33 but the result was that all traffic from CON7 will go through CON15 and CON4 due to CON7 to 4 link is in area 0, but I don't wont to use area 0 for AS peering).

  • Route reflectors: let's start with the simpliest one: CON13 (no additional/strange configuration is required on RR clients CON9 and CON14, just a single iBGP session)

CON13#sh run | beg router bgp[+/-]

CON13#sh run | beg router bgp
router bgp 65008 !-- here we must use the confederation AS number
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 885 !-- this is the "global" AS number
bgp confederation peers 65002 !-- declaration of other confederations peer (don't declare the same confed, only the peers)
neighbor CORE2 peer-group
neighbor CORE2 remote-as 65002
neighbor CORE2 ebgp-multihop 2 !-- EBGP-multihop required, intra-confed sessions are threated as eBGP sessions
neighbor CORE2 update-source Loopback0
neighbor PE-ROUTERS peer-group
neighbor PE-ROUTERS remote-as 65008
neighbor PE-ROUTERS update-source Loopback0
neighbor PE-ROUTERS route-reflector-client !-- here I declare that they are RR clients, so the Split horizon rule will be modified
neighbor 1.1.1.1 remote-as 65008
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 peer-group CORE2
neighbor 7.7.7.7 peer-group CORE2
neighbor 9.9.9.9 peer-group PE-ROUTERS
neighbor 14.14.14.14 peer-group PE-ROUTERS
no auto-summary
I used peer-groups to improve scalability if more Route Reflector Clients will add.
Now take a look over the RR configuration of CON7 and CON4. Here we must use the bgp cluster-id nn to avoid loops in the route reflection.

CON7#sh run | beg router bgp[+/-]

CON7#sh run | beg router bgp
router bgp 65002
no synchronization
bgp cluster-id 7
bgp log-neighbor-changes
bgp confederation identifier 885
bgp confederation peers 65008
neighbor PE-ROUTERS peer-group
neighbor PE-ROUTERS remote-as 65002
neighbor PE-ROUTERS update-source Loopback0
neighbor PE-ROUTERS route-reflector-client
neighbor CORE8 peer-group
neighbor CORE8 remote-as 65008
neighbor CORE8 ebgp-multihop 2
neighbor CORE8 update-source Loopback0
neighbor 1.1.1.1 peer-group CORE8
neighbor 4.4.4.4 remote-as 65002
neighbor 4.4.4.4 update-source Loopback0
neighbor 6.6.6.6 peer-group PE-ROUTERS
neighbor 13.13.13.13 peer-group CORE8
neighbor 15.15.15.15 peer-group PE-ROUTERS
no auto-summary



CON4#sh run | beg router bgp[+/-]

CON4#sh run | beg router bgp
router bgp 65002
no synchronization
bgp cluster-id 4
bgp log-neighbor-changes
bgp confederation identifier 885
bgp confederation peers 65008
neighbor PE-ROUTERS peer-group
neighbor PE-ROUTERS remote-as 65002
neighbor PE-ROUTERS update-source Loopback0
neighbor PE-ROUTERS route-reflector-client
neighbor CORE8 peer-group
neighbor CORE8 remote-as 65008
neighbor CORE8 ebgp-multihop 2
neighbor CORE8 update-source Loopback0
neighbor 1.1.1.1 peer-group CORE8
neighbor 6.6.6.6 peer-group PE-ROUTERS
neighbor 7.7.7.7 remote-as 65002
neighbor 7.7.7.7 update-source Loopback0
neighbor 13.13.13.13 peer-group CORE8
neighbor 15.15.15.15 peer-group PE-ROUTERS
neighbor 192.168.1.2 remote-as 892
neighbor 192.168.1.6 remote-as 779
no auto-summary

Monday, December 15, 2008

Wism Uptime

Back home, trying slowly to return to my "normal" life...

Now it's Time to reboot our other Wism controller (at 23.45... off peak) !
I have seen the same issue that we have experienced in October with webauth portal, here the uptime screenshot as usual:



Well, system on both our Wism Controllers is a little bit outdated, we have 4.1.181.0 software version, I guess now it's actual the 5.2....

(and always as usual, no new cooling system for network room has appeared, so +30°C inside the controller... and we're in december ;-) )