10-08-2013 04:49 AM
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,
Solved! Go to Solution.
10-13-2013 06:41 AM
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
10-16-2013 06:10 PM
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
10-13-2013 06:41 AM
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
10-14-2013 06:08 AM
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,
10-16-2013 06:10 PM
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
10-20-2013 05:50 AM
very nice, 5+
by the way what is the best/simple way to send L3VPN traffic over Inter-AS TE tunnel using option B ?
10-25-2013 05:23 AM
Thanks friend for your reply again ....do you have any LABS or have idea of any site which has well designed labs???
10-25-2013 02:35 PM
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
10-26-2013 09:33 PM
Thanks again for answer
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: