BGP Configuration Lab
AS 70000
IGP Configuration
1. EIGRP named mode (AS70000) for AS 1 is enabled on all the devices in AS
70000 on their directly connected interfaces within the AS and on their loopback
interface
0. Do not enable EIGRP on inter-AS links
BGP configuration
1. All iBGP peers are peering over loopback interfaces
2. R2 should be configured as a route reflector in AS 70000
All session related command should be configured using session
templates
All policy related commands should be configured using policy templates
3. R3 and R6 send an aggregate [Link]/16 to R7
No specific prefixes of the aggregate should be advertised to R7
4. The local preference value for all BGP updates should be 150
Use a single command on all devices to achieve this
AS 78910
IGP and Static Routing Configuration
1. EIGRP named mode (AS78910) for AS 1 is configured on all the devices in AS
78910
Do not enable EIGRP on external inter-AS links
2. Connected interfaces on all the devices in AS 78910 should be advertised into
EIGRP
Do not enable EIGRP on e0/1 interface on R8 and R9 or on inter-AS links
3. Lo1, Lo2 and Lo3 on R10 should not be advertised into EIGRP
BGP Configuration
1. R7, R8 R9 and R10 belong to the main AS 78910
2. Ensure that the IPv4 address family routing information is not advertised to every
peer of every address family
3. R7 and R8 belong to sub AS 65534
BGP peering between R7 and R8 is established over their directly
connected interfaces
4. R9 and R10 belong to the sub AS 65535
BGP peering between R9 and R10 is established over their directly
connected interfaces
5. BGP peering between R8 and R9 is established over their directly connected
interface e0/1
6. R22 and R23 are iBGP peers in sub-AS 65533 with confederation peers 65534
and 65535 respectively
7. Lo1, Lo2, Lo3, Lo4 and L05 should be advertised into BGP on R10
8. R8 should not advertise EIGRP-learned prefixes via BGP to its BGP neighbors.
Use two BGP configuration commands to accomplish this (one on R8, one
on R9)
Do not use prefix-list, route-maps, distribute-lists, or other methods of
explicit filtering to accomplish this
9. On receiving the aggregate [Link]/16, R7 should do the following:
R7’s BGP routing table should have a more specific prefix [Link]/24
with the BGP next hop of [Link]
R8, R9 and R10 should install this prefix with AS 70000 in the
AS_PATH
The more specific prefix should not be advertised outside the
confederation
R7’s BGP routing table should have a more specific prefix [Link]/24
with the BGP next hop of [Link]
R8, R9 and R10 should install this prefix with AS 70000 in the
AS_PATH
The more specific prefix should not be advertised outside the
confederation
10. R8 should advertise R10’s loopbacks with a MED value of 200 to R22
11. R9 should advertise R10’s loopbacks with a MED value of 100 to R23
12. The BGP table on R22 should prefer the path from R23 to reach the loopbacks
on R10
Complete this task with a single command on R22
13. All traffic destined to Lo1, Lo2 and Lo3 on R10 from R22 should go directly to
R23
Use a traceroute to verify this behavior
Do not modify any IGP metrics, route-maps, or use PBR to achieve
this
Configuration change should be made on R9
AS 13
1. R13 has an eBGP peering with R5 over its directly connected interface and an
iBGP peering with R17 over the directly connected interface
2. R17 should advertise Lo1 and Lo6 through BGP
3. R13 should only receive 2 prefixes from R17
If R17 were to advertise any other prefixes into BGP, R13 should display a
warning message that informs the admin that the prefix limit has exceeded
Accomplish this task with a single command on R13
4. R13 should not inject the prefix [Link]/16 into its BGP table
Do not use manual filtering to accomplish this
Do not make any configuration changes on R5 or R13
AS 11 and AS 12
1. R11 has an eBGP peering with R12 and R4 over their directly connected
interfaces
Lo1 through Lo5 are advertised into BGP by R11
2. R12 has an eBGP peering with R1 and R14 over the directly connected
interfaces
Lo1 through Lo5 are advertised into BGP by R12
3. AS 12 does not provide transit for any prefixes to AS 11 except its own prefixes
([Link]/24)
Do not configure any manual outbound policy on R12 to achieve this
Make policy configuration changes on R11 only
Ensure that R12 does not send any unnecessary or unwanted
routing updates to honor this task
Do not use any route-maps, filter-lists to achieve this task
4. AS 12 does not provide transit for any prefixes to AS 11 except its own prefixes
([Link]/24)
Do not configure any outbound policy on R12 to achieve this
Make configuration changes on R11 only
Do not use any route-maps to achieve this task
5. R11 should only advertise its locally originated routes to AS 70000
Do not use any route-maps, prefix-list, access-list or distribute list
The configuration should be done on R11 only
AS 16
1. R16 has an eBGP peering with R2 and advertises the prefix [Link]/32 into
BGP
2. In an event of a DDoS attack destined to the prefix owned by AS16
R16 should explicitly signal R2 through configuration commands to
discard the DDoS traffic to the affected destination
The attacked prefix should no longer be propagated by R2 to its BGP
peers
Only BGP routing techniques can be used to achieve this task
AS 2120
IGP configuration
1. R18 through R21 belong to the same EIGRP domain
Advertise the Lo1 interface into EIGRP on all routers
BGP Configuration
1. R18 through R21 belong to the AS 2120
2. R20 is responsible for passing the iBGP learned routes to all the iBGP neighbors
iBGP peering is established over the loopback interfaces (R18 - Lo1 -
[Link]/32 etc.)
R20 should load share traffic
3. R21 should send all external traffic to R20 to be load shared between R18 and
R19
Configuration changes should be made on R20