[j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue

Nalkhande Tarique Abbas ntarique at juniper.net
Mon Oct 5 06:10:41 EDT 2009


Hi Jimmy,

How about adding another term in your premium-export policy ..

term export-CT {
    from community csr-CT-vrf;
    then accept;
}

... before reject on both the sides. 


Coming to your query on direct route in bgp.l3vpn table, do you mean
this is a direct route from inet.0? Is this BGP peer not under any VRF &
at a global level?

 

Thanks & Regards,
Tarique A. Nalkhande

-----Original Message-----
From: Jimmy Halim [mailto:jimmy at pacnet.net] 
Sent: Monday, October 05, 2009 2:52 PM
To: Nalkhande Tarique Abbas; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables
Issue

Hi Tarique,

Yes, I am leaking CT crf routes into premium vrf on router A using the
community.

policy-options policy-statement csr-rib-policy-from-CT-vrf-peer
term aloha {
    from {
        community csr-CT-vrf;
    }
    to rib vrf_premium.inet.0;
    then {
        accept;
    }
}

==========================
Export policy on router A:

routing-instances vrf_premium:
instance-type vrf;
route-distinguisher 1.1.1.1:9005;
vrf-export premium-export;
vrf-table-label;

====
policy-options policy-statement premium-export:
term add-premium {
    from protocol [ direct static bgp ];
    then {
        community add rt-premium;
        accept;
    }
}
then reject;

====
community rt-premium:
members target:10026:9005;

===========================
Import policy on router B:

routing-instances vrf_premium:
instance-type vrf;
route-distinguisher 2:2:2:2:9005;
vrf-import premium-import;
vrf-table-label;

====
policy-options policy-statement premium-import
term add-premium {
    from community rt-premium;
    then accept;
}
then reject;

====
community rt-premium:
members target:10026:9005
========================

By the way, what do you think of the route table bgp.l3vpn.0?
Is it correct to say that it shouldn't show the direct peering routes
that
is provisioned on the same PE?

route table bgp.l3vpn.0 61.217.192.0/18
 
bgp.l3vpn.0: 316803 destinations, 316803 routes (316803 active, 0
holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
 
122.122.122.1:9003:61.217.192.0/18
                   *[BGP/170] 6w6d 21:34:02, MED 100, localpref 250,
from
122.5.5.1
                      AS path: 1334 I
                      to 122.5.5.2 via so-1/2/0.0 ---------> Direct
peering
interface
                    > to 122.5.5.3 via so-1/3/0.0 ---------> Direct
peering
interface
==========================

Cheers,
Jimmy


-----Original Message-----
From: Nalkhande Tarique Abbas [mailto:ntarique at juniper.net] 
Sent: Monday, October 05, 2009 4:55 PM
To: Jimmy Halim; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables
Issue


<You said>

--I have confirmed that in router A, all the routes that are learned via
direct peering (CT vrf) are inside premium vrf route table. 

--I can confirm that direct connected, static, and customer's BGP routes
that are provisioned in router A under premium vrf are being seen under
router B under premium vrf. So the issue is only on those routes that
are
learned via direct peering under CT vrf. Those routes are not advertised
to
router B premium vrf. Any clue?



<Tarique>
So how do you leak CT vrf routes into premium vrf on router A, by means
of
community? These routes certainly won't fall under static, direct or
customers bgp (of premium).

With the available information, I would still doubt the export policy on
router A & import on router B of premium vrf. Though having a look at
outputs/config on both sides would help.


 
Thanks & Regards,
Tarique A. Nalkhande


-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Jimmy Halim
Sent: Monday, October 05, 2009 2:03 PM
To: juniper-nsp at puck.nether.net
Cc: jimmy at pacnet.net
Subject: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue

Hi guys,
 
I have a situation where the PE (router A) is not advertising the routes
that they got from direct peering (for example under CT vrf) to other PE
(router B) under different vrf (for example premium vrf).
 
I have confirmed that in router A, all the routes that are learned via
direct peering (CT vrf) are inside premium vrf route table.
It means the import policy is working.
 
The strange thing, thouse routes are not being advertised to premium vrf
in
router B. I have confirmed there is no problem with export policy in
router
A and import policy in router B.
 
In router A, under route table bgp.l3vpn.0, I am seeing the route that
is
learned via direct peering interface. This shouldn't be the case right?
 
==============================
route table bgp.l3vpn.0 61.217.192.0/18
 
bgp.l3vpn.0: 316803 destinations, 316803 routes (316803 active, 0
holddown,
0 hidden)
+ = Active Route, - = Last Active, * = Both
 
122.122.122.1:9003:61.217.192.0/18
                   *[BGP/170] 6w6d 21:34:02, MED 100, localpref 250,
from
122.5.5.1
                      AS path: 1334 I
                      to 122.5.5.2 via so-1/2/0.0 ---------> Direct
peering
interface
                    > to 122.5.5.3 via so-1/3/0.0 ---------> Direct
peering
interface ==============================
 
I can confirm that direct connected, static, and customer's BGP routes
that
are provisioned in router A under premium vrf are being seen under
router B
under premium vrf. So the issue is only on those routes that are learned
via
direct peering under CT vrf. Those routes are not advertised to router B
premium vrf.
 
Any clue?
 
Cheers,
Jimmy
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list