Junos vrf-table-label komutu

Genel olarak amacı, ingress PE ve Egress PE arasındaki end to end LSP bozmak, ve egress PE’de çıkışdan önce ip veya adj look-up yapmakdır.

PE’nin gelen pakedi uygun next-hop’a göndermesi için (IP lookup yapması gereken durumlarda), bu komuta ihtiyaç vardır.

CE-PE arasındaki bağlantı ethernet gibi paylaşımlı bir ortam ise, PE’nin pakedi hangi next-hop’a göndereceğini bilmesi gerekir (mac encapsulation vb). Noktadan noktaya olan durumlarda ip headerına bakmadan direk karşı uca pakedi gönderebilir.

Başka bir örnek ise bir PE’de aynı routing-instance (MPLS L3 VPN) dagil birden fazla CE var, ve bir prefix’i birden fazla CE’den duyuyor ise aynı şekilde PE’nin ip başlığına bakarak uygun next-hop’a göndermesi gerekir.

Aryıca egress PE’de bazı ip özellikleinin uygulanması için, COS, multicast vb pakedin ip olarak el alınması ve switch edilmeden önce incelenmesi için bu komuta gerek vardır. Bu şekilde CE CE arası LSP bozulmuş olur.

Bu konu ile ilgili olarak ayrıca l3VPN inner label allocation konusuda bakılmalıdır.

Genel olarak 3-tip vardır.

1 – Per-Prefix

2 – Per-CE

3 – Per VPN

 

Hi,

 

If you have multi access interface like ethernet, you will need to add relevant MAC address before sending it out. Say you have multiple CE routers connected to PE over same i/f behind a CE switch. Based on which CE router advertised the route, PE will need to add the relevant MAC address and hence will need multiple lookups (one for identifying the VRF and 2nd lookup for identifying the end router which advertised the route).

Bakınız : J-Net communitiden güzel bir açıklama.

http://forums.juniper.net/t5/Routing/vrf-table-label-why-it-s-for/td-p/82736

If you have point-point link, PE can just pop the VPN label and send it to CE with out the need of doing an IP lookup.

 

Let me show by some example

 

                                |—–CE-B

CE-A——–R1—–R2——R3—|

                                |

R1 and R3 are PEs here

 

Here, assume CE-A and R1 connection is sonet with ppp encapsulation. Connection between R3 and CE-B is ethernet. You will need to set vrf-table-label on R3 but you need not set vrf-table-label on R1

 

Configs on R1 (without vrf-table-label)

 

Pavan@R1# show routing-instances
VPN-A {
instance-type vrf;
interface so-0/0/1.0;
route-distinguisher 65221:111;
vrf-target target:65221:111;
protocols {
bgp {
group ext {
type external;
as-override;
neighbor 10.1.1.2 {
peer-as 65000;
}
}
}
}
}

 

Configs on R3:

Pavan@R3# show routing-instances
VPN-A {
instance-type vrf;
interface ge-3/1/2.0;
route-distinguisher 65221:112;
vrf-target target:65221:111;
vrf-table-label; <——
protocols {
bgp {
group ext {
type external;
as-override;
neighbor 20.1.1.2 {
peer-as 65000;
}
}
}
}
}

[edit]

 

I’ve advertised 191.1.1.0/24 from CE-A., If you see these routes on R1 (where no vrf-table-label is configured)

 

Pavan@R1# run show route advertising-protocol bgp 3.3.3.3 extensive

VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
* 10.1.1.0/30 (1 entry, 1 announced)
BGP group int type Internal
Route Distinguisher: 65221:111
VPN Label: 299824
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65221] I
Communities: target:65221:111

* 191.1.1.0/24 (1 entry, 1 announced)
BGP group int type Internal
Route Distinguisher: 65221:111
VPN Label: 299840 <———————————
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65221] 65000 I
Communities: target:65221:111

[edit]
Pavan@R1# run show route table mpls.0

mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both

