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.
  • [geot exclude_region="No Trial" ] Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career![/geot]
  • Full Access to our 541 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

294 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!


Notable Replies

  1. Many thanks for the lesson, it's very easy to understand!

  2. navn1 says:

    Hi,

    I would appreciate if you can talk about how to advertise routes toward inside your network.

    let say you have r1 and r2 are mutihome. R1 to isp1 and R2 to isp2 (getting bgp full table). Now let say you have R1 and R2 criss cross connected to nexus 7k inbound. I know you can run iBGP but that would be too many routes to your switches. What would be a good solution in this situation?

    Thanks,
    Nav

  3. Hi Nav,

    If R1 and R2 are the only exit points for your network then a default route will do the job, no need to run iBGP on all your internal devices.

    Rene

  4. Hi Diana,

    Do you mean the startup configurations?

    In the most recent lessons I have been adding the final configurations, for example:

    MPLS Layer 3 VPN PE CE OSPF

    Rene

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

Continue the discussion forum.networklessons.com

29 more replies

Participants