Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

peering in transit AS

hi experts,

please help me in finding a solution for this scenario.

A transit AS has peering with 4 upstream providers and 7 downstream customer peerings.customers are multihomed to our AS.

(i)i want to separate the transit and peering traffic(traffic between customers)

.. ie one link from customer specifically for transit traffic and other one for peering traffic alone.

(ii)how can i implement this scenario using BGP communities or any other method.

Thanks in advance


New Member

Re: peering in transit AS

Hi Arjun,

If I understood your scenario correctly, we can use BGP AS Path selection tool to make one path as transit by giving High priority (may be AS PATH PREPAND) and Other comparatively less.

HTH. I am looking for other experts comments also


Hall of Fame Super Silver

Re: peering in transit AS

Hello Arjun,

I understood that there are some customers multi-homed with your AS ISP1 and with the other AS let's call it ISP2.

This is common in the internet.

You want to have a peering relationship on one link Link1 where ISP1 and ISP2 agree to exchange their customers' routes.

Then there is another link where you ISP1 wants to use ISP2 as one of your upstream provider receiving a BGP full table from them and paying money for bytes sent on the link link2.

You can use local preference in the following manner:

default value is 100 the highest value is preferred.

give local preference 80 to all routes received on link link2

leave local preference 100 on routes received on link1

increase to 150 local preference on routes received from your own customers.

So you achieve:

route to your own customers first

route to my peering partners

at the end if no peering partner provides the route use of the upstream provider.

local preference is the right tool because it is propagated in all your AS .

This kind of settings is typical in an ISP.

For scalability and to make an auto adaptive configuration local preference can be set using match on BGP communities.

This is used when multihomed customers and the two ISPs cooperate to try to have customer's links used in a fair way also for the return traffic.

And for other possible needs/policies.

Hope to help


New Member

Re: peering in transit AS

hi Giuseppe,

Thanks for your quick response.i think u misunderstood the scenario.Please check the attached diagram.There is only one ISP(say AS 100) and the customers(say AS 20,AS 30,AS 40) are peering to this ISP through 2 paths as shown in link(link 1) is active and the other link act as reduntant link(link 2).Wht we plan to implement is to use the first link(link 1) for transit to internet and the other link(link 2)for peering traffic between the customers(AS 20,AS 30,AS 40)) peering to this ISP-AS(AS 100)

New Member

Re: peering in transit AS


We will configure LINK-2 as to prepend with the same AS Number, so that LINK-1 will be the best Route in BGP table and LINK-2 will however peer and exchange the Route.

I tested this in Lab and seems to be fine.

Experts, any comments on this please



Re: peering in transit AS

Hi Arjun,

with regard to (Link 1) on AS 100 border, i would configure it as follows:

1- Only Allow the particular AS to be recieved on AS 100 router, this is achieved by applying filter-list inbound with : ^20$ or ^30$ or ^40$

2- On AS 100 border , you would also advertise only locally originated routes and you should prevent every customer from using the particular link-1 for other than transit traffic by configuring the following:

a- applying a filter-list outpound direction allowing only locally originated routes with : ^$

b- applying a community to be sent to each customer to prevent them advertising your networks by sending a well known (no-export) community to all link-1 neighbor. This will ensure all customers should transitly go through AS 100 and for peering they will have to go also through AS-100 to reach other ASs.

example for customer AS-20:

neighbor x.x.x.x remot-as 20

neighbor x.x.x.x sent community

neighbor x.x.x.x default-originate

neighbor x.x.x.x filter-list 10 out

neighbor x.x.x.x route-map 20 out

neighbor x.x.x.x filter-list 11 in

ip as-path access-list 10 permit ^$

ip as-path access-list 11 permit ^20$

route-map 20 permit 10

match as-path 10

set community no-export


(The Locally Originated routes should be AS-100 Networks and adefault-route to the Internet)

(Likewise, the config is the same for all neighbors).

With Regard to link-2 (Peering) traffic between Customers through AS-100:

