Re: [c-nsp] Configuration missing after upgraded IOS router 7600 from 12.2(33)SRD3 to SRE10.

My problem is serious in "ip nat inside source list 114 pool pool_vrf_DR vrf DR" command. https://supportforums.cisco.com/sites/default/files/attachments/discussion/c ant_configure.jpg Thank you very much. ___ cisco-nsp mailing list cisco-nsp@puck.neth

Re: [c-nsp] ASR920 Service Instance - when to 'rewrite ingress'

Hi Eric, Your understanding is right. I'm out of office this week, let me get back to you next week to figure what the issue is. Thanks, Vinod Kumar Balasubramanyam ENGINEER.TECHNICAL MARKETING vinba...@cisco.com WebEx Social profile Phone: +1 408 527 2051

Re: [c-nsp] ASR920 Service Instance - when to 'rewrite ingress'

> > interface GigabitEthernet0/0/6 > > mtu 9216 > > no ip address > > load-interval 30 > > negotiation auto ! > > service instance 243 ethernet > > description SI243 > >  encapsulation dot1q 243 > >  bridge-domain 243 > > Here you need indeed to pop 1 tag, otherwise on the backplane you will > hav

Re: [c-nsp] ASR920 Service Instance - when to 'rewrite ingress'

> I always was under the impression that 'rewrite ingress tag' was used > for either translation or termination of the VLAN on the local node, > but unnecessary when transparently passing traffic between SIs on > different interfaces. Is this wrong? There point is: "Bridge-domain" doesn't pass tra

Re: [c-nsp] ASR920 Service Instance - when to 'rewrite ingress'

> interface GigabitEthernet0/0/6 > mtu 9216 > no ip address > load-interval 30 > negotiation auto ! > service instance 243 ethernet > description SI243 >  encapsulation dot1q 243 >  bridge-domain 243 Here you need indeed to pop 1 tag, otherwise on the backplane you will have 2 times the 243 tag. T

[c-nsp] ASR920 Service Instance - when to 'rewrite ingress'

Hi all, Ran into an issue we haven't seen before, primarily due to a misunderstanding of when to use 'rewrite ingress tag pop 1 symmetric'. We turned up a new ASR920 and had some trouble getting traffic to pass between service instances on different interfaces. Here's the config we had: inter

Re: [c-nsp] Peering + Transit Circuits

On 18/08/2015 22:10, William Herrin wrote: > This technique described isn't URPF, it's simple destination routing. > The routes I offer you via BGP are the only routes in my table, hence > the only routes I'm capable of routing. If you send me a packet for a > _destination_ I didn't offer to you, I