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 568 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

323 New Members signed up the last 30 days!

satisfaction-guaranteed

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


Forum Replies

  1. system says:

    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. system says:

    What about this method, Rene?

    access-list 1 permit 1.1.1.0 0.0.0.255
    
    route-map NO-EXPORT permit 10
      match ip address 1
    
    neighbor 192.168.12.2 route-map NO-EXPORT out
    neighbor 192.168.13.3 route-map NO-EXPORT out

    Ofc we can use "match ip address prefix-list" as well. And my deepest respect for all what you do for us all.

  3. andrew says:

    Jason,
    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 1.1.1.1
    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
     *>  1.1.1.0/24       0.0.0.0                  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. andrew says:

    A route-map is not needed. Tying the as-path access-list to the neighbor via the filter-list argument is sufficient.

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

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