We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 606 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)


363 New Members signed up the last 30 days!


100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Thanks for the labs Rene, I appreciate all the time you take out of your day to create these labs for us. I always forget about the BGP regular expressions so I printed them out this time.

  2. Rene – in your example of Filter-list with AS PATH access-list you wrote:

    R1(config)#ip as-path access-list 1 permit ^$

    Is the AS number of R1 suppose to go between the ^ and the $? In your example you didn’t specify an AS # - let’s just say R1 AS # is 4444. Should it look like this?

    R1(config)#ip as-path access-list 1 permit ^4444$

  3. andrew says:

    This is actually a very good question which required wireshark and some musing on my part to figure out.

    Here’s the short answer:
    If you included R1’s AS in the filter:
    R1(config)#ip as-path access-list 1 permit ^4444$
    It would indeed stop ISP1 and ISP2 from using R1 as a transit path. However, there is also a negative consequence. R1’s advertisements to ISP1 and ISP2 would also be filter out.

    Here’s the long answer:
    The interesting question is why does it do this? To answer this question, the first point to understand is what the ip as-path command is saying. It is using regex where the “^” means “beginning of string” and “$” means “end of string.” So, " ^4444$ " means “this string contains exactly 4444.” Since the as-path access list has an implicit deny at the end, everything except 4444 in the as-path is rejected.

    To figure out why the R1 is filtering out its own route, you need to look at the BGP Topology table. Here’s what it looks like:

    R1#show ip bgp topology *
    For address family: IPv4 Unicast
    BGP table version is 4, local router ID is
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
                  x best-external, a additional-path, c RIB-compressed,
    Origin codes: i - IGP, e - EGP, ? - incomplete
    RPKI validation codes: V valid, I invalid, N Not found
         Network          Next Hop            Metric LocPrf Weight Path
     *>                  0         32768 i

    Notice the Path field in the table–specifically what is NOT there. It lists only the origin code and no AS-Path. Self-originated routes are not stamped with the AS-Path in the host router’s BGP Topology table. The route is associated with the 4444 AS Path attribute once it leaves R1 (after the filter has already done its work).

    Essentially, the reason putting 4444 in the as-path filter will not work comes down the order in which BGP operates: Filter based on Topology table first, then send BGP Update message with added AS-Path attribute to neighbors.

  4. Hey Rene,

    Thanks for your great lessons and labs you post. I have a question regarding BGP when using 2 ISPs.

    I have a muti-homes ISR with two ISPs both advertising a default route via BGP I have manipulated the weight attribute to prefer ISP1 over ISP2. My question is why when I learn the default route through ISP1 my ISR also advertises it to ISP2 becoming a transit AS, even though I didnt manually configure it under my BGP instance ?

    Thanks in advance.

  5. Hi @iniguezjuan,

    By default, BGP will advertise prefixes that you have learned from one eBGP neighbor to another eBGP neighbor. That’s why you will have to configure your router to prevent this :slight_smile:

31 more replies! Ask a question or join the discussion by visiting our Community Forum