0                  *[MPLS/0] 00:23:23, metric 1
Receive
1                  *[MPLS/0] 00:23:23, metric 1
Receive
2                  *[MPLS/0] 00:23:23, metric 1
Receive
299776             *[LDP/9] 00:20:05, metric 1
> to 120.1.1.2 via ge-2/1/1.0, Pop
299776(S=0)        *[LDP/9] 00:20:05, metric 1
> to 120.1.1.2 via ge-2/1/1.0, Pop
299792             *[LDP/9] 00:13:54, metric 1
> to 120.1.1.2 via ge-2/1/1.0, Swap 300352
299824             *[VPN/170] 00:02:06
> via so-0/0/1.0, Pop
299840             *[VPN/170] 00:02:02
> to 10.1.1.2 via so-0/0/1.0, Pop       <———-

[edit]

 

You can see that the operation is Pop and ship to i/f so-0/0/1.0 for VPN label 299840

 

Check the same for R3 where vrf-table-label is enabled

===============================

I am pumping 181.1.1.0/24 from CE-B

 

Pavan@R3# run show route advertising-protocol bgp 1.1.1.1 extensive

VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
* 20.1.1.0/24 (1 entry, 1 announced)
BGP group int type Internal
Route Distinguisher: 65221:112
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65221] I
Communities: target:65221:111

* 181.1.1.0/24 (1 entry, 1 announced)
BGP group int type Internal
Route Distinguisher: 65221:112
VPN Label: 16 <————–
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65221] 65000 I
Communities: target:65221:111

 

Pavan@R3# run show route table mpls.0

mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both

0                  *[MPLS/0] 00:14:36, metric 1
Receive
1                  *[MPLS/0] 00:14:36, metric 1
Receive
2                  *[MPLS/0] 00:14:36, metric 1
Receive
16                 *[VPN/0] 00:14:36
to table VPN-A.inet.0, Pop     <———————————-
299904             *[LDP/9] 00:14:26, metric 1
> to 130.1.1.2 via ge-3/0/5.0, Pop
299904(S=0)        *[LDP/9] 00:14:26, metric 1
> to 130.1.1.2 via ge-3/0/5.0, Pop
299920             *[LDP/9] 00:14:26, metric 1
> to 130.1.1.2 via ge-3/0/5.0, Swap 300336

[edit]

 

Pavan@R3# run show route table VPN-A.inet.0 181.1.1.0/24

VPN-A.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both

181.1.1.0/24       *[BGP/170] 00:24:17, localpref 100
AS path: 65000 I
> to 20.1.1.2 via ge-3/1/2.0

[edit]
Pavan@R3#

 

If you observe above, for VPN label 16, it is popping and sending to table VPN-A.inet.0 (instead of earlier case where it was sending out of ifl).

 

Note that VPN label 16 is special label allocated for LSI i/f (Created because of vrf-table-label)

 

Pavan@CE-B# run ping 191.1.1.1
PING 191.1.1.1 (191.1.1.1): 56 data bytes
64 bytes from 191.1.1.1: icmp_seq=0 ttl=62 time=0.939 ms
^C
— 191.1.1.1 ping statistics —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.939/0.939/0.939/0.000 ms

 

Pavan@CE-A# run ping 181.1.1.1 logical-system delany-LR1
PING 181.1.1.1 (181.1.1.1): 56 data bytes
64 bytes from 181.1.1.1: icmp_seq=0 ttl=61 time=0.660 ms
64 bytes from 181.1.1.1: icmp_seq=1 ttl=61 time=0.848 ms
64 bytes from 181.1.1.1: icmp_seq=2 ttl=61 time=25.814 ms
^C
— 181.1.1.1 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.660/9.107/25.814/11.814 ms

 

Hope this helps

 

If you like the explanation kudos will be appreciated 🙂

 

Thanks,

Pavan Kurapati

 

run show route table mpls.0 label 16 detail

mpls.0: 141 destinations, 141 routes (141 active, 0 holddown, 0 hidden)
Restart Complete
16 (1 entry, 0 announced)
*VPN Preference: 0
Next hop:
Next table: MPLS_VPN.inet.0 –> MPLS_VPN.inet.0 tablosuna bakarak pakedin iletileceğini gosteriyor.
Label operation: Pop
Address: 0x3016db8
Next-hop reference count: 1
State: <Active NotInstall Int Ext>
Local AS: xxxx
Age: 16:49:48
Task: RT
AS path: I

 

http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/vpns-filtering-packets-in-layer-3-vpns-based-on-ip-headers.html

Leave a Reply

Your email address will not be published.