BGP Allow AS In

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. Where’s the lab?

5. If you register and login, you’ll see the “attachments” at the bottom of the article.

6. Please share the configuration of this lab

7. 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

8. 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???

9. 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.

10. 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

11. 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.

12. good lab.

13. It is a good lab. Using the debug ip bgp updates after you redistribute but before you allowas-in can show you some informative messages.

    Also I gave some thought on what would happen if we set the AD of the bgp and ospf learned routes to be the same. Came to interesting thread

    https://supportforums.cisco.com/discussion/11968131/dilemma-understanding-routing-table-building#4067147

14. 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

    1. Sorry, correction issue happens between R1 and R3.

Comments are closed.