BGP Allow AS In


Scenario:

An international toy store company needs your help. They use BGP to exchange routing information between their sites but everytime one of their IBGP routers fails they have connectivity issues. Let’s see if you can help them out!

Goal:

  • All IP addresses have been preconfigured for you.
  • Configure IBGP within AS 1, source BGP updates from the loopback0 interfaces.
  • Configure EBGP between router Woody and Buzz.
  • Configure EBGP between router Andy and Buzz.
  • Advertise the loopback1 interfaces in BGP on router Woody and Andy.
  • Ensure router Woody and Andy can still reach each others loopback interfaces when router Rex fails.

It took me 1000s of hours reading books and doing labs, making mistakes over and over again until I mastered all the protocols for CCNP.

Would you like to be a master of networking too? In a short time without having to read 900 page books or google the answers to your questions and browsing through forums?

I collected all my knowledge and created a single ebook for you that has everything you need to know to become a master of CCNP.

You will learn all the secrets about BGP, External vs Internal BGP and more.

Does this sound interesting to you? Take a look here and let me show you how to Master CCNP ROUTE!

IOS:

c3640-jk9s-mz.124-16.bin

Topology:

BGP Allow AS In

Video Solution:

Configuration Files

You need to register to download the GNS3 topology file. (Registration is free!)

Once you are logged in you will find the configuration files right here.

Opt In Image
Do you want your CCNA or CCNP Certificate?

The How to Master series helps you to understand complex topics like spanning-tree, VLANs, trunks, OSPF, EIGRP, BGP and more.

Written by René Molenaar - CCIE #41726

You May Also Like

About the Author: Rene Molenaar

René - CCIE #41726 is the creator of GNS3Vault.com where he shares CCNA, CCNP and CCIE R&S labs. He also blogs about networking on http://networklessons.com

16 Comments

  1. I have one small problem with this lab.

    “Ensure router Woody and Andy can still reach each others loopback interfaces when router Rex fails.”

    As we are using iBGP in AS1 we have two problems,

    1. Woody’s loopback will not reach Andy with out the use of a route reflector and vice versa.

    2. iBGP’s AD is 200 where as eBGP’s is 20,

    So by default all traffic will always take the path through Buzz and never through Rex as without Buzz Woddy and Andy would never know of each others loopbacks.

    But anyway thanks for the lab.

  2. Hello Andrew,

    Thanks for your comment.

    [quote]1. Woody’s loopback will not reach Andy with out the use of a route reflector and vice versa. [/quote]

    Within the autonomous system you need to configure IBGP and it should be a full-mesh. If you want you can use a route reflector if you don’t want to configure all IBGP peerings.

    [quote]So by default all traffic will always take the path through Buzz and never through Rex as without Buzz Woddy and Andy would never know of each others loopbacks. [/quote]

    You are right about the administrative distance but what is the loop-prevention mechanism for EBGP? If you see your own AS number in the AS Path for an update you will reject it because it’s a loop. That’s the default for BGP.

    You can get around this by disabling the loop prevention mechanism for BGP, the title of this lab is the answer to that 😉

    Good luck!

    Rene

  3. Oh I got the purpose of the lab, disabling eBGP’s metric, just wasn’t overly keen on the wording of the last objective.

    But I think that works well for this lab as it does make you think more the adding the allowas-in command.

    Thanks again for the great resource.

    🙂

  4. Hi Sehgal,

    I will soon…once I have time I’ll be recording all the videos.

    What part are you stuck on? If you drop questions here on the forum I’ll be answering them.

    Rene

  5. After configuring the IBGP in As-1.I am not able to up the EBGP between Andy and BUZZ,But after configuring peer-group between andy and buzz,all nei. are comes up .is it right way for this lab???

  6. Hello Vik,

    You should only use a peer group when you have neighbors with the exact same configuration. Imagine having 4 EBGP peers with the same prefix-filter, that would be a good example of using a peer group.

    In this example router Andy only has one IBGP and one EBGP router. You could configure a peer group on router Buzz because it has two EBGP neighbors in AS 1. To keep things simple I would just forget about the peer group and use the per neighbor commands. There has to be an error in your BGP neighbor configuration somewhere.

    The lab is about the loop prevention mechanism of BGP. If it sees it’s own AS number it will drop the traffic by default. Using BGP allow-AS in can change this behavior.

  7. Thanks Rene for reply….
    Yes,my all bgp nei. are up now,route also in routing table of every router but not able to ping.Allows in is confugured on both router l.e. Woddy and andy for nei. With buzz

  8. Hi Rene

    I am wondering have u ever used this allow as in feature in a real world?

    The lab was good and everything worked fine a/c to the plan.

    Thanks

    1. I never used this in real life but if someone else did…please reply 🙂 I think you have to be careful with this feature because we are telling BGP to ignore it’s "loop-prevention" mechanism.

  9. For both woody (R1) and andy (R3) next hop keep on changing from next hope as Buzz (R4) to the loopback of R1 or R3 as shown below. So when next hop is Buzz then ping works between R1-R2 otherwise it does not.

    I can see that of as-path and origin attributes could be playing there part but don’t know why best routes keeps flapping as shown below.

    R1#show ip bgp 3.3.3.3
    BGP routing table entry for 3.3.3.0/24, version 157
    Paths: (2 available, best #1, table Default-IP-Routing-Table)
    Flag: 0x820
    Not advertised to any peer
    Local
    3.3.3.3 from 3.3.3.3 (3.3.3.3)
    Origin IGP, metric 0, localpref 100, valid, internal, best
    2 1
    192.168.14.4 from 192.168.14.4 (4.4.4.4)
    Origin IGP, localpref 100, valid, external
    R1#
    R1#
    R1#show ip bgp 3.3.3.3
    BGP routing table entry for 3.3.3.0/24, version 158
    Paths: (2 available, best #2, table Default-IP-Routing-Table)
    Flag: 0x820
    Advertised to update-groups:
    2 3
    Local
    3.3.3.3 (inaccessible) from 3.3.3.3 (3.3.3.3)
    Origin IGP, metric 0, localpref 100, valid, internal
    2 1
    192.168.14.4 from 192.168.14.4 (4.4.4.4)
    Origin IGP, localpref 100, valid, external, best

    —————————–

    R3#sh ip bgp 1.1.1.1
    BGP routing table entry for 1.1.1.0/24, version 213
    Paths: (2 available, best #1, table Default-IP-Routing-Table)
    Flag: 0x820
    Advertised to update-groups:
    1
    Local
    1.1.1.1 from 1.1.1.1 (1.1.1.1)
    Origin IGP, metric 0, localpref 100, valid, internal, best
    2 1
    192.168.34.4 from 192.168.34.4 (4.4.4.4)
    Origin IGP, localpref 100, valid, external
    R3#
    R3#sh ip bgp 1.1.1.1
    BGP routing table entry for 1.1.1.0/24, version 215
    Paths: (2 available, best #2, table Default-IP-Routing-Table)
    Flag: 0x820
    Advertised to update-groups:
    1 2 3
    Local
    1.1.1.1 (inaccessible) from 1.1.1.1 (1.1.1.1)
    Origin IGP, metric 0, localpref 100, valid, internal
    2 1
    192.168.34.4 from 192.168.34.4 (4.4.4.4)
    Origin IGP, localpref 100, valid, external, best

Comments are closed.