Routing

Hi All, I'm trying to create a policy-statement which matches vpnv4 routes with a particular route-distinguisher. The route-distinguisher I'm using is a valid RD and is configured as part of a vrf-instance on the local router - however, when I check the config the router tells me the RD is 'not defined' - see below (N.B. I have changed the actual public IP address value in the RD to a dummy private address in the output below for security reasons!)

 

[edit policy-options policy-statement Inter-AS-VPN]

user@router#show

term 1 {

          from {

                   family inet-vpn;

                   protocol bgp;

                   rib bgp.l3vpn.0;

                   route-distinguisher 10.1.1.1:666; }

          then {

                   metric 10;

                   accept; }

 

[edit policy-options policy-statement Inter-AS-VPN]

user@router#commit check

re0: [edit] 'policy-options' Policy error: 10.1.1.1:306 route-distinguisher referenced (in term 1) but not defined

 

So, why would the router tell me this RD is 'not defined' when it is actually defined as part of a vrf-instance ..?

Hello,

The rule of thumb is that all objects used by policy (except IP addresses) must be defined under [edit policy-options]. Your RD is not defined there (it is may be defined under [edit routing-instances Whatever] but this does not count).

You need to define this RD under [edit policy-options]

set policy-options route-distinguisher 10.1.1.1:666 members 10.1.1.1:666

- and Your commit would pass.

On a separate note, matching on RD is not the best idea, using communities makes policies more scalable and manageable.

Finally, if You are using this policy as BGP export policy under BGP group/neighbor, don't forget to add "vpn-apply-export" knob.

HTH

Thx
Alex

Many thanks Alex - that's a good piece of information about defining the RD under policy-options - that's now in the memory bank! :) I had already come to the conclusion that tagging the prefixes with communities was probably the best way to go but I was still interested to know why the config wouldn't commit. Also, I'm aware of the requirement for the 'vpn-apply-export' knob, and it is already present in the BGP group I was hoping to apply the policy to, so it's not an issue. On a related matter: I was also playing around with prefix-lists/route-filters and discovered that vpnv4 96-bit addresses (e.g. 10.1.1.1:666:192.0.1.1/32) can't be used in prefix-lists/route-filters ... the router seems to think it's an IPv6 address which is wrongly formatted ... so, is there any way of referencing vpnv4 addresses in prefix-lists/route-filters ? TIA

Hello,

---

@Velociraptor wrote:
 discovered that vpnv4 96-bit addresses (e.g. 10.1.1.1:666:192.0.1.1/32) can't be used in prefix-lists/route-filters ... the router seems to think it's an IPv6 address which is wrongly formatted ... so, is there any way of referencing vpnv4 addresses in prefix-lists/route-filters ? TIA

---

Only literal IPv4 or IPv6 prefixes ("addresses"  if You will) are supported in JUNOS prefix-lists/route-lists.

And there is no such thing as "96-bit vpnv4 addresses", they are called VPNv4 NLRI in various RFCs and are

composed of RD+prefix.

As I mentioned before, if You'd use communities match, it will alleviate this pain as well among other benefits.

HTH

Thx

Alex

Yes - I'm aware that a vpnv4 address (or VPNv4 NLRI if you will) is RD+v4 prefix (64-bit RD + 32-bit v4 address) - calling it a 96-bit vpnv4 address is simply a colloquialism. Thanks anyway.