Bgp topics to be covered!

1) Establishing Peerings

• TCP Transport
• Update Source

2) Authentication

3) EBGP

4) iBGP

• Route Reflection
• Confederation
• Next-Hop Processing

Next-Hop Self
Route-Map

• iBGP Synchronization

Redistribution into IGP
BGP over GRE

5) Bestpath Selection

• Weight
• Local Preference
• AS-Path Prepending
• MED

6) Originating Prefixes

• Network Statement
• Redistribution
• Aggregation

Summary-Only
Suppress-Map
Unsuppress-Map
Filtering Specifics
Filtering Aggregate

• Conditional Route Injection

7) Default Originate

8) Communities

• No-Export
• No-Advertise
• Local-AS
• Numbered
• New Format
• Local AS

9) Conditional Advertisement

10) Outbound Route Filtering

11) Dampening

12) Peer Groups

13) Regular Expressions

14) Remove Private AS

16) Timers

17) Fast External Fallover

18) Max Prefix

Hmm, I plan on completing all this in around next 12 days! Let's see how far can I get.

Internetwork Expert WB VOL 1 - BGP Lab 7

7)BGP Bestpath Selection – Weight

Objective: Configure the BGP Weight attribute on R3 so that traffic from R3’s Ethernet segment going to VLAN 5 is first sent to R1.

Hmm, over here ..I was again in line not with the solution though. The WB solution is more general, where as I decided to come up with the a more specific solution that only modifies the weight for VLAN_5 prefix!! I am more correct here, being more specific on the lab always helps.

Anyways this is what I Have done,

ip prefix-list VLAN_5_PREFIX seq 5 permit 155.1.5.0/24

route-map MODI_WEIGHT permit 10
match ip address prefix-list VLAN_5_PREFIX
set weight 100

router bgp 2
neighbor 155.1.13.1 route-map MODI_WEIGHT in
end

Worked like a charm! Hmm seven labs for the day, with some theory of bgp are good enough. I will call it a day, will try to do more tomorrow.

Internetwork Expert WB VOL 1 - BGP Lab 6

6)Transiting Non-BGP Speaking Devices – Tunneling

Objective: Configure the network so that hosts on VLAN 5 can reach hosts on VLAN 43. R3 will not participate in BGP routing. Configure a GRE tunnel between R1 and R2 to accomplish this.

Alright, I will try and make some quick changes to the previous lab config and see if I get this correct.

Yep, It’s correct! Had no difficulties at all. Next please.

Internetwork Expert WB VOL 1 - BGP Lab 5

5)Transiting Non-BGP Speaking Devices – Redistribution

Objective: Configure the network so that hosts on VLAN 5 can reach hosts on VLAN 43. R3 will not participate in BGP routing. Redistribute BGP into IGP in AS 2 to accomplish this.

Ok, see here ..that makes my job easier and saves time too! This scenario maps to solution 2 mentioned in the previous lab post. Nice! Let's hit it.

Yeah I nailed it straight, I mean I did configure this same thing in the previous lab just out of curiosity. The only difference between me and the solution in the WB was that, I dint find necessary to resolve the next-hop ip address as they were ending up as rib failed routes. The book does use the next-hop-self command, hmm fair enough!

Next.

Internetwork Expert WB VOL 1 - BGP Lab 4

4)iBGP Synchronization

Objective: Configure BGP per the diagram to obtain connectivity from AS 1 to R4 and R5's loopback interfaces. R4 and R5 should have static default routes pointing towards R1 and R2 respectively. BGP synchronization should be enabled on R1 and R2.

Wow, this was a big step ..the topology was much better here. Let me get moving and then blog more on this one. Well to understand this lab better here is the bgp rule of synchronization, as quoted by Brian of IE:

‘Paths marked as "not synchronized" in the show ip bgp longer-prefixes output. If BGP synchronization is enabled, which it is by default in Cisco IOS® Software, there must be a match for the prefix in the IP routing table in order for an internal (iBGP) path to be considered a valid path. If the matching route is learned from an OSPF neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization using the no synchronization BGP subcommand. See the Synchronization section in Using the Border Gateway Protocol for Interdomain Routing for more information.
• Note: Synchronization is disabled by default in Cisco IOS Software version 12.2(8)T and later.’

Actually it’s a legacy rule, which was designed for a specific purpose, which is “Designed to prevent traffic black holes, in an transit AS”. As CCIE candidates it’s important to understand its purpose and how it works, irrespective of whether it is on or off and what are the possible solutions to prevent black-holes in our transit AS!!

And yes, btw what are black-holes?! In an transit AS, whenever you see a non-BGP speaker chances are that the packets will be dropped.

To prevent this black-hole problem, I am going to go ahead and list some of the possible solutions,

1) Run full mesh iBGP within the transit AS. (synchronization is off)
2) Redistribute BGP into the IGP, thereby making the two to be in sync with each other. (synchronization is on)
3) Impelement tunnels, (synchronization is off)

• Gre
• IPIP
• MPLS ..et all

I went ahead and using the same topology, I did make all the three above mentioned solutions work!! Towards, the end of the day I will again work with solutions, as I really want to have it wrapped around my head.

Let’s proceed to our next lab.

Internetwork Expert WB VOL 1 - BGP Lab 3

3)BGP Update Source Modification

Objective: Configure a BGP peering relationship between R1 and R3. R1 should peer with R3's Ethernet interface, while R3 should peer with R1's Serial interface. R1 should use the source address 31.0.0.1 when sending BGP packets to R3.

Ok, this I had already done in the above lab, one good point to note here is that the update-source command will still work if its present on just one router, I mean after all we only need one active tcp session between the two routers. So we are good here, in the lab though it would definitely be better to configure the update-source command on both R1 and R2!

Internetwork Expert WB VOL 1 - BGP Lab 2

2)BGP Update Source Mismatch

Objective: Configure a BGP peering relationship between R1 and R3. R1 should peer with R3's Ethernet interface, while R3 should peer with R1's Serial interface.

Yep yep, I did this lab and it did take not more than 10 minutes! I know too much time there ..an ip on the fa 0/0 of R1 cuased me some problem, but nothing major. I need to be a bit more attentive whilst doing these labs I guess.

Anyways configuration was correct, I did it w/o any problems ..infact I went ahead and used the neighbor 13.0.0.3 update-source serial 1/1 command, which actually fixed and made the bgp peering come-up successfully.

Internetwork Expert WB VOL 1 - BGP Lab 1

1)Establishment of BGP Peering Relationships

Objective: Configure a BGP peering relationship between R1 and R2

Hmm, about this lab, well what can I say ..very very basic. Was done in about 5 minutes, after that I did explore some more about bgp using these three debug commands ..

debug ip packet detail
debug ip bgp events
debug ip tcp transactions

Ok, so onto the next one ..Yep btw, I did answer all the questins that followed with ease. I am really looking forward to reading the breakdown of these labs!