1) Exchanging and using the VPN information, for this the Multi-hop MP-EBGP is done between the RR's.
2) Exchanging and using the IGP next-hop information, for this the ASBR's exchange the IGP-next-hops routes in their domain with the other AS including the Label for that route. This is done using SAFI identifiers using a IPV4 EBGP peering between the ASBR's.
When a packet has to traverse from AS1 to AS2.
It will check the VPN routing table which says it has received this label from a PE in AS2 for which the next-hop is ASBR1.
So the local PE inserts a label stack with the VPN label received from the other side (this was received by MP-EBGP between RR's), and the IGP label for the PE in AS2 ( this label was received from ASBR1, which in turn got it from ASBR2 with the route and also the label to use to reach the PE in AS2).
When this MPLS packet arrives at the ASBR1 it looksup the label forwarding table and swaps the topmost IGP label with the label received from ASBR2 to reach the PE in AS2.
So to summarize, the label imposition and swapping happens as in normal MPLS only there is no special difference. Only difference is how this VPN and IGP label information is exchanged.
PS: there are couple of other methods for INter-AS which help you to exchange the VPN and IGP information in different ways.But the concept remains the same.
Hey Swaroop nice explaination, in order not to confuse the original poster, i think that what you meant by "The frame format doesn't change" that its an ordinary MPLS frame using the label received from the other AS despite the method (Options 1, 2a, and 3 according to the RFC).
XIAO, please refer to the following presentation and the RFC for more details:
ADVANCED CONCEPTS: INTER-AUTONOMOUS SYSTEM MPLS VPN
I can understand inter-as packet transfer when using ldp. In the book 《MPLS and VPN architectures》,the process of Label swap along the path is clearly described.But I have no idea when ldp is replaced by bgp.
There is no difference in the logic of MPLS label swapping or frame structure, the whole difference between LDP and MPBGP label propagation is the way they work.
In the case of LDP, for every IGP IP prefix in its IP routing table, each LSR creates a local binding, it binds a label to the IPv4 prefix. The LSR then distributes this binding to all its LDP neighbors. These received bindings become remote bindings. The neighbors then store these remote and local bindings in a special table, the label information base (LIB).
BGP-4 is described in RFC 1771, but that RFC describes only the use of BGP to carry IPv4 prefixes. BGP can do much more than carry IPv4 prefixes. RFC 2858, "Multiprotocol Extensions for BGP-4", was written to extend BGP as being able to carry other routing information than IPv4.
BGP advertises the vpnv4 prefixes in the MPLS VPN network. This is not enough to be able to forward the VPN traffic correctly. For the egress PE router to be able to forward the VPN traffic correctly to the CE router, it must forward the packet based on a label. The egress PE router can map such a label to the vpnv4 prefix, it is called the VPN label. The egress PE router must advertise the label along with the vpnv4 prefix to the possible ingress PE routers. The encoding of the label with the prefix is described in RFC 3107, "Carrying Label Information in BGP-4." The label is simply piggybacked along with the vpnv4 prefix and advertised by BGP using the multiprotocol extensions attribute.
To cut the confusion short here....the orginal post was about the data plane so the explanation should not give rise to any confusion...infact fits the bill well.
Infact giving reference to standard Inter-AS configuration or RFC would be termed inappropriate in this specific scenario.
The logic behind giving an explanation was to elaborate on data flow where as standards only describe the control plane of the flow. The explanation would answer the question would be frame format change, No it doesnt.. Inter-AS is only means of advertising IGP and VPN labels across AS's, as MPLS end of the day is bothered only about labels to switch data.
Hope I have been clear.
The book by Ivan is a good resource. Since you would like to know when LDP is replaced by BGP, and what is the data plane for the same. I would suggest rather than going by the standard CCO documents or RFC, you may want to try a small lab excercise below. This will help you understand the concept inside out.
1) Form IGP adjacency between your ASBR's and enable LDP and everything will work fine.
2) Or mutual Redistribution of IGP into local BGP and advertise to other AS and do vice versa, and run LDP on the link between both ASBR's. This will work still.
Here the point you will note is, in real world the ISP wont allow each other to run IGP with each other (unless both the AS's are controlled by the single entity) or neither perform a IGP<->BGP mutual redistrbution.
So exchanging the topmost labels with IPV4 BGP which supports exchange of routes with labels to be used to reach those routes is implemented.
PS: Do note that labels are not generated by LDP for BGP routes, that is the main reason this whole jugglery is done.
The point is that the confusion of the original poster (IMHO) was between LDP and BGP behavior (control plane, despite he stated data plane, he needs to well understand the control plane frist) and thus i elaborated further in it according to his words "But I have no idea when ldp is replaced by bgp." as he needs to understand the control plane before thinking about the data plane
Any way the target is for the original poster to understand what ever the approach is, we are all trying to help with different perspectives and opinions.
I hope that i've made my self clear, please take care and have a nice day.
1. Introduction Internet security is important with the increasing
attacks that are happening every day. Many internet and browsing
security solutions exist, but some are not very easy to use or maybe the
question is how can I enable them? In this referen...
Cisco Software Manager Server API Guide This document describes the
programmatic interfaces, RESTful APIs, which are supported by Cisco
Software Manager Server (CSM Server). Overview CSM Server supports a set
of finite RESTful APIs. The first step to use ...
If you are using Cisco's new linux-based Cisco Software Manager server,
then you probably want to make sure there is a startup service for
it.I'll assume that you've already installed the CSM server on a
systemd-based linux system. The commands given belo...