cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1138
Views
5
Helpful
7
Replies

TE and Inter AS material ???

Anand Solgama
Level 1
Level 1

Hi,

I am confuse in TE and Inter AS topics,please any one explain me these and give me easy material if have ????

I found something for Inter AS option A,B,C but was tuff and confusing couldnt clearly understand all

specially where to use "send-lable","next-hop unchanged"!!!!

Bye,

2 Accepted Solutions

Accepted Solutions

Nagendra Kumar Nainar
Cisco Employee
Cisco Employee

Hi,

"send-label" and "next-hop-unchanged" are not related to TE. They are related to InterAS.

By default, when BGP advertise a VPNv4 prefix with nexthop as self, it will assign a local label and advertise to neighbors. But with any otehr address-family, it needs to be explicitly mentioned. SO when a label needs to be advertised via BGP (for IPv6 Unicast or IPv4 unicast), we need to use "send-label" to instruct BGP to assign a local label.

"next-hop-unchaned" is used in Option C. Inter-As Option C is something used in operators where both AS opeators agrees to exchange their internal address details (can be limited to just the edge PE node loopback address). This is commonly seen in merge scenarios.

In such scenarios, we establish a VPNv4 session between RRs on each AS and mark it as next-hop-unexchanged. For example, assume the below simple scenario,

(PE1-AS1)-----(RR-AS1)-----(Edge-AS1)--------(Edge-AS2)------(RR-AS2)------(PE1-AS2)

Assume x-AS1 are in AS1 and x-AS2 are in AS2.

When Option C is used, PE1-AS1 address will be advertised to RR-AS1 adn Edge-AS1 via IGP used in AS1 (say IGP1) and PE1-AS2 address will be advertised to RR-AS2 and Edge-AS2 via IGP used in AS2 (say IGP2).

Now edge PE node details needs to be exchanged between AS. To be more specific, PE1-AS1 should be advertised to AS2 and PE1-AS2 to be advertised by AS1. This is simply done by BGP unicast session between Edge-AS1 and Edge-AS2 (this helps avoid anotehr instance of IGP between edge nodes). As mentioned by default only VPNv4 session assign and adveritise label while the session between Edge-AS1 and Edge-AS2 is IPv4 Unicast. So we need to explicitly mention "send-label".

All VPNv4 prefixes from PE nodes will be advertised to RR and in turn will be advertised to RR-AS2. eBGP will set the nexthop as self before advertiing. To overrule this, we use "nexthop-unchanged".

When VPN1 prefix is adverised by PE1-AS1 to RR-AS1, it set nexthop as self. RR-AS1 while advertising to RR-AS2 will NOT change teh nexthop (due to nexthop-unchanged). RR-AS2 will inturn advertise to PE1-AS2 without changing the nexthop (follows traditional iBGP behaviour).

PE1-AS2 will have in its local table the label advertised by PE1-AS1 and push it as bottom label. On top of it, it include the label to reach PE1-AS1 whcih was advertised by Edge-AS2 and middle label and top of it the IGP label to reach Edge-AS2.

HTH,

Nagendra

View solution in original post

Hi Anand,

(Kind of copy/paste from my blog that I wrote few years back )

Opton A --> Each AS will treat the otehr side AS a VRF customer. So no additional machinery/consideration required. For each VRF, there is a need for an interface between AS edge nodes whcih deems to be non scalable solution.

With Option B,

CE1-----PE1-----P1------ASBR1-----ASBR2----P2-----PE2---CE2

Assume PE1, P1 and ASBR1 are in in AS and ASBR2, P2 and PE2 are in otehr AS.

VPNv4-eBGP neighborship will be established between ASBRs without LDP between ASBRs.

Now when ASBR receives an VPNv4 prefix from other ASBR, as per iBGP rule, it will advertise the same to

other iBGP neighbors (other PEs) without changing the Next hop. As normally, the link between ASBRs will not

be advertised into our AS, we have 3 sub options to get it work. The 3 sub options as below,

Option B -2a – On ASBRs; configure “next-hop-self” to all iBGP neighbors (PEs). Label allocation happens in

PE1, ASBR1 and ASBR2.

Option B -2b – On ASBRs, when next-hop is not modified, a host entry (/32) will be installed as connected for

other ASBR. We need to redistribute this route into IGP using “redistribute connected” command. (If we have

more connected interface and which we don’t need to be redistributed, we can use a route-map that matches

only the host entry of ASBR). Label allocation happens in PE1 and ASBR1.

Option B – 2c – With above options (Option 2a, Option 2b), we run the risk of having single link failure. As part

of redundancy, we can have multiple links between ASBRs and establish eBGP neighborship between loopback

interfaces. Static routes need to be configured at ASBRs to reach the other ASBR’s loopback address and

should be redistributed using “redistribute static” command.

HTH,

Nagendra

View solution in original post

7 Replies 7

Nagendra Kumar Nainar
Cisco Employee
Cisco Employee

Hi,

"send-label" and "next-hop-unchanged" are not related to TE. They are related to InterAS.

By default, when BGP advertise a VPNv4 prefix with nexthop as self, it will assign a local label and advertise to neighbors. But with any otehr address-family, it needs to be explicitly mentioned. SO when a label needs to be advertised via BGP (for IPv6 Unicast or IPv4 unicast), we need to use "send-label" to instruct BGP to assign a local label.

"next-hop-unchaned" is used in Option C. Inter-As Option C is something used in operators where both AS opeators agrees to exchange their internal address details (can be limited to just the edge PE node loopback address). This is commonly seen in merge scenarios.

In such scenarios, we establish a VPNv4 session between RRs on each AS and mark it as next-hop-unexchanged. For example, assume the below simple scenario,

(PE1-AS1)-----(RR-AS1)-----(Edge-AS1)--------(Edge-AS2)------(RR-AS2)------(PE1-AS2)

Assume x-AS1 are in AS1 and x-AS2 are in AS2.

When Option C is used, PE1-AS1 address will be advertised to RR-AS1 adn Edge-AS1 via IGP used in AS1 (say IGP1) and PE1-AS2 address will be advertised to RR-AS2 and Edge-AS2 via IGP used in AS2 (say IGP2).

Now edge PE node details needs to be exchanged between AS. To be more specific, PE1-AS1 should be advertised to AS2 and PE1-AS2 to be advertised by AS1. This is simply done by BGP unicast session between Edge-AS1 and Edge-AS2 (this helps avoid anotehr instance of IGP between edge nodes). As mentioned by default only VPNv4 session assign and adveritise label while the session between Edge-AS1 and Edge-AS2 is IPv4 Unicast. So we need to explicitly mention "send-label".

All VPNv4 prefixes from PE nodes will be advertised to RR and in turn will be advertised to RR-AS2. eBGP will set the nexthop as self before advertiing. To overrule this, we use "nexthop-unchanged".

When VPN1 prefix is adverised by PE1-AS1 to RR-AS1, it set nexthop as self. RR-AS1 while advertising to RR-AS2 will NOT change teh nexthop (due to nexthop-unchanged). RR-AS2 will inturn advertise to PE1-AS2 without changing the nexthop (follows traditional iBGP behaviour).

PE1-AS2 will have in its local table the label advertised by PE1-AS1 and push it as bottom label. On top of it, it include the label to reach PE1-AS1 whcih was advertised by Edge-AS2 and middle label and top of it the IGP label to reach Edge-AS2.

HTH,

Nagendra

Wow!!!! friend too much exaplination I like but need to read two three more times to understand

Thanks so much for your answer. Do you have OPTION A,B with same details ....??? and have examples friend???

Bye,

Hi Anand,

(Kind of copy/paste from my blog that I wrote few years back )

Opton A --> Each AS will treat the otehr side AS a VRF customer. So no additional machinery/consideration required. For each VRF, there is a need for an interface between AS edge nodes whcih deems to be non scalable solution.

With Option B,

CE1-----PE1-----P1------ASBR1-----ASBR2----P2-----PE2---CE2

Assume PE1, P1 and ASBR1 are in in AS and ASBR2, P2 and PE2 are in otehr AS.

VPNv4-eBGP neighborship will be established between ASBRs without LDP between ASBRs.

Now when ASBR receives an VPNv4 prefix from other ASBR, as per iBGP rule, it will advertise the same to

other iBGP neighbors (other PEs) without changing the Next hop. As normally, the link between ASBRs will not

be advertised into our AS, we have 3 sub options to get it work. The 3 sub options as below,

Option B -2a – On ASBRs; configure “next-hop-self” to all iBGP neighbors (PEs). Label allocation happens in

PE1, ASBR1 and ASBR2.

Option B -2b – On ASBRs, when next-hop is not modified, a host entry (/32) will be installed as connected for

other ASBR. We need to redistribute this route into IGP using “redistribute connected” command. (If we have

more connected interface and which we don’t need to be redistributed, we can use a route-map that matches

only the host entry of ASBR). Label allocation happens in PE1 and ASBR1.

Option B – 2c – With above options (Option 2a, Option 2b), we run the risk of having single link failure. As part

of redundancy, we can have multiple links between ASBRs and establish eBGP neighborship between loopback

interfaces. Static routes need to be configured at ASBRs to reach the other ASBR’s loopback address and

should be redistributed using “redistribute static” command.

HTH,

Nagendra

very nice, 5+

by the way what is the best/simple way to send L3VPN traffic over Inter-AS TE tunnel using option B ?

Thanks friend for your reply again ....do you have any LABS or have idea of any site which has well designed labs???

Hi Anand,

You can try all 3 options in GNS3/dynamips without any issue. You may need 3 routers in each AS (ingress PE, RR and egress PE/ASBR ) and 2 CE connected to each ingress PE.

something like below,

CE1------PE1-----RR-----ASBR1----ASBR2----RR2---PE2----CE2

-Nagendra

Thanks again for answer

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: