关于inter-as mpls vpn# EmergingNetworking - 热门网络技术
p*a
1 楼
目前国外各大运营商主要用哪个option来做为互连方式？ 以前可能A用的比较多，现在
是不是已经在考虑转到C了？
是不是已经在考虑转到C了？
s*g
2 楼
The most popular option is option C, the problem with option A is
scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
【在 p***a 的大作中提到】
: 目前国外各大运营商主要用哪个option来做为互连方式？ 以前可能A用的比较多，现在
: 是不是已经在考虑转到C了？
scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
【在 p***a 的大作中提到】
: 目前国外各大运营商主要用哪个option来做为互连方式？ 以前可能A用的比较多，现在
: 是不是已经在考虑转到C了？
z*r
3 楼
nod, and I don't think option A has ever been popular. All 3 options are
defined in the same RFC (2547bis then 4364), that means when ppl think of
inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
very obviously, tho it looks very simple. However, when 2 SP's talking about
inter-as vpn connectivity, they normally want some strategy inter-
connectivity, not just case by case, which is as you said, not scale, high
maintain cost.
the problem of option C is it requires 2 SP
【在 s*****g 的大作中提到】
: The most popular option is option C, the problem with option A is
: scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
defined in the same RFC (2547bis then 4364), that means when ppl think of
inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
very obviously, tho it looks very simple. However, when 2 SP's talking about
inter-as vpn connectivity, they normally want some strategy inter-
connectivity, not just case by case, which is as you said, not scale, high
maintain cost.
the problem of option C is it requires 2 SP
【在 s*****g 的大作中提到】
: The most popular option is option C, the problem with option A is
: scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
d*i
4 楼
//hand. I think option B is also easier to implement compared to option C. for example, our
testcenter can test this using option b only because we almost don't need to
do anything additional to implement this test.
is
about
route
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
testcenter can test this using option b only because we almost don't need to
do anything additional to implement this test.
is
about
route
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
z*r
5 楼
right, option C increases the complexity because of the route reflectors
btw, are you still busy everyday? and how was your interview?
for example, our
to
【在 d****i 的大作中提到】
: //hand. I think option B is also easier to implement compared to option C. for example, our
: testcenter can test this using option b only because we almost don't need to
: do anything additional to implement this test.
:
: is
: about
: route
btw, are you still busy everyday? and how was your interview?
for example, our
to
【在 d****i 的大作中提到】
: //hand. I think option B is also easier to implement compared to option C. for example, our
: testcenter can test this using option b only because we almost don't need to
: do anything additional to implement this test.
:
: is
: about
: route
p*a
6 楼
option b is not very scalable and has some security concerns.
is
about
route
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
is
about
route
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
p*a
7 楼
actually some vendors still don't support option c yet. option c also has
some security concerns.
option C is not trivial, while option A does not need any special handling
besides basic MPLS-VPN implementation, so option A is kind of poor man's
Inter-AS solution, any vendor t
【在 s*****g 的大作中提到】
: The most popular option is option C, the problem with option A is
: scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
some security concerns.
option C is not trivial, while option A does not need any special handling
besides basic MPLS-VPN implementation, so option A is kind of poor man's
Inter-AS solution, any vendor t
【在 s*****g 的大作中提到】
: The most popular option is option C, the problem with option A is
: scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
s*g
8 楼
Could you please elaborate what are the security concerns of option B and
option C?
And how are those security concerns are addressed by option A?
IPsec over MPLS is always an option if customers are paranoid.
【在 p***a 的大作中提到】
: actually some vendors still don't support option c yet. option c also has
: some security concerns.
:
: option C is not trivial, while option A does not need any special handling
: besides basic MPLS-VPN implementation, so option A is kind of poor man's
: Inter-AS solution, any vendor t
option C?
And how are those security concerns are addressed by option A?
IPsec over MPLS is always an option if customers are paranoid.
【在 p***a 的大作中提到】
: actually some vendors still don't support option c yet. option c also has
: some security concerns.
:
: option C is not trivial, while option A does not need any special handling
: besides basic MPLS-VPN implementation, so option A is kind of poor man's
: Inter-AS solution, any vendor t
s*g
9 楼
Of course you don't run IGP between to SPs for option C, this is a basic
requriement of any inter-AS, no IGP between ASBRs.
Problem with option B is also obvious, ASBRs have to be VPN aware (you need
to configure vrf/vpn address family under ASBR's bgp in order to exchange
VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
imagine if you have a dozen customers and each customer wants to have whole
Internet routes ..., not many vendors on the market can do over 1M routes
hardw
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
requriement of any inter-AS, no IGP between ASBRs.
Problem with option B is also obvious, ASBRs have to be VPN aware (you need
to configure vrf/vpn address family under ASBR's bgp in order to exchange
VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
imagine if you have a dozen customers and each customer wants to have whole
Internet routes ..., not many vendors on the market can do over 1M routes
hardw
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
z*r
10 楼
I actually wanted to mean the IGP routes are exchanged between AS's in
option C, because an ASBR must have the knowledge of all loopbacks of the PE
routers within the AS, then uses eBGP to advertise them to other AS's. This
requires greater trust between 2 SP's.
Also a lot of situations that ppl use RR to improve the scalability, thus
the eBGP connections exist only between the blue RR in the blue AS and the
green RR in the green AS.
In option B, ASBR VPN awareness shouldn't be a problem at all,
【在 s*****g 的大作中提到】
: Of course you don't run IGP between to SPs for option C, this is a basic
: requriement of any inter-AS, no IGP between ASBRs.
: Problem with option B is also obvious, ASBRs have to be VPN aware (you need
: to configure vrf/vpn address family under ASBR's bgp in order to exchange
: VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
: imagine if you have a dozen customers and each customer wants to have whole
: Internet routes ..., not many vendors on the market can do over 1M routes
: hardw
option C, because an ASBR must have the knowledge of all loopbacks of the PE
routers within the AS, then uses eBGP to advertise them to other AS's. This
requires greater trust between 2 SP's.
Also a lot of situations that ppl use RR to improve the scalability, thus
the eBGP connections exist only between the blue RR in the blue AS and the
green RR in the green AS.
In option B, ASBR VPN awareness shouldn't be a problem at all,
【在 s*****g 的大作中提到】
: Of course you don't run IGP between to SPs for option C, this is a basic
: requriement of any inter-AS, no IGP between ASBRs.
: Problem with option B is also obvious, ASBRs have to be VPN aware (you need
: to configure vrf/vpn address family under ASBR's bgp in order to exchange
: VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
: imagine if you have a dozen customers and each customer wants to have whole
: Internet routes ..., not many vendors on the market can do over 1M routes
: hardw
p*a
11 楼
i agree with you more on this.
but actually different ASes can be in a singile IGP domain, of course, in
this case the ASes should belong to a same provider.
need
whole
PEs
【在 s*****g 的大作中提到】
: Of course you don't run IGP between to SPs for option C, this is a basic
: requriement of any inter-AS, no IGP between ASBRs.
: Problem with option B is also obvious, ASBRs have to be VPN aware (you need
: to configure vrf/vpn address family under ASBR's bgp in order to exchange
: VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
: imagine if you have a dozen customers and each customer wants to have whole
: Internet routes ..., not many vendors on the market can do over 1M routes
: hardw
but actually different ASes can be in a singile IGP domain, of course, in
this case the ASes should belong to a same provider.
need
whole
PEs
【在 s*****g 的大作中提到】
: Of course you don't run IGP between to SPs for option C, this is a basic
: requriement of any inter-AS, no IGP between ASBRs.
: Problem with option B is also obvious, ASBRs have to be VPN aware (you need
: to configure vrf/vpn address family under ASBR's bgp in order to exchange
: VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
: imagine if you have a dozen customers and each customer wants to have whole
: Internet routes ..., not many vendors on the market can do over 1M routes
: hardw
p*a
12 楼
for option b, the security concern is label spoofing at the asbr
for option c, the security concern is access to all PEs from the remote AS
yes you can use some tools such as filter to reduce the risk but SPs still
should worry about it.
【在 s*****g 的大作中提到】
: Could you please elaborate what are the security concerns of option B and
: option C?
: And how are those security concerns are addressed by option A?
: IPsec over MPLS is always an option if customers are paranoid.
for option c, the security concern is access to all PEs from the remote AS
yes you can use some tools such as filter to reduce the risk but SPs still
should worry about it.
【在 s*****g 的大作中提到】
: Could you please elaborate what are the security concerns of option B and
: option C?
: And how are those security concerns are addressed by option A?
: IPsec over MPLS is always an option if customers are paranoid.
相关阅读
两个房子其中一个有宽带, 如何能让另一个房子也用上这个宽带?TD：最坏的自主创新Sr. Software Engineer PositionCSCO 夏末砍人 (转载)请大侠给小弟推荐一本wireless的书吧。什么是cloud-based unified communication啊海归回国深造，回国前的挥泪大甩卖，看着就能让你心动的物品谁最近考了笔试，能不能提供点材料？版上大侠推荐的mpls-enabled applicationwifi还有什么发展前景么...Voice里面的signaling。大家说说看学习BGP要不要先弄明白IGPF5 BIG-IP Engineer positionsfibre port下面duplex用什么呢？lets talk about flaws of CISCO IOS为什么美国没有pplive/ppstream?xmodem真funny啊。问：企业级网络大家来分析一下这次思科裁人对market的影响吧RTP吃饭，版聚？