When configuring REP with trunk in place on ASR903 , I cannot use xconnect (Cisco TAC) So my only option is vfi

 

You need to configure l2vpn vfi instead of l2vpn xconnectTake a look at http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l2_vpns/configuration/xe-3s/asr903/mp-l2-vpns-xe-3s-asr903-book/mp-vpls.html

 

I’d use the following config for the service instances and the L2VPNI guess you can’t use the service instance in the L2VPN, because of the bridge-domain command inside the service instance.

service instance 1 ethernet  encapsulation dot1q 100,200,300  rewrite ingress tag pop 1 symmetric l2vpn xconnect context L2VPNmember GigabitEthernet0/0/0 service instance 1member GigabitEthernet0/1/0 service instance 1member pseudowire 20 Maybe the trunk keyword in the service instance plays some role..

 

 

 

 

 

 

This is how it would look like using the “old-style”

 

ASR903

interface GigabitEthernet0/0/0

service instance trunk 1 ethernet

encapsulation dot1q 100,200,300

rewrite ingress tag pop 1 symmetric

xconnect 2.2.2.2 20 encapsulation mpls

! interface GigabitEthernet0/1/0

!  service instance trunk 1 ethernet

!    encapsulation dot1q 100,200,300

!    rewrite ingress tag pop 1 symmetric

!    xconnect 2.2.2.2 40 encapsulation mpls

! — config related to backup PW–

Also on ME I’d recommend using xconnect under the service instance rather than attaching the service instance to a BD and configuring xconnect under the VLAN interface. Because if you attach a service instance to a BD by default MAC learning is in place and you don’t want that for a simple p2p PW (MAC learning can be disabled using cmd: ” no mac learning” under the BD config).

ME3600

interface GigabitEthernet0/x

service instance trunk 1 ethernet

encapsulation dot1q 100,200,300

rewrite ingress tag pop 1 symmetric

xconnect 1.1.1.1 20 encapsulation mpls

!     backup peer 1.1.1.1 40 encapsulation mpls

! — config related to backup PW–

 

 

 

 

 

> ASR903

> interface GigabitEthernet0/0/0

>  description Connected-To-AS1-G0/2

>  no ip address

>  negotiation auto

>  rep segment 20 edge primary

>  rep preempt delay 30

>  rep block port 3 vlan 1-4094

>  service instance trunk 1 ethernet

>   encapsulation dot1q 100,200,300

>   rewrite ingress tag pop 1 symmetric

>   bridge-domain from-encapsulation

>

>

> interface GigabitEthernet0/1/0

>  description Connected-To-AS2-G0/2

>  no ip address

>  negotiation auto

>  rep segment 20 edge preferred

>  rep preempt delay 30

>  service instance trunk 1 ethernet

>   encapsulation dot1q 100,200,300

>   rewrite ingress tag pop 1 symmetric

>   bridge-domain from-encapsulation

>

> interface pseudowire 20

> encapsulation mpls

> neighbor 2.2.2.2 20

>

> l2vpn xconnect context L2VPN

> member GigabitEthernet0/0/0 –> When I tried to put service-instance ,

> it did

> not accept the command

> member pseudowire 20

>

> ME3600

> interface vlan 100

> no ip address

> xconnect 1.1.1.1 20 encapsulation mpls

>

> Now , the xconnect came up as shown in the output below

>

> ME3600X#show mpls l2transport vc 20

>

> Local intf     Local circuit              Dest address    VC ID      Status

> ————-  ————————– ————— ———-

> ———-

> Vl100          Eth VLAN 100               1.1.1.1         20         UP

>

> ASR903#sh xconnect all

> Legend:    XC ST=Xconnect State  S1=Segment1 State  S2=Segment2 State

>   UP=Up       DN=Down            AD=Admin Down      IA=Inactive

>   SB=Standby  HS=Hot Standby     RV=Recovering      NH=No Hardware

>

> XC ST  Segment 1                         S1 Segment 2                         S2

> ——+———————————+–+———————————+–

> UP pri mpls 2.2.2.2:20                   UP   ac Gi0/0/0:6(Ethernet)          UP

>

> No ping between the two sites , I tried to modify the MTU vlaue on the

> interfaces going to the CE side , and the xconnect is down directly

