|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
BGP-Funktion : aggregate-address part 2
|
|
|
|
Hallo zum zweiten Teil. Während wir uns die Auswirkungen der Aggregation im ersten Teil nur auf dem Rtr-E angeschaut haben, überprüfen wir jetzt doch mal, was auf den beiden Routern Rtr-B und Rtr-A passiert. Hier nochmal unser Versuchsaufbau.
|
|
|
|
 |
|
|
|
Rtr-A und Rtr-B announcen Ihre Loopback-Interfaces per redistribute connected zum Rtr-C. Der Rtr-C aggregiert die die empfangenen Routen und sendet diese Information an alle Nachbarn weiter. Wie wir gelernt haben, werden bei der Aggregation die AS-Path Informationen standardmäßig abgeschnitten. Das heißt, das aggregierte Netz sollte sowohl auf Rtr-B, als auch auf Rtr-A sichtbar sein. Schauen wir doch mal bei Rtr-B nach :
|
|
|
|
Rtr-B#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
C 192.168.12.0/24 is directly connected, Loopback5
C 192.168.13.0/24 is directly connected, Loopback6
C 192.168.14.0/24 is directly connected, Loopback7
C 192.168.15.0/24 is directly connected, Loopback8
C 192.168.8.0/24 is directly connected, Loopback1
C 192.168.9.0/24 is directly connected, Loopback2
C 192.168.10.0/24 is directly connected, Loopback3
172.22.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.22.1.8/30 is directly connected, Serial0/0
B 172.22.1.0/30 [20/0] via 172.22.1.10, 00:03:48
C 172.22.100.17/32 is directly connected, Loopback0
B 172.22.100.6/32 [20/0] via 172.22.1.10, 00:03:48
C 192.168.11.0/24 is directly connected, Loopback4
B 192.168.0.0/20 [20/0] via 172.22.1.10, 00:00:09
Rtr-B#
Rtr-B#sh ip bgp
BGP table version is 47, local router ID is 192.168.15.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.22.1.0/30 172.22.1.10 0 3 2 ?
*> 172.22.1.8/30 0.0.0.0 0 32768 ?
*> 172.22.100.6/32 172.22.1.10 0 3 2 ?
*> 172.22.100.17/32 0.0.0.0 0 32768 ?
*> 192.168.0.0/20 172.22.1.10 0 0 3 i
*> 192.168.8.0 0.0.0.0 0 32768 ?
*> 192.168.9.0 0.0.0.0 0 32768 ?
*> 192.168.10.0 0.0.0.0 0 32768 ?
*> 192.168.11.0 0.0.0.0 0 32768 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*> 192.168.13.0 0.0.0.0 0 32768 ?
*> 192.168.14.0 0.0.0.0 0 32768 ?
*> 192.168.15.0 0.0.0.0 0 32768 ?
Rtr-B#
|
|
|
|
Wie deutlich zu sehen, wird das ganze aggregierte Netz 192.168.0.0 /20 in die Routingtable des Rtr-B aufgenommen, da in dem AS-Path das eigene autonome System nicht auftaucht. Was passiert aber, wenn wir die as-set Option benutzen, die ja genau diese Ungenauigkeiten bereinigen soll. Hier das Ergebnis mit der auf dem Rtr-C gesetzten as-set Option:
|
|
|
|
Rtr-C#sh run | beg bgp
router bgp 3
no synchronization
bgp log-neighbor-changes
aggregate-address 192.168.0.0 255.255.240.0 as-set summary-only
neighbor 172.22.1.1 remote-as 2
neighbor 172.22.1.6 remote-as 4
neighbor 172.22.1.9 remote-as 1
no auto-summary
Rtr-C#
Rtr-B#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
C 192.168.12.0/24 is directly connected, Loopback5
C 192.168.13.0/24 is directly connected, Loopback6
C 192.168.14.0/24 is directly connected, Loopback7
C 192.168.15.0/24 is directly connected, Loopback8
C 192.168.8.0/24 is directly connected, Loopback1
C 192.168.9.0/24 is directly connected, Loopback2
C 192.168.10.0/24 is directly connected, Loopback3
172.22.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.22.1.8/30 is directly connected, Serial0/0
B 172.22.1.0/30 [20/0] via 172.22.1.10, 00:22:50
C 172.22.100.17/32 is directly connected, Loopback0
B 172.22.100.6/32 [20/0] via 172.22.1.10, 00:22:50
C 192.168.11.0/24 is directly connected, Loopback4
Rtr-B#
c2611xm-3#sh ip bgp
BGP table version is 48, local router ID is 192.168.15.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.22.1.0/30 172.22.1.10 0 3 2 ?
*> 172.22.1.8/30 0.0.0.0 0 32768 ?
*> 172.22.100.6/32 172.22.1.10 0 3 2 ?
*> 172.22.100.17/32 0.0.0.0 0 32768 ?
*> 192.168.8.0 0.0.0.0 0 32768 ?
*> 192.168.9.0 0.0.0.0 0 32768 ?
*> 192.168.10.0 0.0.0.0 0 32768 ?
*> 192.168.11.0 0.0.0.0 0 32768 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*> 192.168.13.0 0.0.0.0 0 32768 ?
*> 192.168.14.0 0.0.0.0 0 32768 ?
*> 192.168.15.0 0.0.0.0 0 32768 ?
Rtr-B#
|
|
|
|
Die Situation, die sich nun zeigt, ist natürlich fatal für Rtr-B, da er keine Route mehr zu den Netzen vom Rtr-A mehr lernt. Gehen wir mal davon aus, daß
Rtr-E dringend die Informationen benötigt, von welchen Routern die Netze announced werden (für einen AS-Path-Filter usw.), haben wir nun ein Problem.
Lösungsvorschlag 1 : wir schalten die Option summary-only auf Rtr-C aus. Dadurch hätten wir aber nicht wirklich unsere Routingtable verkleinert.
Lösungsvorschlag 2 : wir announcen nur noch Routen per as-set zu Rtr-B, die nicht bei Rtr-B erzeugt werden. Die passende Option heißt advertise-map mit einer passenden Route-map. In dieser Route-Map werden einfach die Routen, die die AS-Path-Information 1 (AS Router Rtr-B) enthalten, nicht per as-set announced. Schauen wir uns zuerst die Konfig auf Rtr-C an:
|
|
|
|
router bgp 3
no synchronization
bgp log-neighbor-changes
aggregate-address 192.168.0.0 255.255.240.0 as-set summary-only advertise-map HIDE-AS1
neighbor 172.22.1.1 remote-as 2
neighbor 172.22.1.6 remote-as 4
neighbor 172.22.1.9 remote-as 1
no auto-summary
!
ip as-path access-list 1 permit ^2$
!
!
route-map HIDE-AS1 permit 10
match as-path 1
|
|
|
Wir erlauben hier also nur noch, daß Routen aus dem AS 2 im AS-Path dar-gestellt werden. Im Umkehrschluß könnten wir natürlich auch AS1 verbieten und den Rest erlauben. Schauen wir uns doch mal die Ergebnisse an.
|
|
|
|
Rtr-A#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, 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.22.0.0/16 is variably subnetted, 4 subnets, 2 masks
B 172.22.1.8/30 [20/0] via 172.22.1.2, 02:30:44
C 172.22.1.0/30 is directly connected, Serial0/0
B 172.22.100.17/32 [20/0] via 172.22.1.2, 02:30:44
C 172.22.100.6/32 is directly connected, Loopback1
C 192.168.4.0/24 is directly connected, Loopback104
C 192.168.5.0/24 is directly connected, Loopback105
C 192.168.6.0/24 is directly connected, Loopback106
C 192.168.7.0/24 is directly connected, Loopback107
C 192.168.0.0/24 is directly connected, Loopback100
C 192.168.1.0/24 is directly connected, Loopback101
C 192.168.2.0/24 is directly connected, Loopback102
C 192.168.3.0/24 is directly connected, Loopback103
Rtr-A#
Rtr-B#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
C 192.168.12.0/24 is directly connected, Loopback5
C 192.168.13.0/24 is directly connected, Loopback6
C 192.168.14.0/24 is directly connected, Loopback7
C 192.168.15.0/24 is directly connected, Loopback8
C 192.168.8.0/24 is directly connected, Loopback1
C 192.168.9.0/24 is directly connected, Loopback2
C 192.168.10.0/24 is directly connected, Loopback3
172.22.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.22.1.8/30 is directly connected, Serial0/0
B 172.22.1.0/30 [20/0] via 172.22.1.10, 02:31:11
C 172.22.100.17/32 is directly connected, Loopback0
B 172.22.100.6/32 [20/0] via 172.22.1.10, 02:31:11
C 192.168.11.0/24 is directly connected, Loopback4
B 192.168.0.0/20 [20/0] via 172.22.1.10, 02:31:12
Rtr-B#
|
|
|
|
Was ist passiert? Rtr-B (ist owner von AS1) empfängt die summary-only aggregate-route, weil AS2 im Pfad stehen bleiben darf. AS2, also Router Rtr-A empfängt das aggregate nicht mehr, da im AS-Path das eigene autonome System vorhanden ist und deshalb eingehende Routinginformationen gedroppt werden.
|
|
|
|