1- I would allow all customer prefixes (ASs 20,30,40) to be sent to evry particulat AS neighbor and Only accept the particular AS Networks on AS-100 border router as follows:

1- neighbor x.x.x.x remote-as 20

neighbor x.x.x.x prefix-list AS20 out

neighbor x.x.x.x filter-list 1 in

2- neighbor y.y.y.y remote-as 30

neighbor y.y.y.y prefix-list AS30 out

neighbor y.y.y.y filter-list 2 in

IP prefix-list AS20 permit (ALL Networks belongs to ASs 30,40)

ip as-path access-list 1 permit ^20$

--- The config is the Same for Neighbor AS-30 ---



New Member

Re: peering in transit AS

Hello Mohamed,

Thanks for your reply

In this for transit traffic AS20 takes link-1 and for pering routes it takes link-2 .

but how we can dedicate link-1 for transit traffic only (both inbound and outbound transit traffic to link 1 only )and link 2 for peering traffic only (both inbound and outbound traffic from peers to link 2 only ).

in this configuration AS100 is receviing local from A20 through link 1 and link 2 .so which link it takes to reach AS20 from AS100.

how we can seperate transit traffic to link 1 and peering traffic to link 2.(AS20 Inbound traffic )



Hall of Fame Super Silver

Re: peering in transit AS

Hello Arjun,

I see that your scenario is different from what I had supposed/guessed on my post.

In your case customers have multiple links with provider AS 100.

You would like to use one link for sending traffic to the big internet and one for reaching other customers of AS 100.

This part can be achieved with MED having a lower MED on link2 and having link2 eBGP session advertising only customer routes.

The difficult part comes for the return traffic:

BGP provided limited capabilities to influence return path.

So first of all you cannot be sure that return traffic comes back to AS 100!

You can be sure only if customers have no other upstream provider.

Second point is that BGP propagates only its best path choice and this choice cannot change to different neighbors.

So how to deal with this:

BGP alone is not enough.

We should use an MPLS VPN for the traffic between customers.

By putting traffic on links type 2 on a different routing table this traffic is confined and also return path can be assured (traffic inside the MPLS VPN stays inside the VPN) on a topology formed only by links2 subset.

links type1 are in global routing table

Hope to help


Re: peering in transit AS

Hi Arjun,

The problem would be in the return traffic comes from AS100 to AS20. In my previous example AS100 could reach AS20 by either link which is not your desired objective.

As Gui suggested, why dont you implement MPLS-VPN for the customer traffic and leave the transit traffic fo the internet in the Global routing table.

By putting every customer into their respective VRF, you would ensure traffic inbound and outbound routed as you want and the default traffic (Internet) is coming through link-1.



New Member

Re: peering in transit AS

Hi Guiseppe/Mohammed

can u pls provide me some sample configuration to be done in transit as side and customer will be very helpfull to me..

Hall of Fame Super Silver

Re: peering in transit AS

Hello Arjun,

look at MPLS VPN with BGP as PE-CE protocol.

on the customer side nothing special in the configuration.

link2 types will be access link in VRFs link1 types will be in the routing table.

ip vrf mycustomers

rd 100:100

route-target import 100:100

route-target export 100:100

int type x/y

desc link2 vrf access

ip vrf forwarding mycustomers

ip address x.x.x.x y.y.y.y

router bgp 100

no bgp default ipv4-unicast

address-family vpnv4

! here mp bgp sessions to Route reflectors

neigh z.z.z.z activate

neigh z.z.z.z send-community extended

address-family vrf mycustomers

red connected

no sync

no auto-summary

! neighbors in links2 type link

neigh x.x.x.w remote-as 10

neigh x.x.x.w activate

this has to be done on AS100 routers with link2 connections that become PE nodes.

you need also to setup mpls forwarding on your AS 100 backbone

Hope to help


Re: peering in transit AS

Hello Arjun,

I see Gui has provided sample config, the example applicable if you have more than one router in ur backbone which terminates all your customers ASs.

But If you have only AS-100 in a single router terminates all your customers, you should think about (VRF-Lite) without involving MPLS in this case.



CreatePlease to create content