> I have tested L3VPN using the exact same setup (without modifying the

> MTU

> values on any interface) and it worked fine

>

> Any ideas?

 

 

 

 

 

> Today.. I only have one ISP and uRPF works fine with this syntax

> -> ” ip verify unicast source reachable-via any 2699″

> I’m moving to a router with multiple  ISP and IX connections and some of our traffic is now asymmetric.

The above uRPF config didn’t work and was removed.

 

Does the router have a default-route? If so, “ip verify unicast source reachable-via any allow-default” should accomplish what you want.

 

If the router is default-free, is it not able to receive reachability information from the rest of your network for the prefixes that are getting incorrectly dropped? (assuming that was the symptoms of “didn’t work”)

 

Finally, what are the contents of access-list 2699? I assume it’s a whitelist of IPs to not drop traffic from, even if there aren’t discrete routes in the routing table for?

> Finally, what are the contents of access-list 2699? I assume it’s a

> whitelist of IPs to not drop traffic from, even if there aren’t

> discrete routes in the routing table for?

 

I’d forgotten about that option – always a bad idea, as it causes performance issues.

Allow-default is useful in circumstances where a default is present – it essentially renders the uRPF ‘S/RTBH-only’

 

This should work, but there’s little detail provided.

 

Did you configure it on both of the uplinks?

How did you monitor the drops and concluded that it ‘didn’t work’?

How you get the default route, is it pointing on one of the uplinks? ‘allow-default’ may be important here.

 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 

Usually it is done on the same session, and the customer adds a special community for blackhole routes.

 

The method I saw was:

 

1) add a null route for a private or test address (e.g. 192.0.2.1/32) on each router.

2) enable ‘ip verify unicast source reachable-via any’ on edge interfaces so that traffic in both directions is dropped for a null-routed prefix.

3) add a route-map that looks for your special community and changes the next hop for those prefixes to 192.0.2.1 (also to make sure that the prefix belongs to that customer, and that the mask length is not too small (e.g. >28))

 

Here’s an example for a different purpose, but basically the same idea:

 

http://www.team-cymru.org/bogon-reference-bgp.html

 

This method also allows you to republish the same blackhole prefix to your upstream providers if they support it, too (e.g. Level3 use community 3356:9999 for blackhole) to stop the traffic before it fills your upstream link.

-=-==-=-=-=–=

You want to just provide a community for your customer to tag which will take the route and change the next hop to null 0.  The idea here if URPF loose mode is enabled you can take any route that your customer tags with the appropriate community, set it’s next hop to null0 and as a result drop the traffic at your edges where you implement this action.

 

There’s a good all be it JunOS example of configuration in the RFC itself and a ton available via google for Cisco.

 

The basic idea is very simple though and just requires changing next hop when a tag is presented.

 

 

 

> Hi

>

> I have a network with ~10 router cisco with the full table BGP.

> I want add for my customer a blackhole possibility.

>

> Anyone have a tuto for this ?

>

> i think’s add a second bgp session with my customer and when he sent a

> prefix in this session, that put a route null on all of my router,

> it’s possible ?

>

 

Does the MPLS ping works between the two routers? -that would verify that the transport (i.e. LDP) labels for PE loopbacks are in place.

ping mpls ipv4 x.x.x.x/32 source y.y.y.y

 

Try cmd ” sh mpls forwarding-table” on both PEs and try to search for each other’s loopback IP /32 address.

On each PE -for the other PEs loopback in Outgoing Label column there should either be a “label value” or a “Pop Label” if the PEs are directly connected.

If it displays No Label then labels are not advertised/received for some reason.

-most of the times the problem is that LDP neighbours don’t see each other via Hello messages multicasted over the directly connected interface but only via the targeted LDP session.

– this can be caused when the interface is not enabled for MPLS i.e. cmd “mpls ip” is not enabled under the interface.

– or LDP passwords do not match.

(this will also be accompanied by OSPF advertising maximum metric for the link to avoid forwarding of MPLS packets over the link when the MPLS is actually not functional on the interface).

 

-or there’s a problem with access-list controlling the label advertisement on the neighbouring router.

 

-if the above is not the case it might be a HW programing issue.

The outgoing label for the other PE’s loopback IP address should be visible when you issue cmd “sh ip cef x.x.x.x/32 detail” *not sure about the exact syntax.