I have a router with a VRF SVI that I need bound to another site with a pseudowire. The SVI is in a VRF, the LDP interface with all the bindings is in the global table. Is there a way to bleed it over to allow the VRF interface into the global LDP so it will peer? Closest thing I found was MPLS LDP-VRF-Aware Static Labels, but that seems messy and might not work in this instance.   Local interface: Vl117 up, line protocol up, Eth VLAN 117 up   Destination address: 172.30.10.22, VC ID: 5, VC status: down     Output interface: none, imposed label stack {}     Preferred path: not configured     Default path: no route     No adjacency   Load Balance: none   Flow Label: Disabled   Create time: 00:39:48, last status change time: 00:39:48   Signaling protocol: LDP, peer 172.30.10.22:0 up     Targeted Hello: 172.30.10.111(LDP Id) -> 172.30.10.22, LDP is DOWN, no binding     Status TLV support (local/remote)   : enabled/None (no remote binding)       LDP route watch                   : enabled       Label/status state machine        : local ready, LruRnd       Last local dataplane   status rcvd: No fault       Last local SSS circuit status rcvd: No fault       Last local SSS circuit status sent: Not sent       Last local  LDP TLV    status sent: No fault       Last remote LDP TLV    status rcvd: None (no remote binding)       Last remote LDP ADJ    status rcvd: None (no remote binding)     MPLS VC labels: local 532, remote unassigned     Group ID: local 0, remote unknown     MTU: local 1500, remote unknown     Remote interface description:   Sequencing: receive disabled, send disabled   Control Word: On (configured: autosense)   VC statistics:     transit packet totals: receive 0, send 0     transit byte totals:   receive 0, send 0     transit packet drops:  receive 0, send 0     Long story why it is this way, but I can't change the underlying design at this time.  ... View more

c7600s72033-adventerprisek9-mz.122-33.SRC3.bin 7609 with Sup7203BXL supervisors. Command rejected: VLAN 881 is crypto connected to Vl1020.This command is rejected because allowing it will result in a crypto connected interface vlan to belong to the interface's allowed vlan list. This poses a potential IPSec security breach.Note that this behavior applies to all trunk ports. If you're attempting to do "no switchport trunk allowed vlan <vlanlist>" Instead, use "switchport trunk allowed vlan none", or "switchport trunk allowed vlan remove <vlanlist>" I get the preceding message currently when trying to add the IPSec VLAN to a trunk port. Little background, this has been working for about a year on a different endpoint device with a trunk up to it. We migrated to a new device for the entpoint of the IPSec traffic and when trying to add the VLANs involved with it to the trunk, I get that message. Interface VLAN 881 on IPSec Service Module port GigabitEthernet7/0/1 connected to Vlan1020 with crypto map set IPSEC Interface VLAN 882 on IPSec Service Module port GigabitEthernet7/0/1 connected to Vlan1020 with crypto map set IPSEC Interface Vlan1020 on IPSec Service Module port GigabitEthernet7/0/1 connected to GigabitEthernet1/1 with crypto map set There is the show crypto vlan output. This was working just fine previously when I added the VLANs to a trunk, but when I tried to add the VLANs to a new set of interfaces, I got that error message. I went so far as to remove the VLANs from the working trunk and try to put them back, now I get the same message as above. VLAN Usage ---- -------------------- 1006 online diag vlan0 1007 online diag vlan1 1008 online diag vlan2 1009 online diag vlan3 1010 online diag vlan4 1011 online diag vlan5 1012 PM vlan process (trunk tagging) 1013 Control Plane Protection 1014 vrf_0_vlan 1015 Container0 1016 IPv6-mpls RSVD VLAN 1017 L3 multicast partial shortcuts for VPN 0 1018 Egress internal vlan 1019 Multicast VPN 0 QOS vlan 1020 macedon_vrf0 1021 IPv6 Multicast Egress multicast 1022 GigabitEthernet1/1 1023 GigabitEthernet1/2 1024 GigabitEthernet1/3 1025 GigabitEthernet1/7 1026 GigabitEthernet1/22 1027 GigabitEthernet1/24 1028 macedon_ctlvlan 1029 macedon_nat7.0 1030 GigabitEthernet2/1 1031 GigabitEthernet2/3 1032 GigabitEthernet2/7 1033 GigabitEthernet2/24 1401 GigabitEthernet1/7.1401 There is the internal VLAN usage. The IPSec tunnel is using VRF mode with the IPSec tunnel dropping to a VRF and the outside interfaces being in the gloal routing table. The VLANs 881 and 882 are part of that VRF and they are SVIs. ... View more

OK, I have a 2921 on 15.3-2T. ZBFW is working from the inside to the outside, but the DMZ is not being blocked at all to the inside. I am currently running with subinterfaces. All interfaces have zones attached. I have policies from inside to outside and DMZ to outside, those work fine. Without any policy from DMZ to inside, it can pass traffic freely from DMZ to inside. I have tried making an explicit policy to drop all to inside, still passes. I ended up just having to put an ACL on the interface I already tried upgrading the IOS, that is how I ended up on the newest version. This is connected to a 2960S with a trunk port. Everything else works perfectly except for the DMZ security. I haven't had time to try to lab it up yet, but wanted to see if anyone knows of any reasons this shouldn't work, as all documentation says it should drop all traffic unless you make a policy to pass traffic. I attached my running config, sensitive information was removed or changed. ... View more