Hi all, i did a lot of search about the following case and it is not
clear to me what are the facts. I need to bind about 10 VRF to the central router (MSFC) in a 6513 with 720G sup.
The objectives is to do as illustrate in the Figure B 5 Example 5 of this Cisco Document : http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/configuration/guide/exampl_f.html#wp1047426
The doc is not specifiying bottom router are physical. So we would like to to the same thing but with VRF for each customer. The question is 'How establish the connectivity between a VRF and the router (MSFC), in order to place a transparent FW context (in FWSM in the same chassis) between the VRF and the MSFC.
We need transparent because behind some customer VRF there will be a WAN with dynamic routing (which is not supported in routed Firewall in multi-context mode).
Any tips would be appreciated.
Probably we could plug a wire in the switch and 'connect' the VRF and a routed port but it is not very attractive !
I understand i can do Route Leaking between VRF with BGP, but this way we couldn't place transparent FW....
we do this to provide internet access to some VRFs.
We use a transparent context for each VRF, the context has two Vlans for example vlan 617 and vlan618.
An IRB instance, a bridge-group is used to bridge between vlans
int vlan 617
no ip address
int vlan 618
no ip address
ip address x.x.x.x 255.255.255.y
On the MSFC vlan 617 is in global routing table and SVI vlan618 is mapped in VRF.
The same IP subnet is used on both.
To overcome problems with same MAC address use on SVIs, VRF SVIs have a different MAC-address to be able to talk for example EIGRP between them.
int vlan 618
on the FWSM context there are some tips:
an ACL for nonIP traffic that allows STP traffic permits the FWSM to convert vlan 617 BPDUs to vlan 618 BPDUs and viceversa otherwise inconsistent vlan-id would be detected.
access-list NOTIP ethertype permit bpdu
if using static routes both GRT and VRF have to redistribute in routing protocols in use.
As explained in the document that you linked your IP ACLs on each context need to permit packets of routing protocol in use.
Hope to help
Giuseppe, it helped a lot ! i understand it is possible ... i tried it a couple of time and im unable to reach ip except the bridge (bvi) ip. On the FWSM, in the context admin, im able to ping the bvi but im not able to ping router on each end of Vlan. Of course, i cant telnet the management FWSM via telnet from the msfc
I put a test access list to permit any any tcp and icmp on both interface (in and out). In the url i mentionned above, there is sample configuration. In the admin context, the add a ARP entry. The same ARP are not in other context. Is there any reason for these entry to be there ? and why only in admin context ?
in admin context :
arp outside 10.1.1.2 0009.7cbe.2100
arp inside 10.1.1.3 0009.7cbe.1000
Not sure if it can be the reason why i dont access anything from the admin ctx.
to be noted you are not obliged to have all contexts in transparent mode, notably the admin context.
You can mix routed and transparent contexts.
The example shows the use of multiple transparent contexts. Each context has an IP address associated to the BVI, however user traffic is bridged between interfaces.
I would suggest to focus on user traffic on a test transparent context with one SVI in VRF and one in global routing table.
To manage the various contexts you can use
session slot n proc 1
take note of tuning for using SVIs on the same chassis
Hope to help
Good morning Giuseppe !
It is exactly what we did for now, trying to establish a transparent FW, with one int on a SVI Global a one Interface on a SVI VRF, all this bridge on a BVI. We manage via a session to the module. We can't access (ping, telnet....) BVI from either of interface (from global router or from VRF) and when in the context, we cannot reach any of two side (svi global ou svi VRF). We can ping the BVI ip when we are in the context.
Is there something else (not mentionned in the config sample) that could be mandatory for basic setup ? Is something required in the routing table (dont think so as it is on the same subnet).
is GRT SVI able to communicate with VRF mapped SVI?
this is your test, the ip address of BVI is less important for the moment.
use the two tricks about STP and about mac address and you should be fine.
to be honest we manage our transparent contexts in the same way via session slot and then changeto context
Hope to help
is GRT SVI able to communicate with VRF mapped SVI? The answer is NO.
Now i tried to put my admin context in routed mode instead. When all will be working, i will create other context in transparent mode. But guess what ? i have the same problem !!!
i created GRT SVI vlan 10 (svi 10.1.1.1)
i created VRF SVI vlan 11 (svi 10.1.2.1)
i created vlan 10 and 11
in FWSM system, i see int vlan 10 and 11
in admin context
int vlan 10 ip 10.1.1.2
int vlan 11 ip 10.1.2.2
when im in context, i ping 10.1.1.2 and 10.1.2.2. but never ping both SVI. (timeout).
i put an acl ip any any on both interface.
ip ut an acl icmp any any on both interface also.
i set up telnet access on int vlan 10 (GRT side) but cannot telnet the FWSM (10.1.1.2) from the switch
if i show arp i see ip of SVI (both)
So, in transparent mode or routed mode, i miss something in order IP in module can talk to IP in the switch (GRT or VRF). ^$%^$#%@!
Im using the switch in VSS Mode. The FWSM module in the other chassis is not configured yet.
some notes follow:
a) in transparent mode both SVIs should be in the same IP subnet the FWSM does not routing at all
b) if you are using a VSS verify that you have the correct software version on the FWSM
Firewall Services Module (FWSM) (WS-SVC-FWM-1-K9)
you need at least version 4.0.4 but I guess you have otherwise you could have problem to access the module as reported by others in previous posts.
c) if everything is fine about versions I think the first thing to do is to create the FWSM failover pair.
You can create failover-groups and each FWSM will be active for a subset of contexts.
also check the configuration of firewall vlan-group(s) on the VSS supervisor.
These commands are needed to create the list of permitted L2 vlans used on internal 6GE bundle between backplane and FWSM(s).
read this ask the expert about FWSM and VSS
Hope to help
Giuseppe, thanks again... we verify and we have good version. We rebuild the setup of the FWSM (clear all configuration). And we have the same results, either in Transparent or Routed Mode. The fact is it look like the FWSM doesnt contact MSFC at Layer 3, as we cant ping anyting (ex. we dont ping int inside from MSFC to FWSM or FWSM to MSFC) we cant telnet the FWSM nor contact http server (ASDM).
Weird, the sh arp command return the mac and ip of those interface (so the ARP Works) . all firewall Interface have same MAC. All svi have also have a unique MAC
We checked Firewall vlan group on the switch and the 2 Vlan used are assigned on group 1, and the group 1 is assigned to the switch module.
We really dont understand, we also compare a lot of sample FW config and nothing seems to be wrong.
How can be sure communication pass on the port Channel between the chassis and the fwsm for the specified vlan ?
How can be sure it is not the Firewall itself who drop connection ?
Would it be better for me to start in another thread with these question ?
>> We checked Firewall vlan group on the switch and the 2 Vlan used are assigned on group 1, and the group 1 is assigned to the switch module.
do you mean the FWSM module?
>> Weird, the sh arp command return the mac and ip of those interface (so the ARP Works) . all firewall Interface have same MAC. All svi have also have a unique MAC
do you see ARP entries for MSFC SVIs on the FWSM and ARP entries for FWSM interfaces on the MSFC? if so this should be enough to prove that L2 connectivity is correctly configured.
>> he fact is it look like the FWSM doesnt contact MSFC at Layer 3, as we cant ping anyting (ex. we dont ping int inside from MSFC to FWSM or FWSM to MSFC) we cant telnet the FWSM nor contact http server (ASDM).
we usually put the outside interface in contact with MSFC, if so it is normal that you cannot ping from MSFC the inside interface this would happen also with an external old PIX.
you should try to verify that you have basic connectivity on outside interface from MSFC to outside (if this is the interface directed to MSFC)
also you may need a static route like
route outside 0.0.0.0. 0.0.0.0 MSFC-ipaddress
to be able to reach it from outside.
sorry if these are basic suggestions that you have probably already implemented, but for security is better to do this sanity check.
Hope to help